Multi-channel ticket creation and service management system with an integrated customer service platform

Abstract

A multi-channel ticket creation and service management system that includes: a graphical interface controller configured to provide a graphical user interface (GUI) accessible through a plurality of predefined Uniform Resource Locators (URLs), the GUI including interactive service request forms associated with a plurality of hierarchical service and subservice classifications; a form processing circuit operatively coupled to the graphical interface controller and configured to receive a selected service-subservice combination from a user and dynamically populate subsequent input fields based on a predefined service taxonomy, the input fields including contact information, email address, subject, location identifier, area of ​​responsibility field, and a description field; a rule execution logical processing unit coupled to the form processing circuitry, the rule execution logical processing unit configured to enable or disable one or more context-sensitive fields based on logical rules stored in a service-subservice dependency tree, the logical rules governing the enablement of date and time fields exclusively when the selected service is journalism and the selected subservice is newspaper reporting; an authentication mapping processor comprising a session parser and a user-to-department resolver, wherein the session parser is configured to extract user credentials and associated metadata from session cookies or authentication tokens, and the user-to-department resolver is configured to auto-populate an activity-driven scope field based on the extracted metadata and an organizational mapping scheme; and a validation and transmission control unit configured to check the completeness and data type conformity of all enabled fields, generate a structured ticket record, and transmit it to a central ticket management platform.

Description

FIELD OF THE INVENTION

[0001] The present invention relates to customer support systems, and more particularly, to a system and method for generating, processing, and resolving service requests via a multi-interface ticketing platform. The system is specifically designed to support concurrent operation across web interfaces and real-time messaging applications. This enables improved user interaction, automated classification, and centralized management of service workflows in institutional environments such as universities or companies. BACKGROUND OF THE INVENTION

[0002] Traditional ticketing systems for service departments often require navigation through rigid web-based portals with static forms. This leads to inefficiencies, delayed responses, and an inconsistent user experience. Such systems lack intelligent automation for task routing, dynamic form filling, and multi-channel integration. Furthermore, institutions that handle diverse requests across departments suffer from a lack of traceability and limited performance visibility. With the evolution of digital service models, there is a critical need for a modular, scalable, and multi-channel customer support platform that enables seamless ticket creation, hierarchical classification, automated data capture, and full-cycle management across both desktop and mobile channels.The invention closes these gaps by introducing a configurable platform built on a service engine like ZOHO Desk, enabling real-time ticket creation via web and chatbot interfaces. It offers intelligent routing, contextual field activation, and operator-level dashboards for a comprehensive overview.

[0003] Customer service management systems have evolved significantly over the past two decades, from manual task assignment models and email-based support channels to sophisticated ticketing platforms that enable companies to systematically track, assign, and resolve customer or internal service requests. These platforms often form the foundation of the digital service infrastructure of modern companies, universities, and government agencies, enabling structured communication between service seekers and service providers. Despite these developments, the ticketing system landscape remains challenged by rising user expectations, mobile behavior, and the need for personalized, real-time interaction.

[0004] Most traditional ticketing platforms are primarily designed for desktop environments and rely on a form-based approach that assumes users submit requests through a static portal. In such systems, users typically fill out a fixed set of fields on a web form—such as name, department, issue type, and a free-text description—and submit the form, triggering a workflow in the backend system. While effective in controlled enterprise environments, this approach suffers from limited accessibility, particularly for non-technical users or mobile device users with limited connectivity. Furthermore, static forms often lack contextual intelligence. For example, irrelevant fields may remain visible regardless of the selected issue category, leading to user confusion or submission errors.These inefficiencies often lead to misrouting of tickets, longer processing times and a burden on employees due to necessary follow-up clarifications.

[0005] A critical disadvantage of most legacy systems is the lack of true multi-channel input functionality. While many platforms advertise omnichannel support, in practice, integrations with messaging apps or SMS are either superficial or rudimentary—typically implemented as one-way notification systems rather than fully interactive ticket submission channels. This limitation hampers real-time interaction, particularly in high-traffic environments like universities, where students and faculty prefer conversational interfaces for task completion. Most institutions still rely on email support or simple online forms that don't natively integrate with chat-based communication systems. This leads to fragmented user experiences and the loss of contextual data.

[0006] In recent years, chatbot frameworks have emerged that mitigate some of these limitations by providing conversational user interfaces (CUIs). Platforms such as Dialogflow, Microsoft Bot Framework, and IBM Watson Assistant enable developers to create chatbots that can interact with users through text-based input. These bots can be integrated with messaging platforms to collect service data, answer frequently asked questions, or route users to relevant service endpoints. However, these solutions typically operate in silos and are disconnected from the central ticketing infrastructure. Therefore, while chatbots can collect user requests, they often cannot generate formal tickets within a unified management console.The lack of backend integration with robust ticketing systems means that service requests captured via chatbots often have to be manually transcribed or transferred to the actual service management system, defeating the very purpose of automation.

[0007] Furthermore, most existing ticketing systems offer insufficient contextual customization options for form creation. For example, form fields cannot be dynamically adapted to the selected service category or subcategory, overwhelming users with irrelevant input requests. This static architecture does not reflect the hierarchical structure of real-world service organizations, where different teams or departments require different levels of detail and supporting information to operate effectively. In a university environment, for example, a communications request for photo coverage would require different data fields (e.g., event location, time, dress code) than a request to edit a press release (e.g., draft upload, headline suggestion, responsible faculty).Without dynamic adjustment of input fields, users either have to provide too many explanations in text descriptions or risk undervaluing the required information, which impairs service efficiency and satisfaction.

[0008] Another key limitation of traditional service management platforms is the lack of automated field population based on user metadata. While some platforms allow the use of templates or reusable forms, they often require manual entry of the same basic information—such as department, email address, or role—for multiple tickets. This not only impairs usability but also increases the likelihood of incorrect or inconsistent data entry. Modern systems should be able to identify users based on login credentials, session metadata, or authentication tokens and leverage this information to pre-populate fields such as "department," "assigned area," or "contact number."Without this capability, institutions that handle hundreds of internal service tickets daily face significant administrative overhead, increasing average ticket processing time and complicating audit trails.

[0009] From an administrative perspective, existing platforms often offer limited visibility into ticket history and performance tracking. While dashboards are typically available to display open or closed tickets, most systems lack detailed timeline visualizations that depict a ticket's lifecycle—for example, time of submission, time of assignment, time to first response, and time of resolution. Furthermore, response actions and ticket updates are typically not captured as discrete, time-stamped events accessible to both users and operators. This lack of granular traceability complicates accountability and performance evaluation for service managers.In large institutional settings, the ability to assess team responsiveness and identify bottlenecks is critical, especially for time-critical tasks such as media coverage of events, equipment repair, or academic content dissemination.

[0010] Despite advances in workflow automation and AI-assisted ticket routing, another common drawback of modern systems is the lack of capability for conditional field activation. For example, ticket fields such as "preferred time" or "urgency level" should ideally only be displayed for specific service types for which this data is relevant. Without conditional field activation based on contextual logic trees, most forms remain either overly complex or too general, compromising the effectiveness of ticket triage mechanisms. Furthermore, when users skip irrelevant but visible fields or misunderstand the required data, the resulting tickets are often incomplete, leading to unnecessary delays and follow-up communication.

[0011] Finally, ticket confirmation and user feedback mechanisms are often poorly implemented in existing solutions. While a user may receive an email confirmation after submitting a request, real-time confirmation via the same interface (especially in messaging environments) is rarely possible. Without an integrated feedback loop that immediately informs users about the ticket ID, estimated response time, and assigned department, trust in the system diminishes. In mobile-first environments such as student campuses, this lack of immediate confirmation can lead to duplicate submissions or confusion regarding ticket status.

[0012] In summary, the current state of ticketing and service management systems reflects a fragmented and partially automated landscape. While platforms like ZOHO Desk offer robust management tools, they often lack seamless integration of multi-channel input, adaptive form creation, chatbot-based ticketing, and user-specific metadata usage. In the context of institutional service delivery—where accessibility, speed, and traceability are essential—these limitations lead to inefficiency, user frustration, and suboptimal service performance. There remains significant potential to unify web-based, mobile, and chat-based ticketing workflows into a coherent, intelligent, and user-friendly system that dynamically adapts to organizational hierarchies, captures relevant metadata in real time, and provides complete visibility into service requests throughout their entire lifecycle.The proposed invention aims to address these long-standing deficiencies by introducing a tightly integrated, cross-interface system with intelligent automation, context-aware field generation, and centralized, dashboard-based ticket management suitable for modern institutions with complex internal support structures. Summary of the invention

[0013] The present invention describes a service ticket management system and method that enables users to create and manage service requests via both web-based portals and messaging interfaces. The invention comprises several integrated components, including a web interface rendering engine, a dynamic form generator with conditional field activation logic, a service classification module, a chatbot interaction engine, a data validation module, and a central operator dashboard. The system uses routing logic to route each ticket to a specific agent based on selected service parameters. It enables dynamic populating of form fields through hierarchical selection of service categories and subcategories. A chatbot guides users through a conversation flow to capture the required ticket data, validate responses, and automatically generate tickets with confirmation feedback.The administrative dashboard supports operator-side ticket management with metadata views, attachment management, response templates, and solution tracking. The invention significantly improves accessibility, efficiency, and service transparency for institutions that handle cross-departmental service communication. SHORT DESCRIPTION OF THE FIGURE

[0014] These and other features, aspects, and advantages of the present invention will become more readily understood when the following detailed description is read in conjunction with the accompanying drawings, in which like characters represent like parts throughout. Fig. Figure 1 shows a block diagram of a multi-channel ticket creation and service management system using an integrated customer service platform.

[0015] Those skilled in the art will also appreciate that the elements in the drawings are shown for convenience and are not necessarily to scale. For example, the flowcharts illustrate the method by key steps to enhance understanding of aspects of the present disclosure. Furthermore, with respect to device construction, one or more components of the device may be represented in the drawings by conventional symbols. The drawing may show only the specific details relevant to understanding embodiments of the present disclosure in order not to clutter the drawing with details that would be readily apparent to those skilled in the art from the present description. Detailed description of the invention

[0016] To facilitate understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and a clear description will be given. However, the scope of the invention is not limited thereby. Changes and further modifications to the illustrated system, as well as further applications of the principles of the invention, are possible, as would normally occur to one skilled in the art to which the invention pertains.

[0017] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be limiting thereof.

[0018] References in this specification to "one aspect," "another aspect," or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Therefore, the language "in one embodiment," "in another embodiment," and similar language throughout this specification may or may not refer to the same embodiment.

[0019] The terms "comprises," "comprising," or other variations thereof are intended to cover non-exclusive inclusion, such that a process or method comprising a list of steps may include not only those steps, but also additional steps not expressly listed or inherent in that process or method. Likewise, the statement "comprises" for one or more devices, subsystems, elements, structures, or components does not exclude, without further limitation, the existence of other devices, subsystems, elements, structures, components, or additional devices, subsystems, elements, structures, or components.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention pertains. The systems, methods, and examples provided herein are for illustrative purposes only and should not be considered limiting.

[0021] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0022] In Fig.Figure 1 shows a block diagram of a system for multi-channel ticket creation and service management using an integrated customer service platform. The system 100 includes: a graphical user interface (GUI) accessible via multiple predefined Uniform Resource Locators (URLs) and containing interactive service request forms associated with multiple hierarchical service and subservice classifications; a form processing circuit (104) operatively connected to the graphical user interface and operative to receive a selected service-subservice combination from the user and dynamically populate subsequent input fields based on a predefined service taxonomy, wherein the input fields include contact information, email address, subject, location identifier, jurisdiction, and description field;a rule execution logic processing unit (106) coupled to the form processing circuitry and configured to enable or disable one or more context-sensitive fields based on logical rules stored in a service-subservice dependency tree, the logical rules governing the enablement of date and time fields exclusively when the selected service is journalism and the selected subservice is newspaper reporting;an authentication mapping processor (108) comprising a session parser and a user-to-department resolver, wherein the session parser is configured to extract user credentials and associated metadata from session cookies or authentication tokens, and the user-to-department resolver is configured to automatically populate a field for the activity-driven area based on the extracted metadata and an organizational mapping schema; a validation and delivery control unit (110) configured to verify completeness and data type conformance of all enabled fields, generate a structured ticket record, and transmit it to a centralized ticket management platform via an application programming interface (API) integration;

[0023] The aforementioned units—namely, the graphical user interface controller, the form processing circuitry, the rule execution logic processing unit, the authentication mapping processor, and the validation and submission controller—are implemented as hardware-based modules, each contained within one or more physical computer components, such as FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), or microcontroller-based circuit assemblies. These units are not merely abstract software constructs but are configured as dedicated electronic subassemblies within a service terminal or embedded computing device, each unit comprising memory-mapped logic, digital signal paths, and input / output interfaces designed to perform specific tasks described in the claim.For example, the form processing circuitry includes hardware-encoded control logic for retrieving and populating service taxonomies in real time; the rule execution logic processing unit includes non-volatile memory and comparison logic for enforcing activation rules for GUI fields; and the authentication mapping processor has a hardware-level session decoding mechanism and a lookup matrix implemented through register-based access to map users to departments.

[0024] In one embodiment, the form processing circuitry (104) comprises a dependency inference engine configured to retrieve from a ruleset repository only those input fields and values ​​relevant to the selected subservice. The fields are displayed in a cascading form framework that adapts in real time based on previous selections, minimizing user errors and unnecessary input.

[0025] In one embodiment, the rule execution logic processing unit (106) further comprises a logic state evaluator configured to evaluate Boolean predicates for each service sub-service node in the dependency tree and to trigger real-time field switching within the form interface using event-driven DOM mutation, thereby enabling seamless user interaction without requiring a full page reload.

[0026] In one embodiment, the authentication mapping processor (108) is further configured to retrieve user role data and operational context through integration with an institutional directory service, and wherein the auto-populated activity controlled area field is checked against access control restrictions to ensure the legitimacy of the request and appropriate forwarding.

[0027] In one embodiment, a chatbot-driven input subsystem operatively integrated with a third-party messaging platform is also included. The subsystem includes: a conversation logic controller that initiates an interactive dialogue with the user by presenting selectable service options in a hierarchical order; a prompt generation engine that dynamically generates natural language prompts based on user selections and contextual inferences from previous responses; an asynchronous input validator that, for each conversation step, receives user-provided input and validates it against expected data types, required fields, and semantic constraints; and a message-to-ticket translator that compiles the conversation inputs into a structured ticket request and transmits it to the central ticket management platform.

[0028] In one embodiment, the prompt generation engine is further configured to adjust the tone, complexity, and language of subsequent prompts based on real-time response latency and interaction abandonment heuristics, thereby increasing mobile ticket creation completion rates.

[0029] In one embodiment, the asynchronous input validator comprises a rule checking microservice deployed on a serverless execution layer. The microservice is configured to invoke a pre-trained data schema and generate immediate feedback to guide the user toward correction before ticket instantiation.

[0030] In one embodiment, the message-to-ticket translator includes a context linking mechanism that tags each input value with a metadata key corresponding to the internal field identifier used by the centralized service platform. This ensures bidirectional integrity during integration with the platform's ticket database.

[0031] In one embodiment, an operator dashboard module configured to simplify administrative response and ticket management is also included.The Operator Dashboard module includes: a status filtering engine that sorts incoming tickets into open, in progress, expired, and resolved categories based on timestamps and SLA criteria; a ticket metadata panel that displays all relevant attributes of a ticket, including requester name, delivery channel, assigned assignee, attachments, and expiration information; a timeline history viewer that presents a scrollable sequence of all status changes, replies, and internal comments as timestamped events; and a standardized response executor configured to retrieve pre-approved response templates from a solution database and issue structured messages via a "Reply All" action, followed by the optional invocation of a "Close Ticket" protocol.

[0032] In one embodiment, the status filtering engine includes a predictive urgency classifier configured to assign visual priority indicators to incoming tickets based on keyword matching, duration of inactivity, and contextual flags in the submitted description field.

[0033] The present invention, as described in the above claims, comprises a high-tech, multi-channel ticket generation and service management system that integrates structured web interfaces and conversational chatbot subsystems to enable efficient and transparent handling of service requests. At the core of the invention is a form processing circuit that interacts with a service classification module, allowing users to select hierarchical categories of services and subservices. Following user selection, the dynamic form engine calls a dependency inference engine, which retrieves the appropriate input fields for the selected subservice from a service rule repository. These input fields, including, among others, contact information, subject, email address, location, area of ​​responsibility, and description, are then dynamically inserted into the form interface.This is done using a cascading framework that leverages client-side JavaScript logic and server-side service dependency APIs to expose only the required components, thus reducing cognitive load and input errors.

[0034] A key aspect of this system is the rule execution logic processing unit, which controls context-specific field activation. This engine is based on a service-subservice dependency tree in JSON or XML format, with each node associated with Boolean predicates that control the display logic. For example, if the selected service is "Journalism" and the subservice is "Newspaper Reporting," the logic tree triggers the activation of a date and time field required for scheduling. The system evaluates these predicates in real time using an embedded rule evaluation engine that works with DOM mutation observers and reactive data binding. This ensures immediate feedback and seamless user interaction without requiring a full page refresh or form reload.

[0035] The system also includes an authentication mapping processor, consisting of a session parser and a department resolution engine. Upon login or portal access, the system analyzes user session cookies or authentication tokens to extract identifiers such as user ID, department affiliation, and access rights. These values ​​are compared against a preconfigured organizational schema to automatically populate the "Activity Controlled Scope" field, ensuring precise ticket routing based on the organizational context. This automatic mapping mechanism leverages a local directory cache, regularly updated via LDAP or single sign-on integration, to reduce latency and ensure high accuracy in department-level mapping.

[0036] To operate alternative user interfaces, the system integrates a chatbot-driven input subsystem. This subsystem is hosted on a cloud-based bot platform and connects to messaging services via a secure API. The conversation logic controller initiates a session with the user by presenting high-level service categories as selection options. After selecting a service, the system invokes the prompt engine, which synthesizes subsequent prompts based on a combination of hard-coded field mappings and machine-learned response modeling. These prompts are created using natural language adaptation logic, which can adjust tone and verbosity depending on user input patterns, such as delays or corrections.

[0037] As the user responds, the asynchronous input validator checks each message fragment against a dynamic field validation table. This validator operates serverless, using a microservice architecture that calls stateless validation functions that check data types, required fields, regular expression conformance, and semantic congruence. After successfully capturing all data points, the message-to-ticket translator assigns metadata keys to each user input and maps it to the internal schema of the central ticketing platform. The complete data packet is then encapsulated in a structured JSON object and transmitted to the ticketing platform via a RESTful API. There, it is logged and confirmed with a chatbot message containing the ticket ID and estimated resolution time.

[0038] For administrative processing, the invention includes an operator dashboard based on a real-time ticket inbox module. This dashboard features a status filtering engine that dynamically categorizes incoming tickets based on status transitions and SLA-related attributes such as elapsed time, owner assignment, and idle duration. It utilizes a predictive urgency classifier that uses a combination of keyword-based scoring and heuristic rule evaluation to assign visual priority indicators to each ticket. This classifier analyzes the description field and evaluates metadata such as department, submission time, and trends in previously closed tickets to recommend sorting.

[0039] In each ticket view, the metadata panel displays comprehensive details about the request, including the requester's identity, the submission method (web or chatbot), the assigned assignee, attached evidence files, and any escalation tags. The system logs each interaction in a delta tracking ledger engine, which maintains an attachment log of status changes and user comments. This engine uses cryptographically signed timestamps to ensure tamper-proof event tracking. The operator can view the chronological processing of the ticket in the timeline history viewer. The scrollable interface displays all changes, responses, reassignments, and closures in real time.

[0040] Tickets are resolved via a standardized response execution unit. This unit contains a response template selector that retrieves pre-approved message fragments based on the selected service and subservice. This allows the operator to compose a complete resolution message using predefined placeholders and variable substitutions. The operator then uses the "Reply All" function to ensure all parties receive the resolution. After sending, the operator calls the "Close Ticket" protocol, which updates the ticket status, archives it, and triggers a post-resolution confirmation notification to the user.

[0041] The system also features an escalation management module that continuously monitors ticket queues and evaluates each entry based on escalation policies. These policies are stored in a policy engine that checks for conditions such as unassigned tickets above a certain threshold, the presence of urgency terms such as "urgent" or "critical" in the description field, and the lack of a response within the SLA timeframe. If a condition is met, the module initiates the reassignment of the ticket to a senior employee, flags it for review, or sends an escalation alert via email and SMS, depending on the configuration.

[0042] From a synchronization perspective, the centralized ticket management platform provides a bidirectional API interface that receives input from both the web portal and the chatbot subsystem. This API uses a unified schema to ensure consistency of ticket attributes such as timestamps, user data, service assignment, and resolution flow. It also provides hooks for real-time updates displayed in the web dashboard and message confirmations, ensuring that all parties involved are aware of the current status of each request.

[0043] Together, the techniques and subsystem architectures described here form a robust, scalable, and user-friendly platform for managing service requests in institutional environments. The invention addresses key inefficiencies of traditional systems by integrating advanced UI / UX techniques, rule-based form functionality, real-time chat interaction, and intelligent backend automation to ensure a transparent, traceable, and effective service solution.

[0044] The system described here comprises a ticket management device with a multi-interface service initiation module, a classification-based routing logic controller, and a chatbot-enabled ticket generator. All components are connected to a central service management platform such as ZOHO Desk. The system architecture enables the generation of service requests from two main sources: a web-based portal interface accessible via URLs such as servicios.ubo.cl and prensa.ubo.cl, and a chatbot embedded in a messaging application. The web-based interface is managed by a web interface unit that dynamically creates domain-specific ticket forms. Upon accessing the corresponding portal, the user is presented with service entry points such as the "TICKET" or "CREATE TICKET" option, which invoke the dynamic service request interface.

[0045] The Service Classification Unit prompts the user to select from a hierarchical list of SERVICE and SUBSERVICE types, each corresponding to different roles and tasks within institutional communication. Once selected, a dynamic form engine generates the relevant fields for user completion, including CONTACT, EMAIL, SUBJECT, LOCATION, AREA OF RESPONSIBILITY, and DESCRIPTION. The engine is equipped with an e that limits the display of form fields to only those associated with the selected subservice. Additionally, there is a Conditional Field Activation Unit operating through a context evaluation module that evaluates the service-subservice selection in real time to activate certain fields such as DATE and TIME only if the service is JOURNALISM and the subservice is NEWSPAPER REPORTING.

[0046] To ensure organizational coherence, an Activity Mapping Unit with User Context Identifier and Department Resolver Engine automatically populates the "ACTIVITY CONTROLLED AREA" field by mapping login metadata or session data to a preconfigured organizational hierarchy. After the form is completed, a Ticket Submission Unit performs input validation and submits the fully structured service ticket to the central ZOHO Desk instance. This initiates the ticket assignment and lifecycle.

[0047] In addition to the web-based input channel, the system includes a chatbot interaction unit that can be used in messaging environments. A conversation initiation module presents the user with selectable service options based on pre-installed templates, after which a dialogue management engine sequentially requests user input. The chatbot interaction dynamically adapts to the user's previous responses and uses a natural language prompt generator. This optimizes the sequence of inputs to facilitate task completion. The input values ​​are validated in real time using a data validation module. This module consists of a structured input checker that compares user input with predefined data formats and issues correction prompts in case of errors.

[0048] Once all required inputs have been captured, a ticket generation subsystem consolidates the data into a structured format, submits the ticket to the central service system, and uses an asynchronous notification handler to send a confirmation message containing the ticket ID and estimated resolution time. All chatbot-based tickets are logged along with their web-based counterparts, ensuring a unified ticket stream.

[0049] On the backend, service operators access tickets through an Operator Dashboard Unit hosted in the ZOHO Desk interface. This unit contains a Ticket Inbox module that displays tickets from all departments with advanced filtering options by status (open, expired, or closed), department ownership, or SLA expiration risk. Each ticket is accompanied by a conversation view window that displays user information, status indicators, attached media, and relevant timestamps. A History Tracking Engine maintains a complete log of ticket actions, generated by a Change Log Generator, and displays them in a scrollable, time-stamped timeline. To optimize responses, a Response Execution Unit provides a Reply Template Selector that retrieves context-specific templates based on the service-subservice mapping and allows operators to respond using the "ALL REPLIES" feature.Ticket closure is achieved by using the “CLOSE TICKET” command, which updates the lifecycle status in the database and archives the case.

[0050] The present invention relates to a service management system (hereinafter referred to as "the system") designed to facilitate companies in providing high-quality services to their customers. The system comprises an integrated platform that automates customer service processes, enables performance tracking, and enables efficient management of service requests through ticket creation and processing.

[0051] In one embodiment, the system offers several user interfaces for creating service tickets. A first method involves accessing a specific service portal (e.g., SERVICIOS.UBO.CL) and selecting the "COMMUNICATION SERVICES" option. The user is then redirected to a subpage where they can proceed with ticket creation using the "TICKET" option.

[0052] A second option is to access a separate interface at PRENSA.UBO.CL and select the "Create Ticket" option to initiate the service request. Upon accessing the ticket creation page, a form appears in which the user must fill out several input fields for the type of service requested.

[0053] The system features a hierarchical mechanism for classifying services. After selecting a service category, the system dynamically displays a corresponding field with subservices listing the specific tasks of the communications team. These subservices are individually tailored to the specialization of each team member.

[0054] The ticket creation form contains additional required fields such as: contact name, email address, subject of the request, physical location, responsible department, description of the request.

[0055] In certain cases, certain fields are only enabled under certain conditions. For example, the DATE and TIME input fields are only enabled if the SERVICE is JOURNALISM and the SUBSERVICE is NEWSPAPER REPORTS.

[0056] Additionally, an “ACTIVITY-DRIVEN AREA” field is integrated to automatically fill in the user’s defined work area, simplifying the data entry process.

[0057] In another embodiment, the system integrates messaging applications to enable ticket inquiries via chatbot interaction. A chatbot is preconfigured to interact with users on a communication platform. Through a guided conversation flow initiated by selecting "Select Option," the chatbot collects structured information relevant to the selected service area.

[0058] After successful data transmission, the chatbot confirms that the ticket has been recorded and ends the conversation.

[0059] The system also includes a user-friendly dashboard that displays an inbox view of all incoming tickets from various departments. Features provided include: Filter tickets by status (open, expired, closed, etc.) Direct ticket creation by the operator from the ticket requests area From the "CONVERSATION" tab on the dashboard, the operator can access key details for each ticket, including ticket owner information, current status, and expiration date. The system also supports downloading attachments, including documents and photo files associated with each ticket.

[0060] The HISTORY tab provides a chronological view of interactions and updates on individual tickets, improving traceability and accountability.

[0061] After processing a service request, the operator can use the "ALL REPLIES" function to send a standardized response to inform the requester that the task has been completed. The operator can then execute the "CLOSE TICKET" command to close the ticket and archive it in the system.

[0062] In addition, the ticket submission unit integrates an escalation trigger module. This applies rules to identify high-priority or delayed tickets. Urgency keywords, incomplete submissions, or expired time thresholds are checked. If necessary, reassignment is automatically triggered at the supervisor level. The entire system functions as a unified system that improves responsiveness, reduces manual workload, and ensures consistent service delivery across departments via synchronous and asynchronous user interfaces.

[0063] The present invention relates to the technical field of digital service management systems and enterprise-wide customer support infrastructure. More specifically, it relates to systems and methods for generating, classifying, routing, validating, tracking, and resolving institutional service requests using a multi-interface ticketing platform that integrates web-based portals and chat clients. The invention lies at the intersection of user interface engineering, real-time data validation, rule-based automation, and asynchronous communication systems and is particularly relevant for organizations such as universities, corporations, and service providers seeking to improve their internal task allocation, cross-departmental communication, and user engagement through intelligent and centralized service management workflows.

[0064] The drawings and the foregoing description illustrate examples of embodiments. Those skilled in the art will recognize that one or more of the described elements may well be combined to form a single functional element. Alternatively, certain elements may be separated into multiple functional elements. Elements of one embodiment may be added to another embodiment. For example, the order of the processes described herein may be changed and is not limited to the manner described herein. Furthermore, the actions of a flowchart need not be performed in the order shown; nor do all actions need to be performed. Also, actions that are not dependent on other actions may be performed in parallel with the other actions. The scope of the embodiments is in no way limited by these specific examples.Numerous variations, whether explicitly stated in the specification or not, such as differences in structure, dimensions, and use of materials, are possible. The scope of the embodiments is at least as broad as indicated in the following claims.

[0065] Advantages, further benefits, and solutions to problems have been described above with reference to specific embodiments. However, the advantages, advantages, solutions to problems, and any components that may result in or enhance an advantage, advantage, or solution are not to be construed as critical, required, or essential features or components of any or all of the claims. REFERENCES 100 A system for multi-channel ticket creation and service management using an integrated customer service platform. 102 Graphical interface control unit 104 Form processing circuit 106 Rule execution logic processing unit 108 Authentication Mapping Processor 110 Validation and Submission Control Unit

Claims

[1] A multi-channel ticket creation and service management system, the system includes: a graphical interface controller configured to provide a graphical user interface (GUI) accessible through a plurality of predefined Uniform Resource Locators (URLs), the GUI including interactive service request forms associated with a plurality of hierarchical service and subservice classifications; a form processing circuit operatively coupled to the graphical interface controller and configured to receive a selected service-subservice combination from a user and dynamically populate subsequent input fields based on a predefined service taxonomy, the input fields including contact information, email address, subject, location identifier, area of ​​responsibility field, and a description field; a rule execution logical processing unit coupled to the form processing circuitry, the rule execution logical processing unit configured to enable or disable one or more context-sensitive fields based on logical rules stored in a service-subservice dependency tree, the logical rules governing the enablement of date and time fields exclusively when the selected service is journalism and the selected subservice is newspaper reporting; an authentication mapping processor comprising a session parser and a user-to-department resolver, wherein the session parser is configured to extract user credentials and associated metadata from session cookies or authentication tokens, and the user-to-department resolver is configured to auto-populate an activity-driven scope field based on the extracted metadata and an organizational mapping scheme; and a validation and transmission control unit configured to check the completeness and data type conformity of all enabled fields, generate a structured ticket record, and transmit it to a central ticket management platform. [2] The system of claim 1, wherein the form processing circuitry comprises a dependency inference engine configured to retrieve from a ruleset repository only those input fields and values ​​relevant to the selected subservice, the fields being displayed in a cascading form framework that adapts in real time based on previous selections, thereby minimizing user errors and unnecessary input. [3] The system of claim 1, wherein the rule execution logic processing unit further comprises a logic state evaluator configured to evaluate Boolean predicates for each service sub-service node in the dependency tree and to trigger real-time field switching within the form interface using event-driven DOM mutation, thereby enabling seamless user interaction without requiring a full page reload. [4] The system of claim 1, wherein the authentication mapping processor is further configured to retrieve user role data and operational context through integration with an institutional directory service, and wherein the auto-populated activity-controlled area field is checked against access control restrictions to ensure the legitimacy of the request and appropriate routing. [5] The system of claim 1 further comprises a chatbot-driven input subsystem operatively integrated with a third-party messaging platform, the subsystem comprising: a conversation logic controller configured to initiate an interactive dialogue with the user by presenting selectable service options in a hierarchical order; a prompt generation engine configured to dynamically generate natural language prompts based on user selections and contextual inferences from previous responses; an asynchronous input validator configured to receive user-provided input for each conversation step and validate it against the expected data types, required fields, and semantic constraints; and a message-to-ticket translator configured to compile conversation inputs into a structured ticket request and transmit it to the central ticket management platform. [6] The system of claim 5, wherein the prompt generation engine is further configured to adjust the tone, complexity, and language of subsequent prompts based on real-time response latency and interaction abandonment heuristics, thereby increasing mobile ticket creation completion rates. [7] The system of claim 5, wherein the asynchronous input validator comprises a rule checking microservice deployed on a serverless execution layer, the microservice configured to invoke a pre-trained data schema and generate immediate feedback messages to guide the user for correction prior to ticket instantiation. [8] The system of claim 5, wherein the message-to-ticket translator comprises a context linking mechanism that marks each input value with a metadata key corresponding to the internal field identifier used by the centralized service platform, thereby ensuring bidirectional integrity during integration with the platform's ticket database. [9] The system of claim 1, further comprising an operator dashboard module configured to facilitate administrative response and ticket management, the operator dashboard module comprising: A status filtering engine configured to sort incoming tickets into open, in-progress, expired, and resolved categories based on timestamps and SLA criteria; a ticket metadata panel configured to display all relevant attributes of a ticket, including the requester's name, delivery channel, assigned assignee, attachments, and expiration information. a timeline history viewer configured to display a scrollable sequence of all status changes, replies, and internal comments as time-stamped events; and a standardized response executor configured to retrieve pre-approved response templates from a solution database and output structured messages via a "Reply All" action, followed by the optional invocation of a "Close Ticket" protocol. [10] The system of claim 9, wherein the status filtering engine comprises a predictive urgency classifier configured to assign visual priority indicators to incoming tickets based on the match of keywords, duration of inactivity, and contextual flags within the submitted description field.

Images