Customer support system and customer support method

Abstract

In an environment where customer messages are received through multiple channels, we provide a customer support system that integrates these messages to efficiently handle customer inquiries. [Solution] The system includes: an acquisition unit that acquires messages from customers transmitted from multiple different channels; a conversion unit that converts the information contained in the messages acquired by the acquisition unit into a predetermined format; a registration unit that registers the converted information on a management platform; a response unit that searches for response candidates related to the acquired message from response knowledge information managed for each facility and generates a response proposal from the searched response candidates according to predetermined conditions; and an escalation unit that switches to an operator response if no response proposal is generated for the message, or if the message matches the emergency notification conditions.

Description

Technical Field

[0001] The present invention generally relates to a technology for supporting customer service.

Background Art

[0002] In recent years, in the accommodation industry, the contacts with customers have diversified, and inquiries and reservations from customers are received through multiple channels such as telephone, email, message applications (messaging apps), and online travel agencies (OTAs). Each of these channels has different data formats and communication protocols, and the staff (operators) of accommodation facilities are in a situation where they have to switch between multiple management screens to handle them. In addition, the customer service operations in accommodation facilities have become more complex, such as the need for multilingual support, 24-hour support, and even rapid response in case of emergencies.

[0003] In response to such problems, various technological developments have been carried out to improve the operational efficiency of accommodation facilities. In Patent Document 1, a hotel reservation system is disclosed that integrally manages reservation information of accommodation facilities, associates related different reservations, and can efficiently display and operate them. In this hotel reservation system, a technology for displaying related reservation information is provided by storing reservation information corresponding to reservation identification information and managing specific information indicating the relationship between different reservation information.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] The technology described in Patent Document 1 focuses on efficiently managing and operating the reception staff of accommodation facilities when users make reservations for continuous stays for a predetermined period using different websites where accommodation facilities can be booked. Therefore, there is room for improvement in the system that automates customer service operations by integrating various inquiry channels such as telephone, email, messaging apps, and OTAs.

[0006] Based on the above, this invention proposes a customer support system and the like for integrating customer messages and efficiently performing customer service operations in an environment where customer messages are received through multiple channels. [Means for solving the problem]

[0007] To solve the above problems, the present invention provides a customer support system for assisting customer service operations at a facility, comprising: an acquisition unit that acquires messages from customers transmitted from multiple different channels; a conversion unit that converts information contained in the messages acquired by the acquisition unit into a predetermined format; a registration unit that registers the information converted by the conversion unit into a management platform; a response unit that searches for response candidates related to the message acquired by the acquisition unit from response knowledge information managed for each facility, and generates a response proposal from the searched response candidates according to predetermined conditions; and an escalation unit that switches to an operator response if the response unit does not generate a response proposal for the message, or if the message matches the emergency notification conditions. [Effects of the Invention]

[0008] According to the present invention, in an environment where customer messages are received through multiple channels, these messages can be integrated to efficiently perform customer service operations. Problems, means, and effects not mentioned above will be clarified by the following description of embodiments. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of a customer support system according to the first embodiment. [Figure 2] This figure shows an example of the functional configuration of a customer support system according to the first embodiment. [Figure 3] This figure shows an example of a flowchart related to processing in the customer support system according to the first embodiment. [Figure 4] This figure shows an example of text channel processing according to the first embodiment. [Figure 5] This figure shows an example of audio channel processing according to the first embodiment. [Figure 6] This figure shows an example of a flowchart relating to the learning process according to the first embodiment. [Figure 7] This figure shows an example of a screen according to the first embodiment. [Modes for carrying out the invention]

[0010] (I) First Embodiment The configurations, procedures, or other elements disclosed below are provided to illustrate embodiments of the present invention and do not limit it. The descriptions based on the drawings are intended to aid understanding, and the shapes, arrangements, functions, etc., of elements may be omitted or simplified as necessary. The present invention is not limited to one or more of the disclosed embodiments and can also be implemented by functionally or structurally equivalent means, or other means achieving similar technical objectives, to the extent that a person skilled in the art can understand from this specification. Unless otherwise specified, each component in this specification is construed as including "at least one." Furthermore, a singular form of a word includes its plural form, and a plural form of a word includes its singular form. In addition, terms used herein are not limited to a specific meaning, to the extent that they are clear from the context, and should be appropriately interpreted by a person skilled in the art. For example, the expression "including" is construed as meaning not limited to those listed.

[0011] The following will be a detailed explanation using the drawings. In this embodiment, identical elements shown in the drawings are denoted by the same reference numeral.

[0012] Figure 1 shows an example of a customer support system according to this embodiment (customer support system 100).

[0013] The customer support system 100 consists of a customer terminal 110, a low-code platform 120, an integrated management platform 130, an FAQ database 140, an internal notification system 150, and an external system 160.

[0014] The customer terminal 110 is a device used by customers, such as guests of accommodation facilities, to make inquiries to the facility, and can be a smartphone, tablet, personal computer, or telephone. The customer terminal 110 can send inquiry information (messages) via various channels such as email, messaging apps, online travel agencies (OTAs), and telephone lines.

[0015] The low-code platform 120 is a central device that receives messages, performs format conversion, extracts metadata, and controls the processing flow. As an example, the low-code platform 120 is described as a platform that connects multiple SaaS or cloud services and proprietary APIs using "no-code or low-code" methods, allowing for consistent workflow design, execution, and monitoring on a drag-and-drop visual interface. For example, the low-code platform 120 sends messages from channels to the integrated management platform 130 as ticket information, based on workflows established for each channel.

[0016] The integrated management platform 130 is a system that records the content of messages and centrally manages interactions with operators (such as facility staff, operators, administrators, etc.) and status management. As the integrated management platform 130, for example, a CRM (Customer Relationship Management) system is used.

[0017] The FAQ database 140 is a database that accumulates and manages FAQs (Frequently Asked Questions: response knowledge information such as past response examples to customer inquiries and facility-specific response policies). The low-code base 120 queries the FAQ database 140 using the message as a key and obtains corresponding response candidates.

[0018] The internal notification system 150 is a notification channel for operators and includes a messaging system capable of sharing information within the organization. For example, as the internal notification system 150, an internal chat system, groupware, etc. are used. When automatic response by FAQ is impossible or the urgency is high, the low-code base 120 sends notification data to the internal notification system 150 to prompt human response.

[0019] The external system 160 is an external service such as a text generation service, translation service, speech recognition service, speech generation service, etc., and cloud services. The low-code base 120 can execute translation processing, voice conversion processing, etc. using the external system 160 for messages and response candidates.

[0020] In this way, the customer support system 100 performs diverse system linkages via the low-code base 120 and integrally realizes channel integration, response generation, FAQ learning, etc.

[0021] Although this embodiment uses accommodation facilities as an example, this embodiment is not limited to accommodation facilities and can be similarly applied to, for example, medical facilities, car rental offices, restaurants, and other facilities that provide customer service.

[0022] Figure 2 shows an example of the functional configuration of the customer support system 100 (for example, the low-code platform 120).

[0023] The low-code platform 120 comprises a processor 210, a storage device 220, and an interface device 230. The processor 210 is a device that performs data arithmetic and control processing. The storage device 220 is a device for storing programs, data, etc. Programs are read and executed by the processor. The interface device 230 is a device that sends and receives information with a network or other devices, or a device that performs information input and output between a user and a device, etc. The functions of the low-code platform 120 (acquisition unit 221, conversion unit 222, registration unit 223, response unit 224, escalation unit 225, learning unit 226, etc.) are realized by software, hardware, or a combination thereof. The functions of the low-code platform 120 can be realized, for example, by software execution on a computer, hardware implementation using dedicated circuits, or distributed processing utilizing the cloud, virtual machines, etc. Some or all of the functions of the low-code platform 120 may be shared by one or more devices.

[0024] The acquisition unit 221 acquires messages sent from the customer terminal 110 (multiple channels). The acquisition unit 221 acquires messages from at least two channels, including voice channels, email channels, messaging app channels, and online carrier channels.

[0025] The conversion unit 222 converts the message acquired by the acquisition unit 221 into a predetermined data format. The conversion unit 222 extracts customer identification information of the customer using the facility, the start date of facility use, the end date of facility use, the message body, etc., and formats these into a standardized format.

[0026] The registration unit 223 registers the data converted by the conversion unit 222 as ticket information in the integrated management platform 130. The registration unit 223 maintains ticket information, response history, status information, etc., in conjunction with the integrated management platform 130.

[0027] The response unit 224 refers to the response candidates (examples of response knowledge information) stored in the FAQ database 140 and extracts response candidates corresponding to the message. From the extracted response candidates, the response unit 224 selects the most suitable response candidate according to predetermined conditions, and, if necessary, modifies, translates, or converts it to speech to generate a response proposal.

[0028] The escalation unit 225 sends notification data to the internal notification system 150 if the response unit 224 cannot generate an appropriate response, or if conditions requiring emergency response are met.

[0029] The learning unit 226 acquires the operator's response history and determines whether the content is a general-purpose response. The learning unit 226 also adds approved response drafts to the FAQ database 140 and updates the response candidates stored in the FAQ database 140.

[0030] Figure 3 shows an example of a flowchart related to processing in the customer support system 100.

[0031] In steps S301 and S302, the low-code platform 120 receives (acquires) messages sent from the customer terminal 110 via the integrated management platform 130 and executes individual workflows corresponding to each channel. Here, "messages" include various types of information sent by customers, such as inquiries to service providers like accommodations, reservations, and requests. These messages are sent through multiple different channels.

[0032] Channels include, for example, text channels and voice channels. Text channels are means of communication that use text information as a medium, and specifically include messages sent via email, contact forms on websites, messaging applications (e.g., social networking services and chat apps), and the management screens of online travel agencies (OTAs). Voice channels, on the other hand, refer to interactions between customers and service providers via voice calls, and include, for example, the content of telephone conversations.

[0033] For example, text channels can be configured to receive messages sent from each service or system directly using means such as webhooks or APIs. This makes it possible to automatically retrieve messages from email, chat applications, etc.

[0034] Furthermore, with regard to voice channels, voice information can also be obtained by receiving a call via an external voice call service and then linking the recorded data of that call to the low-code platform 120 via a webhook. In this case, the URL of the recorded data notified by the call service, or the voice file itself, may be sent to the low-code platform 120. It should be noted that this embodiment does not exclude configurations in which messages are obtained without going through the integrated management platform 130.

[0035] The low-code platform 120, via the integrated management platform 130, can handle the different receiving methods for each channel, absorb the format differences of the received messages, and format them into a common data format, thereby enabling consistent data handling in subsequent processing steps. Therefore, the low-code platform 120 can be configured to process messages centrally, even if the message source channels are different.

[0036] Furthermore, the low-code platform 120 can automatically determine the type of channel through which a message has passed by referring to metadata (sender address, communication method, protocol type, header information, etc.) associated with the received message. For example, if the sender is an email address, it can be determined to be a "text channel," if it is a telephone number, it can be determined to be a "voice channel," and if it is via an HTTP webhook, it can be determined to be a "messaging channel." However, these classification methods are merely examples, and it is clear to those skilled in the art that other methods of channel determination are also possible.

[0037] In this embodiment, although different processing content exists for each channel, in order to avoid duplication of the description and maintain conciseness, the processing related to the text channel and the audio channel will be described together below. However, if there is processing specific to each channel, it will be explained individually in separate figures (Figures 4 and 5).

[0038] Furthermore, steps S301 and S302 execute the process of acquiring messages corresponding to the multiple channels as described above. Subsequently, in step S303, the messages related to the text channel are converted into a common format (for example, including sender ID, reservation ID, check-in date, body, etc.) and registered or updated via the API of the integrated management platform 130. Meanwhile, in step S304, the recorded data in the voice channel is converted into text, converted into a similar common format, and then registered or updated on the integrated management platform 130. Details of these processes will be described later with reference to Figures 4 and 5.

[0039] In step S305, the low-code platform 120 retrieves the response content executed on the integrated management platform 130 for the target message. The response content includes information such as whether it is an automated or manual response, the response text, the date and time of transmission, the channel used, and the status. If multiple response candidates are presented and one is selected and sent, the selected content is also retrieved. Prior to step S306, the low-code platform 120 may perform a processing target determination (hereinafter referred to as filtering) on ​​the target message. In filtering, it is determined whether the content of the message is suitable for FAQ updates and learning targets, and only if the conditions are met is the message passed as a target for preprocessing. The criteria for determination may include the number of characters, the presence or absence of keywords, and the message type (standard response, sentiment analysis result, channel type, etc.).

[0040] In step S306, the low-code platform 120 performs message preprocessing. Message preprocessing extracts metadata such as the facility name, reservation date (start date, end date, etc.), and customer name from the message, and then structures and normalizes it. The extraction process may use string pattern matching, named entity recognition by an external natural language processing service, or generative processing. In addition, relative date expressions such as "tomorrow" and "the day after tomorrow" are converted to specific dates by referring to the context such as the transmission date and time and the scheduled reservation date. External processing functions for date normalization or generative processing services may be used for this conversion. The resulting preprocessed message is then in a format suitable for subsequent processing (e.g., FAQ search).

[0041] In step S307, the low-code platform 120 determines whether or not an existing response candidate (existing FAQ) exists in the FAQ database 140 for the message that was preprocessed in step S306.

[0042] Specifically, the low-code platform 120 converts normalized messages into document vectors using an external natural language processing service and calculates the semantic similarity with existing FAQs. The similarity evaluation may also be performed by calling APIs of cloud-based machine learning services or vector search services. In addition, the existing FAQs may be indexed in advance on an external vector search service.

[0043] If the similarity is above a predetermined threshold, it is determined that an existing FAQ exists, and the process proceeds to step S308. On the other hand, if the similarity is below the threshold, the message is treated as a candidate for a new FAQ, and the process proceeds to step S309.

[0044] Furthermore, the determination method for this process is not limited to similarity evaluation using document vectors; other natural language processing techniques such as keyword-based matching, edit distance, clustering, and semantic identity evaluation using generative services may also be used. In addition, when transmitting highly confidential content to an external service, the system may be configured to tokenize or anonymize the content before transmission.

[0045] In step S308, the low-code platform 120 executes a process to generate a proposed update to the FAQ if an existing FAQ was detected in step S307. This step consists of the following steps, but is not limited to this embodiment.

[0046] The low-code platform 120 uses an external natural language processing service to convert existing FAQs (questions and answers) and messages into document vectors and perform word clustering to calculate a difference score. Based on words whose scores exceed a predetermined threshold, it extracts attributes to be updated (e.g., temperature conditions, delivery timing, etc.).

[0047] For each extracted attribute, a corresponding template is selected, and prompts are sent to an external generative service containing instructions such as "supplement missing information," "add constraints," and "resolve inconsistencies in terminology" to generate updated drafts of the question and answer texts.

[0048] For example, if the existing question is "Can I have my luggage delivered to the accommodation?" and the existing answer is "Yes, you can. Please arrange for it to be delivered on the day of check-in," and the user then asks "Is it possible to send refrigerated luggage the day before?", the following update proposals may be generated. Suggested question: "Is it possible to have refrigerated items delivered in advance?" Suggested response: "We also accept advance delivery of refrigerated goods. However, due to limited storage space, please contact the facility in advance if you require delivery the day before."

[0049] Furthermore, this process can be applied not only to package delivery but also to other scenarios such as storage of valuables, large packages, and pet-accompanied transport.

[0050] In step S309, the low-code platform 120 executes a process to generate a new draft FAQ if no similarity to existing FAQs was found in step S307. The generated new draft FAQ is abstracted in meaning and generalized in expression so that it can be reused for similar inquiries. The specific configuration and implementation procedure of this process are shown below, but are not limited to this embodiment.

[0051] The low-code platform 120 analyzes the data and response content acquired from steps S301 to S306. The message includes the content of the customer inquiry, and the response content includes the automated response or operator response to the message, the transmission channel, a timestamp, etc.

[0052] The low-code platform 120 uses an external natural language processing service to convert messages and response content into document vectors. Next, it extracts keywords based on word frequency, syntactic structure, occurrence patterns, etc., to identify the subject of the inquiry (e.g., "check-in time," "facility usage," "meal arrangements," etc.).

[0053] The low-code platform 120 matches the extracted keywords with a template dictionary and uses an external generation processing service to select a question generation template that results in a natural syntax (for example, "Is OO available?" or "Does it support OO?") to create candidate questions.

[0054] Furthermore, the response text included in the corresponding response content is also generated using an external generation service or a set of rule-based templates to create an appropriate response. The response text is controlled to include the response policy, precautions, requirements, etc., and polite language is applied to the sentence endings.

[0055] For example, if a customer's message is "Can I work in my room before check-in?" and the operator responds "Yes, you can use your room as a workspace even before check-in," the following new FAQ draft will be generated. Suggested question: "Is it possible to work in my room before checking in?" Suggested answer: "Yes, you can use your room as a workspace even before check-in if you wish. However, please consult with us in advance."

[0056] In step S310, the low-code platform 120 performs a process to temporarily save the FAQ draft (updated draft or new FAQ draft) generated in step S308 or step S309. "Temporary saving" here means that the generated FAQ draft is held in external storage at an intermediate stage before going through the approval workflow.

[0057] Specifically, the low-code platform 120 adds metadata related to the generated FAQ draft (e.g., generation date and time, processing module, original message ID, score information with similar FAQs, author information, etc.) and stores them together in a data structure. The storage location may be external storage such as a spreadsheet service or a workflow management system.

[0058] The format for saving the draft FAQ may be one in which the main text data, including the question and answer, is separated from the metadata. Alternatively, the draft FAQ may be assigned a "status flag" (e.g., unconfirmed / approved / returned / scheduled for discard) to enable management of status transitions.

[0059] Furthermore, to prevent duplication with existing FAQs, full-text search and similarity matching are performed in parallel for new FAQ drafts. If an existing FAQ is detected with a similarity score exceeding a predetermined threshold, the new FAQ draft is rerouted to the update flow in step S308.

[0060] After saving is performed, the low-code platform 120 can record a log of whether saving was successful or unsuccessful in the storage device 220, thereby ensuring traceability during subsequent processing and troubleshooting.

[0061] Furthermore, if approval processing is required for the draft FAQ after temporary saving, the low-code platform 120 may send a notification requesting confirmation to the administrator (approver, operator, etc.) via the internal notification system 150. The notification may include a preview of the draft FAQ, a difference comparison, an approve button, a reject button, etc.

[0062] Furthermore, the low-code platform 120 may include an automatic reminder function in case approval is not given within a certain period for temporarily saved FAQ drafts. For example, it is possible to automatically extract unapproved FAQ drafts after 7 days from the saving date and send a reminder.

[0063] In this way, draft FAQs are not immediately reflected in the production environment after generation, but are temporarily stored and await human review and approval, thereby preventing the circulation of incorrect answers and inappropriate information. Approved draft FAQs may also be registered in the FAQ database 140 and made available for subsequent inquiries.

[0064] Figure 4 shows an example of a flowchart related to text channel processing.

[0065] In step S401, the low-code platform 120 retrieves a message originating from a text channel and executes the workflow corresponding to that channel. Below, we will first explain the processes common to each channel, and then detail the channel-specific processes separately.

[0066] The low-code platform 120 follows a workflow designed for each channel, converting channel-specific input formats (e.g., message body, sender ID, reservation number, transmission date and time, etc.) into a common format usable by common processing. This unifies the interface with subsequent processing.

[0067] Each channel's workflow is individually configured by the workflow building service and is triggered by channel-specific triggers (e.g., incoming email, webhook, external API call, etc.). This allows for the individual absorption of structural differences between channels (message format, header information, parameter configuration, etc.) and standardization into a unified format.

[0068] The standardized messages are then passed to common processing modules such as metadata extraction, response processing, and FAQ search, and used in a series of subsequent processes.

[0069] Furthermore, when a new channel is added, it can be easily expanded without affecting the existing configuration by creating a new workflow specifically for that channel. This design enables flexible and gradual system expansion.

[0070] In step S402, the low-code platform 120 extracts metadata associated with the received message according to the processing defined within the workflow for each channel. In this step, "metadata" includes the message sender, date and time of transmission, reservation-related information, transmission channel, language type, message ID, etc.

[0071] The targets and methods for extracting metadata differ for each channel, and processing is separated within a workflow specific to each channel. Examples of channel-specific processing are shown below.

[0072] (a) In the case of an email channel The low-code platform 120 is configured to extract email header information (e.g., From, To, Subject, Date, Message-ID, etc.). Reservation information contained in the email body (reservation number, check-in date, customer name, etc.) is obtained by entity extraction using regular expressions or an external natural language processing service.

[0073] (b) For messaging app channels The low-code platform 120 extracts user ID, thread ID, transmission date and time, and sending terminal type from the API response provided by the channel. Information such as the date and number of people included in the free-text body may be extracted supplementarily through syntactic analysis.

[0074] (c) In the case of online business channels (e.g., OTA) The low-code platform 120 receives structured data (e.g., reservation ID, stay date, customer category, facility code, etc.) provided by the reservation management platform and directly extracts it as predefined JSON parameters.

[0075] (d) In the case of a dedicated app or form input channel within the facility The low-code platform 120 extracts each input field of the submission form (form ID, input date and time, check-in date, desired conditions, etc.) based on predefined labels. If the form structure is defined, it is configured to map and process the corresponding fields.

[0076] (e) Common completion processing In either channel, the low-code platform 120 can refer to a natural language processing model trained on historical data and perform metadata completion processing from abbreviated and colloquial expressions.

[0077] The extracted metadata is stored in key-value format and used as contextual support data in subsequent steps S403 (message normalization) and S404 (registration processing). Furthermore, the extraction patterns and settings for each channel are configured to be updatable by the administrator via an external configuration file or the configuration screen of the low-code infrastructure 120.

[0078] In step S403, the low-code platform 120 performs message normalization processing based on the metadata extracted in step S402 and the message body obtained in step S301, etc. This step is a process that arranges a message written in natural language into a structure and format suitable for subsequent processing, and performs grammatical formatting, vocabulary unification, numerical conversion, and semantic attribute assignment in cooperation with the external system 160 (external service). The processes described below may be configured to be executed selectively depending on the channel type or content.

[0079] The low-code platform 120 works in conjunction with an external natural language processing service (e.g., a generative service) to format fragmented or ambiguous message sentences into a form that expresses a clear intent. For example, a simple sentence like "Can I cancel?" could be converted into a sentence with a clear meaning, such as "Is it possible to cancel the reservation?".

[0080] The low-code platform 120 refers to a domain-specific dictionary or synonym mapping list to unify vocabulary variations, performing replacement processes such as changing "check-in (half-width)" to "check-in (full-width)". The dictionary can utilize a vocabulary system built from FAQ history and operational logs.

[0081] Relative date expressions (e.g., "next Tuesday") and quantitative expressions (e.g., "two or three people") included in the message may be converted into a quantitative, machine-readable format, such as "July 23, 2025" or "Number of people: 2-3," in cooperation with an external natural language parser or date normalization engine.

[0082] The low-code platform 120 uses an external entity extraction API to assign part-of-speech tags and semantic labels to named entities (e.g., "baby crib," "early check-out"), which are then used in subsequent FAQ searches or response generation.

[0083] The low-code platform 120 is configured to translate normalized messages into a common language (e.g., Japanese) using an external translation service when multilingual support is required, and to add the source language information and confidence score obtained at that time as metadata.

[0084] In this way, unstructured natural language messages are structured and normalized through processing in cooperation with the external system 160, thereby improving accuracy and efficiency in processing from step S404 onward (registration processing, FAQ search, response processing).

[0085] In step S404, the low-code platform 120 executes the process of registering the normalized message from step S403 with the integrated management platform 130. The integrated management platform 130 is a system for centrally managing inquiries and response status from multiple channels, and includes inquiry history, priority, and status management functions.

[0086] The low-code platform 120 interacts with the integrated management platform 130 via a predetermined interface (e.g., an API) to perform registration processing. The registration information may include a normalized message body, a sender identifier (such as the user ID of the customer terminal 110), channel type, and transmission date and time, as well as additional information such as priority and classification tags. This additional information may be configured to be transmitted in association with predefined custom fields.

[0087] The registration process creates one inquiry ticket in the integrated management platform 130 and assigns it a ticket ID. This ticket is then linked to and handled in subsequent response generation, FAQ draft generation, or response recording processes.

[0088] The integrated management platform 130 includes a function to notify or display registered tickets through an operator interface (dashboard screen, chat screen, etc.). Operators can perform actions such as reviewing ticket content, editing responses, and updating response status.

[0089] Furthermore, this process is not limited to a configuration that is always performed for all messages; it may be omitted depending on the channel type and the nature of the message content. In addition, the registration items and registration timing can be switched according to the settings and operational policies of the integrated management platform 130.

[0090] In step S405, the low-code platform 120 performs a process to determine whether or not an AI (Artificial Intelligence) response to the message is possible. The purpose of this process by the low-code platform 120 is to comprehensively evaluate whether or not the content of the message is suitable for an automated response, thereby ensuring response accuracy and reducing business risks.

[0091] The low-code platform 120 takes the messages acquired and formatted in steps S402 and S403 as input, and works in conjunction with the external system 160 (the external judgment module described below) to make a comprehensive determination of whether or not an AI response is possible.

[0092] (a) Presence or absence of similar FAQs The low-code platform 120 converts messages into document vectors and calculates the similarity to existing FAQs registered in the FAQ database 140, in cooperation with an external natural language processing service or vector search service (vector DB). The low-code platform 120 determines that a similar FAQ exists if the similarity is above a predetermined threshold.

[0093] (b) Evaluation of response confidence score The low-code platform 120 uses an external natural language processing service to generate multiple response candidates for a message. Next, the low-code platform 120 has the external service perform a process to calculate a confidence score based on the consistency, logic, presence or absence of ambiguity, and consistency with the response history of these candidates, and retrieves this score.

[0094] (c) Detection of response prohibition conditions and response hold conditions The low-code platform 120 uses external topic classification models, keyword dictionaries, and entity extraction APIs to determine whether the message body contains confidential information, potentially misleading information, or expressions that may violate laws and regulations. If the low-code platform 120 determines that such content is present, it decides that the automated response should be suppressed.

[0095] The low-code platform 120 integrates the judgment results from (a) to (c) above as a score or judgment flag obtained from an external judgment API and makes a final judgment on whether a response is possible or not. At this time, the low-code platform 120 synthetically evaluates whether the AI ​​response is valid or not based on the features obtained from the external service.

[0096] If the low-code platform 120 determines that the AI ​​response is acceptable as a result of the judgment, it proceeds to step S406. On the other hand, if the low-code platform 120 determines that the AI ​​response is inappropriate or should be postponed, it proceeds to step S409.

[0097] Furthermore, the low-code platform 120 is configured to dynamically update the evaluation criteria used for determining whether a response is possible, based on the operational policies and response performance data of the deployment site, in conjunction with the integrated management platform 130. In addition, the low-code platform 120 can attach metadata such as an urgency flag and a confidence score to the response judgment result, and this metadata can be used as control conditions in subsequent processing.

[0098] In step S406, the low-code platform 120 executes a process to generate response candidates for the message. First, the low-code platform 120 calculates the similarity between the message and existing FAQs registered in the FAQ database 140. The low-code platform 120 uses an external natural language processing service to convert the message and existing FAQs into vector format, and then evaluates the similarity (e.g., cosine similarity) using a vector search index.

[0099] When the low-code platform 120 detects an existing FAQ with a similarity score above a predetermined threshold, it uses the answer text of the existing FAQ as is, or with minor edits, as a response candidate. If editing is necessary, the low-code platform 120 uses an external natural language processing service to rewrite the existing answer (unifying the tone and adjusting the context). This improves the stability of response quality and operational efficiency.

[0100] On the other hand, if the low-code platform 120 does not find a suitable existing FAQ, or if it determines that an existing answer is inconsistent with the context of the message, it sends a prompt to the natural language processing service to generate a new response candidate. At this time, the low-code platform 120 configures the prompt to include metadata such as the transmission channel, user attributes, and past response history in addition to the message body, and controls it to obtain contextually appropriate output.

[0101] The low-code platform 120 scores the generated multiple response candidates from the perspectives of confidence score, diversity of expression, length, and tone (e.g., polite / casual), and selects one or more response candidates that meet predetermined conditions. The low-code platform 120 is configured to incorporate company policies and constraints (e.g., not specifying the price, making the required time ambiguous, etc.) into the prompt as needed, or to apply filtering to the generated results.

[0102] In step S407, the low-code platform 120 determines whether fallback (human response verification) is necessary for the response candidates generated in step S406. This process evaluates whether the quality of the response candidates is sufficient and whether they can be automatically sent to the customer as is. The low-code platform 120 comprehensively evaluates the necessity of fallback from the following perspectives.

[0103] (a) Threshold determination of confidence score The low-code platform 120 determines whether the confidence score assigned to the response candidate is below a predetermined threshold, and if it falls below the threshold, it determines that a fallback is necessary.

[0104] (b) Presence or absence of risk statement The low-code platform 120 detects whether the response candidate text contains high-risk words related to medicine, law, contracts, safety, etc., or ethically or emotionally impactful language (e.g., "anger," "anxiety," "sarcasm," etc.). If detected, it determines that a fallback is necessary to avoid misunderstandings and problems.

[0105] (c) Detection of ambiguous expressions or misgenerations The low-code platform 120 evaluates whether the response candidates contain ambiguous expressions (such as "maybe" or "it might be") or obviously grammatically unnatural descriptions, and if so, it targets the fallback option.

[0106] The low-code platform 120 may perform the above evaluation process using rule-based filters configured for each channel, or it may perform it using a machine learning model with an external natural language processing service. In the case of a machine learning implementation, the low-code platform 120 is configured to send response candidates and their metadata to a classification API (for example, a pre-trained external classification model) and receive a binary classification of "automatic submission possible" or "human verification required".

[0107] If the low-code platform 120 determines, based on the evaluation results, that fallback is unnecessary (i.e., automatic response is possible), it proceeds to step S408. On the other hand, if it determines that fallback is necessary, it proceeds to step S409.

[0108] The application of evaluation items and the setting of thresholds can be adjusted according to the target business, customer service policy, and past performance. Furthermore, evaluation items can be added or removed in the future, allowing for a scalable structure.

[0109] In step S408, the low-code platform 120 processes the response candidates generated in step S406, formatting the response body in a format appropriate to the channel type of the message, and sending it to the customer terminal 110. In this process, the low-code platform 120 controls its operation by referring to the channel type determined in step S401 and the metadata extracted in step S402. This process in the low-code platform 120 is configured as a workflow defined individually for each channel, and different processing routes and templates are executed depending on the channel type. This makes it possible to generate a response format that is suitable for the channel characteristics. The low-code platform 120 formats the response candidates according to the following template rules depending on the channel type.

[0110] (a) In the case of an email channel Low-code platform 120 conforms to the MIME format and generates an email structure including a subject, recipients (To, Cc). The body of the email includes links, explanatory text, and paragraph structure to ensure both readability and reliability. For example, it might say, "Please enter your request using the link below," and insert a form URL.

[0111] (b) For messaging app channels The low-code platform 120 constructs the response body as a short sentence and, if necessary, adds interactive elements such as selection buttons and dropdowns via chat actions or external chat integration services before sending it. For example, in response to "Please select a check-in time," it presents options such as [15:00-17:00].

[0112] (c) In the case of online business channels (e.g., OTA) The low-code platform 120 conforms to the structured templates provided by the OTA and generates a message structure that combines information such as the reservation ID and facility code with the response body. It works in conjunction with the integrated management platform 130 to send the response linked to the reservation case to the appropriate UI area.

[0113] (d) In the case of an in-facility app or form channel The low-code platform 120 formats the response text in an "input assistance" or "supplementary display" format according to predefined form items and UI structure, and outputs it to the corresponding field in the application. For example, it sends the response in a format that supplements the answer to the "request field."

[0114] As a preprocessing step for response formatting, the low-code platform 120 reads template structures (punctuation rules, line break rules, honorific language settings, word substitution rules, etc.) corresponding to each channel type from the template management module and formats the response candidates accordingly. The low-code platform 120 also adds annotations such as "This message was automatically generated by AI" or feedback prompts such as "Did this answer solve your problem?" to the end of the message as needed.

[0115] The low-code platform 120 may be configured to centrally manage template structures and channel definition information within the integrated management platform 130, allowing operators to register and modify new channel templates through a settings screen.

[0116] Note that the channel support for this processing is just an example, and it is not necessary to apply it uniformly to all messages. The low-code platform 120 can flexibly switch processing content and transmission format according to operational policies and channel characteristics.

[0117] In step S409, the low-code platform 120 executes a notification process to prompt human verification of the response. This process is performed when it is determined that human verification is necessary due to the risk, ambiguity, or unreliability of the response, and enables operator intervention by notifying the relevant parties.

[0118] The low-code platform 120 registers messages and response candidates, as well as related metadata (inquiry channel, user ID, message ID, estimated category, priority, etc.) with the integrated management platform 130. This prepares the foundational information for subsequent operator processing.

[0119] The low-code platform 120 sends notifications to pre-configured facility staff or operators via the internal notification system 150 based on the registered information. The notification content may include information such as a summary of the message body, AI-generated response suggestions, channel type, estimated category, confirmation deadline, response deadline, and notification level.

[0120] Upon receiving a notification, the operator can view the message and suggested responses through the user interface of the integrated management platform 130 (for example, the dashboard screen). Depending on the content, the operator can modify, add to, replace the suggested responses, instruct the response to be held or discarded, or add supplementary information.

[0121] The presence and timing of notification processing in this step are controlled by the workflow settings for each channel. Conditional branching for notification requirements can be set according to operational policies, industry requirements, and response risk levels; it is not necessary to process notifications for all messages.

[0122] Furthermore, notification methods (email notifications, chat notifications, pop-up notifications, etc.), notification priority settings, and confirmation flows (whether or not primary / secondary confirmation is required) can be modified and expanded by operators through the integrated management platform 130.

[0123] In step S410, the low-code platform 120 executes a process to save the transmitted response content as a response record to a storage device such as the integrated management platform 130, the FAQ database 140, or external storage. Through this process, the low-code platform 120 enables traceability of the response history, quality control, and accumulation of datasets for retraining.

[0124] The low-code platform 120 can be configured to store the following information as data to be recorded in a structured data format (for example, JSON format).

[0125] (a) Response body (sent text, links, button definitions, etc.) (b) Information used when generating the response (such as template identifier used, referenced FAQ identifier, and version of the generation model) (c) Transmission metadata (sending date and time, channel used, customer ID, thread ID, etc.) (d) Processing path (response status determination result in step S405, fallback determination result in step S407, etc.) (e) Whether or not an operator was involved (whether or not it was via step S408 or step S409)

[0126] The low-code platform 120 organizes this information into a standardized format based on the specifications for integration with the integrated management platform 130 and transmits it. The integrated management platform 130 adds this to the ticket information and records it as a single response history.

[0127] The integrated management platform 130 is configured to store recorded response content as comment information that operators can view on the screen, and to provide it for referencing response history and assisting in decision-making.

[0128] Here, the customer support system 100 may maintain the response mode (human-priority mode or AI-priority mode) set on the management screen and refer to the response mode immediately after channel determination (step S401) to determine the initial responder. In the case of human-priority mode, the customer support system 100 does not automatically send the generated AI response candidates, but holds them in an operator confirmation waiting queue, and proceeds to send them after a predetermined time has elapsed or when an operator is detected to be absent.

[0129] The customer support system 100 is configured to automatically send a response immediately if the AI ​​response is deemed acceptable when the response mode is AI-priority mode, and to transition to fallback only if there are unsuitable or pending conditions. If the response mode is changed in the middle of a conversation, the customer support system 100 applies the change to subsequent turns and records the date and time of the change and the operator as part of the response content. Furthermore, when making decisions in steps S405 and S407, the customer support system 100 may evaluate multiple rule groups (similar FAQ threshold rules, prohibited or urgent keyword rules, confidence score lower limit rules, etc.) in order of priority and record the applied rule ID and match reason (corresponding word, score value, threshold comparison result) in the decision log.

[0130] The customer support system 100 can facilitate subsequent audits or threshold adjustments by associating the ID of the judgment log with the summary record described later. Furthermore, the system may be configured to omit the evaluation process for low-priority rules when prohibition or emergency keyword rules are applied.

[0131] Figure 5 shows an example of audio channel processing.

[0132] In step S501, the low-code platform 120 executes a workflow corresponding to the voice channel, initializes the voice processing environment corresponding to the voice channel, and acquires information and establishes a connection for subsequent processing. This step is executed when an outgoing or incoming call event from a customer is detected.

[0133] (a) Connection establishment and session identification process The low-code platform 120 receives a webhook notification from an external voice call service (e.g., a cloud PBX) and obtains an identifier (call_id) that identifies the call session.

[0134] (b) Initial acquisition of call log information The low-code platform 120 acquires metadata included in the notification, such as the caller ID, recipient ID, call direction (inbound / outbound), call start date and time, and operator ID, and stores this information as identification for call session management.

[0135] (c) Initialization process for receiving audio data The low-code platform 120 is configured to start a separate process for preparing to receive audio streaming (e.g., WebSocket connection) in order to cooperate with an external service that handles speech recognition processing. Audio segment extraction and speech recognition (ASR: Automatic Speech Recognition) processing are performed on the external service side.

[0136] (d) Initial analysis of voice quality and language type The low-code platform 120 determines the recognition language (Japanese, English, etc.) based on voice metadata acquired immediately after the start of a call or predefined customer settings, and logs the noise level and SNR (Signal to Noise Ratio) as needed.

[0137] In this way, in step S501, preparatory processing prior to real-time voice processing is performed, resulting in a configuration that smoothly connects to the subsequent steps S502 and beyond.

[0138] In step S502, the low-code platform 120 works in conjunction with an external speech processing engine to perform segment separation processing on the acquired speech data at the utterance level. This process divides the speech data into appropriate units in preparation for subsequent speech recognition processing and response generation processing.

[0139] The low-code platform 120 transmits audio data to an external audio processing engine in real time or in batch format, and performs voice activity detection (VAD) and energy change analysis. Speaker clustering (speaker diarization) processing is also used as needed.

[0140] The speech processing engine automatically divides continuous speech data into utterances and assigns metadata to each speech segment, including the start date and time, end date and time, estimated speaker label (such as "customer" or "operator"), and confidence score. The low-code platform 120 receives this metadata and uses it as auxiliary information for contextual understanding in speech recognition and subsequent processing.

[0141] The low-code platform 120 will integrate with cloud-based commercial services and open-source speech recognition engines as its voice processing engines.

[0142] In use cases where voice segment separation is not required (for example, tasks that process the entire call in one go), it is permissible to omit some or all of this step. Furthermore, this process is just an example, and the configuration should be flexible and changeable depending on the type of voice channel and the external voice processing engine used.

[0143] In step S503, the low-code platform 120, in cooperation with an external speech recognition engine, performs speech-to-text (ASR) processing for each speech segment separated in step S502. The low-code platform 120 obtains the utterance content obtained through this processing as natural language text and passes it on to the subsequent semantic understanding and response processing.

[0144] The low-code platform 120 sequentially transmits each voice segment to the speech recognition engine and obtains the corresponding text (utterance) and confidence score. If the confidence score falls below a predetermined threshold, the low-code platform 120 may be configured to output multiple candidate sentences or trigger a response hold process.

[0145] The low-code platform 120 can utilize cloud-based or on-premise external services as its speech recognition engine. The low-code platform 120 is configured to improve recognition accuracy by linking these services with predefined specialized terminology dictionaries and language models.

[0146] The low-code platform 120 stores the output results of speech recognition in a structured format (e.g., JSON) that includes metadata such as text, start date and time, end date and time, speaker label, and confidence score. This allows it to be used as contextual information in the subsequent steps S504 (message normalization) and S505 (registration process).

[0147] In step S504, the low-code platform 120 performs message normalization processing based on the speech recognition results (text) obtained in step S503. Through this process, the low-code platform 120 converts unstructured text written in natural language into a structured format suitable for subsequent processing, and prepares it into semantically and syntactically organized data. The low-code platform 120 is configured to perform the following sub-processes in stages.

[0148] (a) Sentence structure formatting The low-code platform 120 uses an external natural language processing service to reshape colloquial and fragmented utterances (for example, "Um, so... can I cancel that?") into clear sentence structures such as "Can I cancel my reservation?".

[0149] (b) Vocabulary normalization The low-code platform 120 unifies vocabulary variations originating from speech recognition (such as "chekuin" and "chekkuin") into standard vocabulary (such as "check-in") based on dictionary information linked with the FAQ database 140, etc.

[0150] (c) Format conversion of numbers, dates, etc. The low-code platform 120 works in conjunction with an external normalization module to convert vague expressions such as "about three people" or "next Tuesday" into formats such as "Number of people: 3" and "July 22, 2025".

[0151] (d) Addition of semantic attributes The low-code platform 120 uses an external natural language processing service to add part-of-speech information and labels (facility name, service name, etc.) to important words (e.g., "extended stay," "breakfast," etc.) in order to improve matching accuracy.

[0152] (e) Machine translation (if necessary) If the low-code platform 120 determines that multilingual support is necessary, it performs machine translation on the normalized message and adds the original language information and confidence score as metadata to the translated text.

[0153] The low-code platform 120 generates the message as described above and provides it for registration in step S505. This normalization process may be configured to omit or replace some sub-processes as needed.

[0154] In step S505, the low-code platform 120 executes the process of registering the normalized message from step S504 with the integrated management platform 130. The data registered by the low-code platform 120 includes the normalized message body (output from step S504), speaker tag ("customer" or "operator"), call ID (session ID), segment start and end dates and times, speech recognition confidence score, channel type (voice channel), flags related to priority or urgency, and message classification tags (category, intent label, etc.).

[0155] The integrated management platform 130 is configured to handle information registered from the low-code platform 120 as "records per conversation segment" for each inquiry ticket. This allows operators and subsequent automated response processing modules to refer to the response history in chronological order while preserving context.

[0156] The integrated management platform 130 displays ticket information on the dashboard screen and notification interface upon completion of the registration process, assisting operators in reviewing, correcting, or updating the status of responses.

[0157] Note that the message registration process in this step does not necessarily need to be performed for all voice segments; depending on the channel settings, utterance content, or operational policy, some processing may be omitted or performed in a batch.

[0158] In step S506, the low-code platform 120 performs a process to determine whether or not an AI-based automated response to the message is possible, based on the message normalized in step S504.

[0159] The logic for determining whether an automatic response is possible in this step is generally the same as in step S405 in the text channel, but additional or complementary elements are added, taking into account that the message originates from voice.

[0160] (a) Reference of speech recognition confidence The low-code platform 120 is configured to consider the confidence score included in the speech recognition result obtained in step S503 as a risk factor that should prevent automatic response if it falls below a predetermined threshold, and to reflect this as a negative factor in the AI ​​response feasibility determination. This helps to suppress inappropriate responses caused by misrecognition.

[0161] (b) Detection of speech interruption and re-entry The low-code platform 120 is configured to temporarily suspend or suppress the decision to apply an AI response if it detects that the same utterance has been repeated in a short period of time within the same call session, considering the possibility that the repetition is a "re-utterance due to failure to recognize."

[0162] (c) Adjustment of judgment based on speaker attributes (optional) The low-code platform 120 may be configured to refer to the speaker clustering results in step S502 (for example, attribute estimation such as "elderly person" or "repeat user") and dynamically adjust the acceptable threshold or response criteria for automatic response according to the speaker's attributes.

[0163] The above judgment process can be configured using either rule-based processing, a machine learning model, or a combination of both. Furthermore, the addition of evaluation metrics that take into account the ambiguity and misunderstanding risks specific to audio channels is also permitted.

[0164] In step S507, the low-code platform 120 executes a process to generate response candidates for the inquiry content in the voice channel. This process is basically the same as in step S406 in the text channel, and response candidates are generated either by reusing existing FAQs or by generating new ones using a natural language processing service.

[0165] The low-code platform 120 first determines whether there are existing FAQs in the FAQ database 140 that are similar to the voice-derived message normalized in step S504. For this similarity determination, a pre-trained embedded model is used to convert the message and existing FAQs into vector representations, and then compare them using metrics such as cosine similarity.

[0166] If the low-code platform 120 confirms a high degree of similarity with an existing FAQ, it reuses the answer text from the existing FAQ as a response candidate, either as is or with some editing. On the other hand, if it determines that no suitable existing FAQ exists or that the context is not well-suited, the low-code platform 120 requests the natural language processing service to generate a new response candidate by constructing a prompt that includes the message body as well as relevant metadata such as the voice channel type, call start date and time, speaker attributes, and past response history.

[0167] The low-code platform 120 allows the configuration of this process to be dynamically changed according to the channel type, operational policy, or business requirements. For example, it may be configured to use multiple natural language processing services in combination and output different responses depending on the style (polite / casual) and length (short / detailed) of the response candidates. Alternatively, the response candidates may be configured to include confidence scores and generation rationale information, which can be used to make selection decisions in the next step.

[0168] In step S508, the low-code platform 120 performs a process to determine whether an automatic response is possible for the response candidates generated in step S507. This process has basically the same configuration as step S407 in Figure 4, and the decision is made comprehensively based on response confidence, ambiguity, presence or absence of prohibited words, etc. The difference in step S508 is that, depending on the fallback determination result, the system transitions to either step S509 (AI response transmission) or step S510.

[0169] In step S509, the low-code platform 120 processes the response candidates generated in step S507 into a format suitable for the characteristics of the voice channel and sends them to the customer terminal 110. The low-code platform 120 configures the voice transmission process according to the following procedure.

[0170] (a) Speech synthesis processing The low-code platform 120 sends the response text to a predetermined speech synthesis engine (for example, a cloud-based speech synthesis service) to generate speech data. At this time, parameters such as speech rate, voice type (male / female), and intonation are set based on channel setting information or a template.

[0171] (b) Voice transmission process The low-code infrastructure 120 transmits the synthesized voice data to the customer terminal 110 in streaming format via a voice channel (public switched telephone network, mobile phone network, or VoIP infrastructure). To ensure communication quality, the voice data is transmitted sequentially in a split buffer format.

[0172] (c) Addition of automated response notes and metadata The low-code platform 120 adds a note to the end of the audio such as "This response was automatically generated by AI," and adds metadata such as ticket ID, transmission date and time, and speaker type to the entire response. This information is used in the response recording process in the subsequent step S512.

[0173] The low-code board 120 may be configured to interrupt the output and transition to step S502 if an interrupt voice message from the user is detected during audio output. Furthermore, this processing configuration can be expanded in the future to include multimodal output, such as using it in conjunction with a visual channel (text display) or branching the output format according to user attributes.

[0174] In step S510, the low-code board 120 performs call forwarding. Call forwarding is performed by bridging the customer call on the voice channel directly to the operator's terminal (such as the facility staff's extension number). The forwarded call is then handled by the operator. The conditions for call forwarding and the forwarding destination can be flexibly changed according to channel setting information, facility type, business hours, and the assigned staff member's schedule.

[0175] In step S511, the low-code board 120 performs notification processing when the operator's call ends.

[0176] The low-code platform 120 works in conjunction with the integrated management platform 130 to send information related to the target message in a format that facility staff can refer to. The transmitted content includes text obtained by speech recognition, a summary of the text, and metadata (speaker type, utterance date and time, confidence score, call ID, etc.).

[0177] The low-code platform 120 notifies facility staff and shares information through a dashboard screen on the integrated management platform 130 or through notification messages linked to the internal notification system 150. To ensure immediacy, these notifications are sent to pre-configured recipients, enabling them to perform actions such as making calls or placing calls on hold.

[0178] Furthermore, this notification process can be configured according to the urgency of the response or the user's attributes. The recipients of notifications and the notification methods can also be flexibly configured in accordance with operational policies.

[0179] In step S512, the low-code platform 120 performs the process of saving the content of the response in step S509 or step S511 as a response record to a storage device such as the integrated management platform 130, the FAQ database 140, or external storage. This process is essentially the same as step S410 in the text channel and aims to ensure traceability of the response history, quality evaluation, and data accumulation for future model improvements.

[0180] The low-code platform 120 works in conjunction with the integrated management platform 130 to register each item of the response record as structured data. This may include the response body (text content before voice transmission), a response type flag indicating that it is a voice response, a call ID, a voice segment ID, and playback timing information such as the start and end dates and times of the corresponding speech synthesis process, as well as information on the name of the speech synthesis engine used and a template identifier.

[0181] The low-code platform 120 communicates the above information with the integrated management platform 130 according to a predetermined interface specification and records it linked to the ticket ID. This allows operators to centrally refer to past response history, regardless of channel type, on the screen of the integrated management platform 130.

[0182] Furthermore, it is desirable that the low-code infrastructure 120 complementarily acquires information specific to the voice channel (segment identifier, playback date and time, etc.) from the corresponding TTS engine or PBX API response and incorporates it in log format. In addition, if the external TTS service does not explicitly provide version information, the engine name and call date and time may be recorded as alternatives.

[0183] In step S513, the low-code board 120 performs a process to determine whether or not to continue the call.

[0184] The low-code platform 120 determines whether or not to terminate the session in the audio channel based on one of the following conditions.

[0185] (a) No response to voice input The low-code platform 120 assumes the user has left if no new input (voice or DTMF signal) is detected within a certain period of time.

[0186] (b) Explicit termination request The low-code platform 120 determines that a call has ended when speech recognition detects that the user's utterance includes an intention to end the call, such as "That's all" or "I'm fine now." While the system may also use natural language processing for call termination, this implementation is achieved in conjunction with an external natural language processing service.

[0187] (c) System control instructions The low-code platform 120 performs a control determination to terminate the call if the maximum number of dialogues is exceeded or a processing timeout occurs.

[0188] If it is determined that the call should continue, the low-code platform 120 returns to step S502 and resumes the process of receiving the voice segment. If it is determined that the call should end, the call session is terminated.

[0189] In this embodiment, the customer support system 100 may generate a summary record and send it to the internal notification system 150 when any of the following triggers occur. (a) When the audio channel session ends (b) When the AI ​​detects insufficient training data, an emergency, or an exceptional event. (c) When the response performed by a human is determined by the AI ​​to be a general response candidate. (d) When it is determined that a human interaction is essential for a category (e.g., reservation changes, cancellations)

[0190] The customer service support system 100 may be configured to summarize the recorded content or response history when a trigger occurs, and to integrate the summary record into the existing response record. In this case, the summary record may be configured to be recorded in a structured format and may include customer name or pseudonym, reservation ID, facility ID, channel type, initial responder, final sender, start date and time, end date and time, processing time, whether translation was performed, trigger type, classification tag, important utterances excerpt, AI confidence score, model ID used, and text with personal information masked.

[0191] Furthermore, it is desirable that detailed processes such as the confirmation process for FAQ update candidates, approval status, and difference detection be handled separately in conjunction with an external FAQ management system or application for recording and operation.

[0192] Figure 6 shows an example of a flowchart related to the learning process.

[0193] In step S601, the low-code platform 120 works in conjunction with the integrated management platform 130 to perform a process that enables UI operations to prompt the administrator to approve the response candidates.

[0194] Specifically, the low-code platform 120 transmits response candidates and related information (customer utterances, trust score, channel type, etc.) in a predetermined format to the integrated management platform 130, and a custom application on the integrated management platform 130 (for example, a dedicated confirmation widget) displays the UI screen.

[0195] In this case, the integrated management platform 130 may be configured to provide a UI on the dashboard screen that includes displaying response candidates, approval / denial operation buttons, and a memo input field for the approval result.

[0196] In this process, the low-code platform 120 does not perform the user interface display processing itself, but rather plays a role in coordinating with external applications through the processing of sending approval information to external applications (such as calling webhooks or registering in a database). An example of the UI screen configuration will be described later using Figure 7.

[0197] In step S602, the low-code platform 120 works in conjunction with the integrated management platform 130 to receive the operation details from the administrator and control the transition to the subsequent process based on those details.

[0198] Specifically, administrators can perform the following operations on a custom application (UI screen) configured on the integrated management platform 130.

[0199] (a) "Approve" operation If the administrator determines that the proposed response can be sent as is, the integrated management platform 130 assigns an "approved" flag to the response and sends the information to the low-code platform 120.

[0200] (b) “Rejection” operation If the administrator determines that a candidate response is inappropriate or insufficient, the integrated management platform 130 sends a rejection instruction along with any rejection reason comments to the low-code infrastructure 120.

[0201] (c) "Modify" operation If the administrator makes minor corrections to a response candidate, they enter the changes in the editing text field and press the "Modify + Approve" button, after which the revised content is sent to the low-code platform 120.

[0202] (d) "Add Label" operation (optional) Administrators can add attribute labels such as urgency, response type, and warning using checkboxes or dropdown selections. This information is also passed to the low-code platform 120 and used for response logging and FAQ learning processing.

[0203] Furthermore, the integrated management platform 130 may be configured to display the original message, similar FAQs, past response history, etc., on the UI as criteria for determining response candidates.

[0204] Furthermore, the operational items in this step can be flexibly expanded or omitted depending on the settings or operational policies on the integrated management platform 130.

[0205] In step S603, the low-code platform 120 performs a process to update the FAQ database 140 based on the response content that was "approved" by the administrator in step S602.

[0206] In this embodiment, the FAQ database 140 is configured as an external structured database (for example, a business management tool or spreadsheet platform), and the low-code platform 120 registers the following information in cooperation with the database.

[0207] The information to be registered includes the question text (user inquiry), the answer text (approved final response), channel type, category, registration date and time, operator ID, template identifier used to generate the response, generation model version, and link information for similar FAQs (ID or cluster ID of existing FAQs with high similarity).

[0208] The low-code platform 120 converts this information into a structured format (e.g., JSON format) defined by the FAQ database 140 and executes the registration process using a predetermined Web API or application integration function.

[0209] Furthermore, if the similarity to an existing FAQ exceeds a certain threshold, the low-code platform 120 may, in cooperation with the integrated management platform 130, display a confirmation screen to the administrator indicating "Notification of the existence of a similar FAQ" or "Potential duplication." In addition, to ensure the traceability of FAQ updates, the low-code platform 120 may be configured to record the difference information before and after the change as history and save it as an update history log.

[0210] The update destination and registration format for this process can be changed as appropriate depending on the operational policy or FAQ management environment.

[0211] In step S604, the low-code platform 120 records a processing log for the response candidates that were rejected by the administrator in step S602. This process aims to save the operational history and reasons for rejection, and to contribute to future improvements in response quality, improvements to the generation model, or analysis of operator decision trends.

[0212] The low-code platform 120 records information to be rejected in the following format: the target message ID, rejected response candidate, operator ID (or name), rejection date and time, rejection reason (free text field), corresponding channel type, confidence score, template identifier, generation model version, etc., and the recording format is JSON or CSV.

[0213] The low-code platform 120 stores this information as structured data and links it to an external database for analysis (for example, a business management spreadsheet or a cloud-based analytics platform). The linking process is configured to relay the output data from the low-code platform 120 and transmit it via the integrated management platform 130 or an external recording service.

[0214] Furthermore, the recorded data is regularly analyzed and used to improve the accuracy of AI responses, revise templates, and optimize criteria for human intervention.

[0215] Furthermore, the recorded items, storage format, recording period, and viewing permissions can be flexibly changed based on system settings or information security policies. It is desirable to restrict log access permissions at the storage location and implement measures to prevent tampering, as needed.

[0216] Figure 7 shows an example of a screen (UI screen 700) related to the approval of response candidates. The integrated management platform 130 configures UI screen 700 on the dashboard and presents it as an operation screen for administrators to approve or reject response candidates. UI screen 700 includes the following information and operation elements. The display content of each item is configured based on data provided by the low-code platform 120.

[0217] (a) Question section The integrated management platform 130 displays messages (questions) that have been normalized by the low-code platform 120. For example, if the original user message was "Excuse me, can I change my check-in time?", the same field will display a generalized question such as "Can I change my check-in time?".

[0218] (b) Answer section The integrated management platform 130 displays response candidates generated or extracted by the low-code infrastructure 120. Examples of such responses include: "The time can be changed between 15:00 and 17:00. Please let us know your preferred time."

[0219] (c) Administrator Actions The integrated management platform 130 provides the following operational elements for administrators to review and modify response candidates: • "Edit Answer" input field: For manually correcting answers. • "Comments" input field: A field for describing the reasons for rejection or the intention to revise.

[0220] (d) Related Links The integrated management platform 130 displays the following links to supplement the information used for decision-making. • "See actual interactions": Customer response history, past chat history, links to similar cases • "Show similar FAQs": A link to a screen where you can view existing FAQs that are highly relevant.

[0221] (e) Approve / Reject button The integrated management platform 130 presents action buttons to allow administrators to make decisions to approve or reject.

[0222] The integrated management platform 130 may be configured to incorporate supplemental metadata (such as channel type, user ID, response confidence score, generation model version, and whether or not fallback is determined) on the UI screen 700 in an abbreviated or collapsed display format, and to be expandable as needed.

[0223] Furthermore, the integrated management platform 130 allows for customization of the UI screen's display layout and item configuration according to operational policies or user permissions. For example, it is possible to adopt a configuration that adds warning labels and color coding to response candidates that are judged to be high risk. The integrated management platform 130 is configured to record all operations on the UI screen (approval / rejection of responses, edits, comments, etc.) as logs, which can be used for subsequent analysis or tracking processes.

[0224] According to this embodiment, operators are freed from cumbersome tasks that were previously required, such as checking information for each channel, manual input, language conversion, and internal escalation, enabling them to efficiently handle inquiries across multiple channels with a small number of people and in a short amount of time.

[0225] For example, even in busy situations where one operator is simultaneously handling phone calls and messaging app inquiries, this embodiment automatically performs a series of processes from message acquisition to formatting, response candidate generation, and internal sharing, thereby minimizing human error and delays in response.

[0226] Furthermore, the transcription and summarization function of voice calls allows other operators to grasp the gist of the conversation in real time, facilitating smooth handovers and simultaneous responses, and increasing the flexibility of the organization's overall response system.

[0227] Furthermore, the system, which allows operators to individually handle customer interactions and then accumulate them as knowledge after approval, prevents individual expertise from becoming dependent on specific individuals, thereby promoting an overall improvement in customer service quality and continuous improvement.

[0228] As a result, it can contribute to improving overall customer satisfaction at the facility, speeding up complaint handling, reducing staff training costs, and enhancing management decisions based on data utilization.

[0229] (II) Addendum The identifiers of components described herein (e.g., prefixes and symbols such as "First" and "Second") are for convenience only and do not limit the number, order, function, arrangement, etc., of the components. The same identifier may refer to different components in different embodiments, and one component may also perform the function of another component. Therefore, the identifiers of components described herein are not intended to limit the technical scope, functional scope, or scope of rights of the components, and each component should be interpreted flexibly according to the context of its embodiment.

[0230] In this specification, "interface device" means a component that may include one or more interface devices. Such interface devices may include, but are not limited to, I / O (Input / Output) interface devices, communication interface devices, or combinations thereof. For example, an I / O interface device may be configured to function as a user interface and may include at least one input device (e.g., a keyboard, a pointing device) and / or an output device (e.g., a display). These I / O interface devices may be configured to have communication functions that allow connection to remote computing devices, in which case the I / O interface device can also operate as a communication interface device. Furthermore, the communication interface device may include identical communication means (e.g., multiple NICs (Network Interface Cards)) or a combination of different types of communication means (e.g., a NIC and an HBA (Host Bus Adapter)). This enables a flexible configuration that ensures connectivity with heterogeneous systems. Interface devices configured in this way are not limited to a specific hardware configuration and can accommodate future technological advancements and diversification of embodiments.

[0231] In this specification, “storage device” means a component that may include at least one storage device. Depending on the intended use and system configuration, such storage devices may be classified, for example, into “memory” which temporarily holds data during operation and “persistent storage device” which retains data even after power is lost. Memory can function as a temporary storage medium accessible by the processor and may include volatile, non-volatile, or a combination thereof memory devices. Specifically, examples include, but are not limited to, volatile memory such as DRAM (Dynamic Random Access Memory) and SRAM (Static RAM), and non-volatile memory such as MRAM (Magnetoresistive RAM) and ReRAM (Resistive RAM). Persistent storage devices are components intended for long-term data storage and include devices using non-volatile storage media. Specifically, these may include HDD (Hard Disk Drive), SSD (Solid State Drive), NVMe (Non-Volatile Memory Express) drives, etc. Next-generation storage technologies such as 3D XPoint and phase-change memory may also be included as examples of storage device configurations. A storage device configured in this way is not limited by the type or architecture of the storage medium, and can accommodate future technological advancements and diversification of future technological advancements and embodiments.

[0232] In this specification, "processor" means a component that may include an arithmetic unit or circuit capable of performing at least one processing function. Depending on the application, such a processor may include, for example, a microprocessor device such as a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), or it may include implementations using dedicated circuits such as an FPGA (Field-Programmable Gate Array), a CPLD (Complex Programmable Logic Device), or an ASIC (Application Specific Integrated Circuit). A processor may consist of a single core, a multi-core, or a single processor core. A processor may be configured to implement processing functions using a computer program, directly implemented using hardware circuits, or a hybrid configuration combining these. When processing is performed by a program, the processor may perform processing in cooperation with other components such as memory devices or interface devices. In this specification, a particular function may be described as a "part," but such a function can be realized by a program executed by the processor, an implementation using circuits, or a combination thereof. Therefore, such a function can be considered to be at least a part of the processor. The program may be supplied from an external program source. Examples of program sources include, but are not limited to, network-connected program distribution servers and computer-readable non-temporary storage media. Processors configured in this way are not limited to specific hardware configurations or implementation forms, and can adapt to future technological advancements and diversification of implementations.

[0233] In this specification, "system" means a set of components that may include at least one computing resource. Such a system may consist of one or more physical computers (dedicated hardware, on-premises servers, etc.) or virtualized computing resources (cloud infrastructure, virtual machines, containers, etc.). A system may include, but is not limited to, cloud computing systems, cluster configurations, serverless environments, etc. A system may be configured within a single device or in a configuration in which multiple computing resources cooperate via a network. Each component may be logically integrated or physically separated. Such a system may also include components such as processors, storage devices, and interface devices, and these components may be implemented as physical devices or realized as virtual configurations. A system configured in this way is not limited to a specific hardware configuration, implementation form, deployment form, etc., and can accommodate future technological advancements and diversification of embodiments.

[0234] The embodiments described above have, for example, the following features.

[0235] (1) A customer service support system (e.g., customer service support system 100) that supports customer service operations at a facility (e.g., accommodation facilities, medical facilities, car rental offices, restaurants and other facilities that perform customer service operations), comprising: an acquisition unit (e.g., low-code base 120, acquisition unit 221) that acquires messages from customers transmitted from multiple different channels; a conversion unit (e.g., low-code base 120, conversion unit 222) that converts the information contained in the messages acquired by the acquisition unit into a predetermined format (a format converted to a predefined structure and format for unified processing, registration, and management in the customer service support system 100); and the conversion by the conversion unit The system includes: a registration unit (e.g., low-code platform 120, registration unit 223) that registers information to a management platform (e.g., integrated management platform 130); a response unit (e.g., low-code platform 120, response unit 224) that searches for response candidates related to the message acquired by the acquisition unit from response knowledge information managed for each facility, and generates a response proposal from the searched response candidates according to predetermined conditions; and an escalation unit (e.g., low-code platform 120, escalation unit 225) that switches to an operator response if the response unit does not generate a response proposal for the message, or if the message matches the emergency notification conditions.

[0236] According to the above configuration, for example, messages from customers sent through multiple different channels at an accommodation facility can be automatically retrieved. The customer support system then converts the information contained in the message (name, accommodation dates, inquiry details, etc.) into a predetermined format and registers the converted information in a management platform such as a customer information management system. This allows operators to centrally check and respond to all customer messages, regardless of the channel type, preventing information oversights and input errors, and improving operational efficiency.

[0237] Furthermore, with the above configuration, for example, response candidates corresponding to a message can be searched from response knowledge information managed for each facility, and appropriate response proposals can be automatically generated according to predetermined conditions. This makes it possible to provide quick and consistent answers even to inquiries that require individual handling for each facility, thereby standardizing response quality and reducing the workload.

[0238] Furthermore, with the above configuration, for example, if the response unit does not generate a response to a message, or if the message meets the criteria for an urgent notification, notification data related to that message can be generated and sent to the company's notification channel. This makes it possible to prompt operators and relevant parties to respond quickly to cases where automated responses are difficult or to highly urgent inquiries, thereby preventing omissions and delays in customer service.

[0239] (2) The acquisition unit described above acquires messages from at least two channels: a voice channel, an email channel, a messaging app channel, and an online service provider channel.

[0240] According to the above configuration, for example, messages from customers can be obtained from at least two of the following channels: voice channels, email channels, messaging app channels, and online business channels, thus enabling flexible support for the diverse channels used by customers.

[0241] (3) The conversion unit extracts customer identification information (e.g., name), the start date of facility use, and the end date of facility use from the message acquired by the acquisition unit, maps the extracted results to a predefined data structure, and performs a conversion to unify the date format (see, for example, steps S403 and S504).

[0242] According to the above configuration, for example, customer identification information, the start and end dates of facility use, and the message body can be automatically extracted from a message, mapped to a predefined data structure, and registered. Furthermore, by unifying and converting the date format, inconsistencies in data processing caused by different input notations across channels can be prevented. This allows for the automation of subsequent processing and improves the accuracy of searches and analyses.

[0243] (4) The response unit described above converts the searched response candidates into the customer's language using a predetermined translation process, and generates the converted text data or audio data as a response proposal.

[0244] According to the above configuration, for example, the searched response candidates can be converted into the customer's language through a predetermined translation process, and the converted text data or audio data can be generated as a response proposal. This makes it possible to respond quickly in the appropriate language to customers who make inquiries in foreign languages, thereby improving the efficiency of multilingual support and enhancing customer satisfaction.

[0245] (5) The above-described customer support system includes a learning unit (e.g., low-code platform 120, learning unit 226) that, when the response unit does not generate a response to a message and a response is made by an operator, acquires the content of the response and reflects the draft data, which is generated as general-purpose content usable by other customers, into the response knowledge information based on a predetermined approval operation.

[0246] According to the above configuration, for example, if an automated response cannot be provided by the response unit and an operator handles the inquiry, the response content can be acquired, converted into general-purpose content applicable to other customers, and draft data can be generated. This data can then be reflected in the response knowledge information based on a predetermined approval operation. This allows for the accumulation and utilization of manual responses as knowledge, enabling continuous improvement in the accuracy and scope of automated responses to similar inquiries in the future.

[0247] (6) The above-mentioned response unit controls whether to prioritize an AI-generated voice response or an operator response in response to a message received through the voice channel, according to a pre-set priority mode. In the response on the voice channel, it transcribes the call audio via the speech recognition unit, summarizes the transcription results, and sends the summarized content to the company's notification channel.

[0248] According to the above configuration, for example, it is possible to automatically control whether to prioritize an AI-generated voice response or an operator response to a message received through a voice channel, according to a pre-set priority mode. This makes it possible to flexibly switch response methods depending on business hours, response policies, congestion levels, etc., thereby achieving both efficiency in call handling and improved customer satisfaction.

[0249] Furthermore, with the above configuration, for example, the content of the response in the voice channel can be transcribed via the speech recognition unit, the obtained transcription result can be summarized, and the summarized content can be sent to the company's notification channel. This makes it possible to automatically record, summarize, and share the content of telephone conversations, reducing the reporting burden on operators while improving the visibility of the response status and accelerating information sharing.

[0250] The above customer support system may include a transmission unit that sends response information generated by a response unit or response information created by a human operator to the customer terminal. In such a configuration, AI generates response information in response to the acquired message, or escalates the matter to an operator to obtain response information, and then notifies the customer terminal of this response information. This establishes a mechanism to ensure that customer inquiries are reliably answered.

[0251] Multi-channel centralization The customer support system described above targets multiple channels used for user inquiries and integrates them into a single management screen. These channels include telephone channels (voice channels) via voice calls, web page inquiry forms, email channels, various messaging services using the internet, and messaging functions included in external reservation services. Inquiry information sent through these multiple channels is processed integrally within the system. The integrated information is displayed in a single management screen, allowing operators to view and respond to inquiries directly. For example, the management screen displays a list of channel type (e.g., icon), ticket status, ID, subject, reservation status, reservation name (e.g., name), subject, check-in date, check-out date, language, and last updated date. This configuration allows operators to perform tasks such as receiving confirmations, entering responses, and checking response history in a single interface without switching between channel-specific screens or tools. As a result, the workload for handling inquiries is reduced, omissions and response delays are prevented, and the quality of customer service is improved.

[0252] Multilingual, high-speed automated response The customer support system described above features a generative model that references facility-specific learning information and is configured to automatically respond to inquiries received through all channels 24 hours a day, 365 days a year, in all languages, with an average response time of just a few seconds. The response processing itself has an average response time of approximately 8 seconds, enabling high-speed responses to inquiries. Furthermore, the generative model supports multiple languages, allowing it to process inquiries regardless of the language they are entered in. In addition, it includes an automatic translation function to absorb language differences between operators and users, thereby enabling bidirectional multilingual operation. These configurations make it possible to provide an inquiry handling system with excellent always-on availability, multilingual support, and response speed.

[0253] Human-AI collaborative communication The customer support system described above includes at least two response modes for voice calls. Specifically, a first mode (human priority mode) prioritizes responses by operators, with AI-based responses only occurring if the operator is unavailable; and a second mode (AI priority mode) where the AI ​​makes an initial response and then transfers the call to the operator based on its content. In either response mode, all call content is automatically transcribed as text data using speech recognition processing, and summarization is performed. The resulting summary is immediately transmitted to a designated internal communication channel, enabling rapid sharing of call content. This configuration allows facility operators to grasp the response status in real time and facilitates smooth collaborative call handling between AI and humans.

[0254] Immediate escalation in irregular situations The customer support system described above is configured to immediately send a notification to a designated internal communication channel if it detects an event that cannot be handled by the AI ​​during an inquiry response via a communication channel, and if the conversation is not included in the learning data or is deemed to be of high urgency. This notification is sent to the operator, for example, via an internal business communication application (e.g., a business chat service), and the operator can check the content of the conversation based on the notification and switch to a manual response. Furthermore, if deemed necessary, the system is configured to temporarily suspend the AI ​​response function, thereby transferring all subsequent inquiries to human processing. This makes it possible to provide appropriate and immediate human support without making guests (users) wait, even in irregular cases where AI response is difficult.

[0255] Self-study (from automatic FAQ generation to relearning) The customer support system described above includes a generative response model that automatically executes responses to inquiries. The response model is built on a set of learning information that includes facility-related information and has the function of generating appropriate response sentences by matching them with the content of the inquiry. Furthermore, the customer support system includes an unresolved detection unit that detects unresolved conversations that could not be resolved by the response model during the response processing process, and an information extraction unit that extracts highly generalizable information from manual responses made by the operator to unresolved conversations. The information extraction unit automatically generates FAQ candidates formatted in Q&A format based on the content of the manual responses. The generated FAQ candidates are compared with existing FAQs, and a decision is automatically made as to whether existing items need to be updated or new items need to be added. As a result of the comparison, FAQ candidates that are judged to need updating or addition are notified to the operator as drafts. The operator checks the draft information included in the notification, edits it as necessary, and then performs the "start learning" operation. This operation updates the set of learning information, and as a result, the response model is retrained based on the new information. Through this series of processes, the operator's knowledge is gradually reflected in the response model, making it possible to continuously improve the resolution rate of AI-driven automated responses.

[0256] Safe memory at the conversational level The above-mentioned customer support system may include a memory unit that stores the utterance history of conversations with users, and the memory unit may employ an access control configuration that allows the stored history information to be accessed only within the scope of the conversation session. In this case, the stored conversation history may include not only the content of the user's inquiry, but also the AI ​​response content in response to the conversation and, if necessary, response information supplemented by the operator. The stored conversation history is referenced when generating responses to maintain the consistency of the conversation within the same conversation session, but is configured not to be referenced in other sessions or conversations with other users. As a result, this customer support system ensures the preservation of context and the continuity of natural conversations in conversations with users, while preventing history information that may contain personal information from being unnecessarily used for other processing. Therefore, it is possible to balance information security requirements and user experience by retaining only the minimum necessary information.

[0257] Automatic translation, two-way operation The customer support system described above includes a translation processing unit and is configured to be applicable to both AI-based automated response processing and manual response processing by operators. The translation processing unit is configured to automatically translate and present response input from operators into the language used by the user, and to translate and display user input into the operator's native language. This allows operators to always handle inquiries in their native language, and the response content is presented in a language appropriate to the user. Furthermore, since the translation processing unit is also applied to input and output in AI response processing, smooth bidirectional operation between multiple languages ​​is achieved in both AI responses and operator responses.

[0258] telephone operation The above-mentioned customer support system can be configured to include multiple processing units for telephone-related operational functions. Specifically, this customer support system has a processing unit that assigns a dedicated telephone number to each facility or operational unit. For voice calls received through this number, a call recording process is performed to record the content of the call, and the voice data is automatically transcribed to generate a text-based call record. Furthermore, this customer support system has a voice reading function and can output predetermined guidance messages or AI-generated response sentences as voice. In addition, it is configured to send short messages depending on the call context, for example, by notifying users of predetermined phrases via SMS. Moreover, the telephone-related operational functions include a simple voice guidance (IVR: Interactive Voice Response) that allows users to select language and response route during a call, and a configuration that performs branching processing according to the input content. Furthermore, if the input of an emergency code by the user is detected, the call is transferred to a pre-registered emergency contact. In addition, for users who wish to be contacted via a messaging app, the system can guide them to the messaging app using SMS, and it is also possible to provide callback instructions if an immediate response is not possible. With the telephone-related operational functions configured in this way, this customer support system enables flexible responses tailored to the call needs and urgency of users, allowing for the distribution of call load, faster initial response, and appropriate guidance to non-face-to-face methods.

[0259] Administration panel and roles The customer support system described above provides an internal management screen for the operation of inquiry handling. The management screen includes a display section that visualizes the status of received inquiries, the content of AI responses to inquiries, and whether or not a response was given, and also includes an operation section that allows operators to manually execute responses. Furthermore, for inquiries requiring individual attention, the management screen can receive notifications through internal notification channels and display the notification content in a list. In addition, operators can edit, register, and manage the content of FAQs used for AI training on the management screen. This allows the customer support system to support the updating of training content and the continuous improvement of inquiry response accuracy. Moreover, the management screen is equipped with a record section that stores response history, and is configured to perform analysis processing based on historical information. This makes it possible to evaluate the performance of inquiry handling and understand trends in response quality.

[0260] Furthermore, the above customer support system may be integrated with a reservation management system to automatically retrieve reservation information from phone numbers. This makes it easier to identify the caller and estimate their requirements at the start of the call. In addition, the above customer support system adopts a policy of providing value in line with the communication methods that users use on a daily basis, and does not require the provision of a proprietary web application or embedded chatbot. [Explanation of Symbols]

[0261] 100...Customer support system, 110...Customer terminal, 120...Low-code platform, 130...Integrated management platform.

Claims

1. A customer service support system that assists customer service operations at an accommodation facility, An acquisition unit that acquires messages from customers sent from at least two channels, including a voice channel, an email channel, a messaging app channel, and an online business channel, A conversion unit extracts customer identification information of customers using the accommodation facility, the start date of use of the accommodation facility, and the end date of use of the accommodation facility from the messages acquired by the acquisition unit, maps the extracted results to a predetermined data structure, and performs a conversion to unify the date format. The information converted by the conversion unit is registered as inquiry ticket information related to the accommodation facility in an integrated management platform that centrally manages inquiries from multiple channels and the status of responses to those inquiries, and the registration unit manages the inquiry ticket information including the start date of use and the end date of use of the accommodation facility. A response unit searches for response candidates related to the message acquired by the acquisition unit from response knowledge information managed for each accommodation facility, and generates a response proposal from the searched response candidates according to predetermined conditions. If the response unit cannot generate a response to the message, or if the message meets the conditions for an urgent notification, the escalation unit generates notification data including a summary of the message body, and transmits the generated notification data to the internal notification system to enable operator intervention. It has a learning department, The aforementioned learning unit, (a) When an operator's response is registered to a customer's message regarding accommodation registered in the integrated management platform, a draft FAQ consisting of general question and answer sentences is generated based on the message and the operator's response. (b) For the generated FAQ draft, a matching process including full-text search and similarity matching is performed to suppress duplication with existing FAQs included in the response knowledge information of the accommodation facility, and the process is distributed to at least one of updating existing FAQs or adding new ones depending on the matching results. (c) The draft FAQ is temporarily saved as an intermediate step before being submitted to the approval workflow, and a status flag indicating the status is assigned to the draft FAQ to manage the state transitions. (d) When an approval operation is performed in the approval workflow, the draft FAQ is reflected in the response knowledge information of the accommodation facility, and the reflected response knowledge information of the accommodation facility is registered as the response knowledge information of the accommodation facility used in the response unit. Customer support system.

2. A customer support system according to Claim 1, The acquisition unit acquires voice calls received through a dedicated telephone number assigned to each accommodation facility or operational unit as messages in a voice channel. The response unit is Based on at least one of the following, the AI ​​voice response or operator response is controlled for messages in the voice channel acquired by the acquisition unit: a first response mode that prioritizes operator responses according to a pre-set response mode and executes an AI response when the operator is unable to respond; and a second response mode that transfers the call to the operator according to the content of the initial response made by the AI. The content of the conversation during the response in the aforementioned voice channel is recorded, the recorded data is transcribed by a speech recognition unit, the obtained transcription results are summarized and a summary record is generated. The aforementioned summary record is sent to the internal notification system. The summary record is associated with the inquiry ticket information corresponding to the message in the integrated management platform. Customer support system.

3. A customer support system according to Claim 2, The response unit outputs voice guidance to the voice channel related to the voice call acquired by the acquisition unit, allowing the customer to select at least a language or a corresponding route at the start of the call, and branches the processing route related to the voice call according to the customer's selection. If the customer indicates that they wish to be contacted via a messaging app, a message guiding them to the messaging app will be sent to their device. If it is determined that an immediate response by an operator or AI is difficult based on predetermined conditions, instructions regarding a return call will be provided. If it is detected that a predetermined emergency code has been entered, the detected result is output to the escalation unit. The escalation unit, when the response unit detects the input of a predetermined emergency code in a message on a voice channel related to a voice call acquired by the acquisition unit, performs call transfer processing to a pre-registered emergency contact. Customer support system.

4. A customer support system according to Claim 1, The acquisition unit acquires messages from customers regarding accommodations transmitted from online business channels. The response unit searches for response candidates related to the message from the response knowledge information of the accommodation facility, converts the retrieved response candidates into the customer's language using a predetermined translation process, and generates the converted text data or audio data as a response proposal. The registration unit manages the proposed response as a response history of inquiry ticket information related to the accommodation facility. Customer support system.

5. A customer service support method for supporting customer service operations at an accommodation facility, The acquisition unit acquires messages from customers sent from at least two channels: a voice channel, an email channel, a messaging app channel, and an online business channel. The conversion unit extracts customer identification information of the customer using the accommodation facility, the start date of use of the accommodation facility, and the end date of use of the accommodation facility from the message acquired by the acquisition unit, maps the extracted results to a predetermined data structure, and performs a conversion to unify the date format. The registration unit registers the information converted by the conversion unit as inquiry ticket information related to the accommodation facility in an integrated management platform that centrally manages inquiries from multiple channels and the status of responses to those inquiries, and manages the inquiry ticket information including the start date of use and the end date of use of the accommodation facility. The response unit searches for response candidates related to the message acquired by the acquisition unit from response knowledge information managed for each accommodation facility, and generates a response proposal from the searched response candidates according to predetermined conditions. The escalation unit generates notification data including a summary of the message body when the response unit cannot generate a proposed response to the message, or when the message meets the conditions for an urgent notification, and transmits the generated notification data to the internal notification system to enable operator intervention. The learning department, (a) When an operator's response is registered to a customer's message regarding accommodation registered in the integrated management platform, a draft FAQ consisting of general question and answer sentences is generated based on the message and the operator's response. (b) For the generated FAQ draft, a matching process including full-text search and similarity matching is performed to suppress duplication with existing FAQs included in the response knowledge information of the accommodation facility, and the process is distributed to at least one of updating existing FAQs or adding new ones depending on the matching results. (c) The draft FAQ is temporarily saved as an intermediate step before being submitted to the approval workflow, and a status flag indicating the status is assigned to the draft FAQ to manage the state transitions. (d) When an approval operation is performed in the approval workflow, the draft FAQ is reflected in the response knowledge information of the accommodation facility, and the reflected response knowledge information of the accommodation facility is registered as the response knowledge information of the accommodation facility used in the response unit, Customer support methods, including those mentioned above.

Images