Task management method, system, device and equipment and storage medium

Abstract

The embodiment of the invention provides a task management method, system, device and equipment and a storage medium, and the method comprises the steps: in response to reception of commitment information sent by a first dialogue service client, generating a performance task based on the commitment information, the commitment information comprises information of three elements, namely a commitment event, a performance mode and a performance time limit, the commitment information is generated based on dialogue information of the first dialogue service client and a user; when it is determined that the performance task needs to be executed offline, creating at least one task work order corresponding to the performance task based on a task execution rule matched with the commitment information; and for any task work order, sending the task work order to a second dialogue service client, and monitoring the execution condition of the task work order until the tasks corresponding to the at least one task work order are all executed. By adopting the implementation mode, effective management on the performance condition of the commitment is supported, and the use experience of the user can be improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence (AI) technology, and in particular to a task management method, system, device, equipment and storage medium. Background Technology

[0002] With the rapid development of internet technology, providing consultation and problem-solving services to users through online dialogue services (known as "online customer service") is becoming increasingly common. However, due to limitations in the functionality of dialogue service platforms, some user requests cannot be met through the dialogue service client itself, such as order compensation or expedited delivery. Dialogue service personnel can usually make promises to users regarding requests that cannot be met immediately, thus responding to their needs.

[0003] However, the current implementation method does not effectively manage the fulfillment of commitments, resulting in poor fulfillment of commitments, such as long-term non-fulfillment or mismatch between the fulfillment results and the commitments, which in turn leads to a poor user experience. Summary of the Invention

[0004] To overcome the problems existing in related technologies, embodiments of this application provide a task management method, system, apparatus, device, and storage medium.

[0005] According to a first aspect of the embodiments of this application, a task management method is provided, the method comprising: In response to receiving the commitment information sent by the first dialogue service client, a performance task is generated based on the commitment information. The commitment information includes three elements: commitment event, performance method, and performance time limit. The commitment information is generated based on the dialogue information between the first dialogue service client and the user. If it is determined that the performance task needs to be executed offline, at least one task work order corresponding to the performance task is created based on the task execution rules matched by the commitment information. For any task order, the task order is sent to the second dialogue service client, and the execution status of the task order is monitored until all tasks corresponding to at least one task order have been executed.

[0006] According to a second aspect of the embodiments of this application, a task management method is provided, the method comprising: During the conversation with the user, the conversation information is sent to the server; In response to receiving information corresponding to the three elements of commitment event, performance method and performance time limit sent by the server, commitment information is generated based on the information corresponding to the three elements. The commitment information is sent to the server so that the server performs the method of the first aspect.

[0007] According to a third aspect of the embodiments of this application, a task management system is provided, the system including a server and multiple dialogue service clients. The first dialogue service client is used to send dialogue information to the server during a dialogue with the user. The server is configured to identify information corresponding to the three elements of commitment event, performance method and performance time limit from the dialogue information, and send the information corresponding to the three elements of commitment event, performance method and performance time limit to the first dialogue service client. The first dialogue service client is also used to generate commitment information based on the information corresponding to the three elements respectively, and to send the commitment information to the server; The server is also configured to generate a performance task based on the commitment information, and, if it is determined that the performance task needs to be executed offline, create at least one task work order corresponding to the performance task based on the task execution rules matched by the commitment information; for any task work order, send the task work order to the second dialogue service client, and monitor the execution status of the task work order until all tasks corresponding to the at least one task work order have been executed. Among them, the first dialogue service client and the second dialogue service client belong to the plurality of dialogue service clients.

[0008] According to a fourth aspect of the embodiments of this application, a task management device is provided, the device comprising: The generation module is used to respond to the commitment information sent by the first dialogue service client and generate a performance task based on the commitment information. The commitment information includes three elements: commitment event, performance method, and performance time limit. The commitment information is generated based on the dialogue information between the first dialogue service client and the user. A creation module is used to create at least one task work order corresponding to the performance task based on the task execution rules matched by the commitment information, when it is determined that the performance task needs to be executed offline. The monitoring module is used to send any task work order to the second dialogue service client and monitor the execution status of the task work order until all tasks corresponding to at least one task work order have been executed.

[0009] According to a fifth aspect of the embodiments of this application, a task management device is provided, the device comprising: The sending module is used to send conversation information to the server during the dialogue with the user. The generation module is used to generate commitment information based on the information corresponding to the three elements of commitment event, performance method and performance time limit sent by the server. The sending module is further configured to send the commitment information to the server, so that the server generates a performance task based on the commitment information, and if it is determined that the performance task needs to be executed offline, creates at least one task work order corresponding to the performance task based on the task execution rules matched by the commitment information; for any task work order, the task work order is sent to the second dialogue service client, and the execution status of the task work order is monitored until all tasks corresponding to the at least one task work order are executed.

[0010] According to a sixth aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method as described in the first or second aspect.

[0011] According to a seventh aspect of the embodiments of this application, a computer-readable storage medium is provided having a computer program stored thereon, the program being executed by a processor to implement the method as described in the first or second aspect.

[0012] According to an eighth aspect of the embodiments of this application, a computer program product is provided, including a computer program that is executed by a processor to implement the method of the first aspect or the second aspect.

[0013] The technical solutions provided in this application embodiment may include the following beneficial effects: By generating fulfillment tasks from received commitment information, and then creating task work orders for fulfillment tasks that require subsequent execution by the dialogue service client, and allocating and monitoring the execution status of task work orders, an automated fulfillment management mechanism is constructed, encompassing fulfillment records, task breakdown, and task execution monitoring. This mechanism supports effective management of commitment fulfillment status. Furthermore, this embodiment creates task work orders based on task execution rules matching commitment information. Therefore, this embodiment categorizes and manages commitment information, thereby supporting the accurate creation of task work orders for fulfillment tasks. This facilitates standardized management of commitments and process monitoring of fulfillment tasks. Thus, by adopting this implementation method, through standardized task construction, management, and monitoring, it ensures that commitments to users are fulfilled in a timely manner, resolving issues such as "long-term non-fulfillment" and "mismatch between fulfillment results and commitments," thereby improving the user experience.

[0014] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly described below. It should be understood that those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0016] Figure 1 A schematic diagram of an exemplary task management system provided in this application embodiment; Figure 2A Exemplary method flow diagram of the task management method provided in the embodiments of this application Figure 1 ; Figure 2B A second exemplary method flowchart of the task management method provided in this application embodiment; Figure 3A Exemplary interface diagram of the dialog interface provided in the embodiments of this application Figure 1 ; Figure 3B A second exemplary interface diagram of the dialog interface provided in the embodiments of this application; Figure 4 Signaling interaction diagram of an exemplary task management method provided in the embodiments of this application; Figure 5A Exemplary composition diagram of the task management device provided in the embodiments of this application Figure 1 ; Figure 5B A second exemplary schematic diagram of the task management device provided in the embodiments of this application; Figure 6 This is an exemplary structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings.

[0018] The terminology used in the following embodiments of this application is for the purpose of describing specific embodiments and is not intended to limit the technical solutions of this application. As used in the specification and appended claims of this application, the singular expressions "a," "an," "the," "the," "the," and "this" are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that although the terms first, second, etc., may be used in the following examples to describe a class of objects, the objects are not limited to these terms. These terms are used to distinguish specific implementations of that class of objects.

[0019] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0020] This application relates to application scenarios where online services are provided through a dialogue service platform. The dialogue service platform serves as a medium for service providers to respond to customer inquiries online. Taking e-commerce as an example, when the dialogue service platform receives a customer's inquiry about the usage of a product, the service provider replies with the correct usage method through the platform. Due to limitations in the platform's functionality, service personnel can respond instantly to simple user requests, such as inquiries, using the platform. However, more complex user requests, such as order refunds, compensation processing, and logistics expediting, cannot be handled immediately using the current platform. In such cases, service personnel can typically make promises to users regarding requests that cannot be immediately fulfilled, thus responding to their needs. In scenarios where service personnel make promises, the fulfillment of those promises has a crucial impact on the user experience and trust levels.

[0021] In conventional implementations, the commitment recognition model set up on the dialogue service platform only has the function of identifying whether a commitment has been made to a user, but it does not have the function of managing the fulfillment of commitments. Therefore, dialogue service personnel need to manually create work orders to generate events to be fulfilled. As a result, dialogue service personnel often forget to create work orders, leading to long periods of non-fulfillment, or the work orders created by dialogue service personnel are inaccurate, resulting in a mismatch between the fulfillment results and the commitment. This leads to problems such as high rates of repeated inquiries from users and a poor user experience.

[0022] In view of this, the technical solution provided in this application provides an automated performance management mechanism that includes performance records, performance task breakdown, and task execution monitoring. This mechanism supports effective management of the performance of commitments and ensures that commitments to users are fulfilled in a timely manner through standardized task construction, management, and monitoring. It also solves problems such as "long-term non-performance" and "mismatch between performance results and commitments," thereby improving the user experience.

[0023] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0024] The task management method provided in this application can be applied to a task management system, which can be deployed on electronic devices such as computers, game consoles, or personal computers (PCs), or on cloud computers, distributed clusters, etc. Figure 1 As shown, based on functionality and invocation logic, this task management system may include a server 10 and multiple dialogue service clients 20, for example... Figure 1 The diagram shows dialogue service clients 20A and 20B, wherein server 10 is communicatively connected to each of the multiple dialogue service clients 20.

[0025] Server 10, also known as the "middle platform" or "workbench," is configured as the management engine for task management. Server 10 maintains functions such as commitment information identification, task splitting, task allocation, and monitoring, as well as policies and data supporting these functions. In some embodiments, server 10 can deploy multiple intelligent modules, each capable of performing the functions of commitment information identification, task splitting, task allocation, and monitoring. For example, the policies maintained by server 10 may include policies for identifying commitment information, creating tasks, and providing timeout reminders. For example, the data maintained by server 10 may include multiple standard operating procedures (SOPs), operation permissions for different dialogue service clients among multiple dialogue service clients 20, the correspondence between task orders and dialogue service clients, and historical dialogue information between users and intelligent dialogue service clients.

[0026] As an example, any intelligent module can be implemented as a functional module with natural language understanding and task management capabilities, such as an AI agent. An intelligent module is a dynamic integration of model functionality and task management capabilities. It can understand received natural language information, determine the tasks to be performed based on the understanding results, and then execute the corresponding tasks. As an example, a commitment information recognition agent can identify commitment information in user dialogue information, and then, based on the semantic matching of the commitment information, determine whether to create a fulfillment task.

[0027] As an example, these multiple SOPs can be defined based on different commitment scenarios. Each SOP can define at least one of the following: standard dialogue scripts for the corresponding commitment scenario and task execution rules for fulfilling the commitment.

[0028] This implementation method constructs an automated fulfillment management system by deploying intelligent modules, avoiding the problem of untimely fulfillment caused by manually creating work orders to trigger fulfillment. Furthermore, by setting Standard Operating Procedures (SOPs) to define dialogue scripts and task execution rules according to different commitment scenarios, the fulfillment tasks are divided into fine-grained categories, which helps improve the matching degree of user commitment fulfillment.

[0029] Any one of the multiple dialogue service clients 20 is configured as the interaction medium between the server 10 and the user. Each dialogue service client can run on a terminal device and can interact with the user in the form of a dialog box on a user interface (UI). In some embodiments, the dialogue service client can receive the user's incoming call instruction and respond to the user's inquiries, coordinate the handling of the user's order status, and promise the user's follow-up processing through dialogue. In scenarios where promises to the user need to be fulfilled offline, in this embodiment, the dialogue service client can display the promise information in the dialogue information in a preset structure (e.g., Figure 3B The information card (in the format shown) is sent to server 10 to enable server 10 to generate a fulfillment task. In some embodiments, the dialogue service client can receive a task work order assigned by server 10, and then respond to a trigger command to execute the task corresponding to the task work order.

[0030] Multiple dialogue service clients 20 can each perform different tasks, and each dialogue service client 20 has different operational permissions. For example, dialogue service client 20A is a client that provides consultation services to users. Therefore, dialogue service client 20A has the permission to respond to input information and engage in dialogue, but does not have the permission to trigger refunds or expedite logistics. As another example, dialogue service client 20B has the permission to process payments with the product server. Therefore, dialogue service client 20B has the permission to trigger refunds, but does not have the permission to expedite logistics.

[0031] It should be understood that the above description of the task management system is merely illustrative and does not constitute a limitation on the task management system in the embodiments of this application. In actual implementation scenarios, the task management system may include more or fewer components. The embodiments of this application do not limit this.

[0032] Please refer to Figure 2A , Figure 2A An exemplary task management method is shown, which can be implemented by... Figure 1 The example server 10 executes this. This task management method may include the following steps: In step S101, in response to receiving the commitment information sent by the first dialogue service client, a performance task is generated based on the commitment information.

[0033] In step S102, if it is determined that the performance task needs to be executed offline, at least one task work order corresponding to the performance task is created based on the task execution rules matched by the commitment information.

[0034] In step S103, for any task work order, the task work order is sent to the second dialogue service client, and the execution status of the task work order is monitored until all tasks corresponding to the at least one task work order are executed.

[0035] In this context, "offline execution of the fulfillment task" means that the first dialogue service client lacks the capability to execute the fulfillment task, and the server needs to allocate it to other devices for execution. The task execution rules can be included in the aforementioned SOP, which includes standard processing steps for the fulfillment task and rules for the operations to be performed at each step. Therefore, this technical solution generates fulfillment tasks based on the received commitment information according to the task execution rules. Then, task work orders are created for fulfillment tasks requiring subsequent execution by the dialogue service client, and the execution status of these task work orders is allocated and monitored. This constructs an automated fulfillment management mechanism for fulfillment recording, task breakdown, and task execution monitoring, supporting effective management of commitment fulfillment status. Furthermore, this embodiment creates task work orders based on task execution rules matching commitment information. Thus, this embodiment categorizes and manages commitment information, supporting accurate creation of task work orders for fulfillment tasks, which is beneficial for standardized commitment management and process monitoring of fulfillment tasks. It is evident that by adopting this implementation method and standardizing task construction, management, and monitoring, commitments to users are ensured to be fulfilled in a timely manner, resolving issues such as "long-term non-performance" and "mismatch between performance results and commitments," which helps improve the user experience.

[0036] The commitment information is generated based on the dialogue information between the first dialogue service client and the user, as detailed in the following embodiments. The commitment information includes three elements: commitment event, fulfillment method, and fulfillment time limit. A commitment event refers to a task promised to be handled for the user, such as expediting shipment or providing a certain amount of coupon compensation. In some embodiments, a commitment event may include one task, such as expediting shipment; in other embodiments, a commitment event may include multiple tasks, such as returns / exchanges and providing a certain amount of coupon compensation. The fulfillment method refers to the promised contact information for the user, such as telephone contact or SMS notification. The fulfillment time limit refers to the quantifiable and monitorable completion time for the response or processing of the commitment event.

[0037] In some embodiments, the server can determine whether the fulfillment task needs to be executed offline based on the relationship between the execution permission corresponding to the commitment event and the permissions of the first dialogue service client. For example, if the execution permission corresponding to the commitment event is outside the permissions of the first dialogue service client, and it is determined that offline execution is required, then step S102 is executed. If the execution permission corresponding to the commitment event is within the permissions of the first dialogue service client, and it is determined that the fulfillment task can be executed online, it indicates that the first dialogue service client has the ability to execute the fulfillment task. Therefore, it is not necessary to leave the execution environment of the first dialogue service client; the first dialogue service client can be triggered to execute the fulfillment task.

[0038] For example, if the commitment event is "modify order address," and the first dialogue service client has permissions to modify the order address, then the fulfillment task corresponding to this commitment event does not need to be executed offline; the first dialogue service client can receive the information input by the service personnel and make the modification. As another example, if the commitment event is "order compensation," but the first dialogue service client does not have compensation permissions, then the fulfillment task corresponding to this commitment event needs to be executed offline, and the server executes step S102.

[0039] In conventional implementations, the information promised by the first dialogue service client to the user is relatively arbitrary, with high ambiguity in semantics and event content. For example, the promised information "I will help you follow up" does not specify the content of the follow-up event or the specific method of "following up," making it difficult to manage the fulfillment of the promise. Therefore, before generating a fulfillment task based on the promised information, when the server detects a dialogue between the user and the first dialogue service client (i.e., user connection), it can collect the dialogue information between the user and the first dialogue service client. From the collected dialogue information, it can identify three elements: the promised event, the fulfillment method, and the fulfillment time limit. In this way, defining the promised information through three specific and clear elements eliminates the semantic ambiguity and unclear content boundaries of promises in conventional implementations. The resulting promised information has clear semantics, time boundaries, and execution paths, which is beneficial for managing and monitoring the fulfillment of the promised information in the form of fulfillment tasks.

[0040] In practical implementation scenarios, the dialogue information between the user and the first dialogue service client is complex and diverse, and it may be impossible to clearly and completely determine the information of the above three elements. Therefore, if the dialogue information is found to contain information of any one of the three elements, the server can send a prompt template to the first dialogue service client. The prompt template is used to instruct the first dialogue service client to inquire about the information of the three elements. The prompt template can be as follows: Figure 3AAs shown. Having extracted the information from the three elements, the server sends the initial commitment information, composed of the information from the three elements, to the first dialogue service client, so that the first dialogue service client can confirm whether the initial commitment information is the commitment information.

[0041] Before a user connects to the first dialogue service client, they typically engage in an initial dialogue with the intelligent dialogue service client. During this dialogue, the user expresses their needs or intentions. To ensure that the promises made by the first dialogue service client closely match the user's intentions, in some embodiments, upon detecting that the user is conversing with the first dialogue service client, the server identifies the promise scenario based on the user's historical dialogue information; determines the task execution rule matching the promise scenario from a preset task execution rule library; and sends the task execution rule to the first dialogue service client to trigger the first dialogue service client to output a script matching the promise scenario.

[0042] For example, historical dialogue information refers to the dialogue information between the user and the intelligent dialogue service client. Commitment scenarios can be scenario types categorized based on predefined task processing rules. For example, based on the order lifecycle processing stages and / or the operation type of the commitment service, each commitment scenario can correspond to a discrete, repeatable task type in the dialogue information where a clear commitment should be made to the user. For instance, the division based on the order lifecycle processing stages can include pre-sales, sales, and after-sales stages. Pre-sales commitment scenarios could include "discount" commitment scenarios, sales stages could include "expedited delivery" and "logistics coordination" commitment scenarios, and after-sales commitment scenarios could include "return / exchange" and "compensation" commitment scenarios. Furthermore, the division based on the operation type of the commitment service can include expedited operations, compensation operations, and verification operations. Expedited operations could include "expedited delivery" and "expedited logistics" commitment scenarios, and compensation operations could include "refund," "compensation coupon," and "compensation" commitment scenarios. Verification operations can include scenarios such as "price fluctuation verification", "product model verification", and "product inventory verification".

[0043] For example, after the server collects the user's historical dialogue information, it can extract keywords describing the commitment scenario in the historical dialogue information, such as "Why hasn't the goods arrived yet", "shipped", "a bit slow", "call it in", etc. Then, the commitment scenario can be determined based on the semantics of the keywords. For example, based on the semantic understanding of the keywords "shipped", "a bit slow", "call it in", it can be determined that the commitment scenario of the historical dialogue information is the "call logistics" commitment scenario.

[0044] Based on the foregoing description of task execution rules and SOPs, in this embodiment, the server can determine an SOP matching the commitment scenario from a pre-set SOP library and send it to the first dialogue service client. This SOP may include processing step templates and dialogue templates matching the commitment scenario, as well as the operation path and related work orders (i.e., task execution rules) included in the fulfillment operation of the commitment scenario. For example, the SOP corresponding to the "urging logistics" commitment scenario includes the following processing step templates and dialogue templates: Step 1: Reassure the user, dialogue: I understand your anxiety; I will immediately check and urge delivery for you. Step 2: Verify key information, guiding customer service to view the sub-order number and logistics status. Step 3: Trigger the creation of the fulfillment task; for example, the SOP can provide a "One-click creation of urging work order" button displayed on the first dialogue service client.

[0045] This implementation defines commitment scenarios based on the order processing stage and / or the operation type of the commitment service. It not only standardizes the definition and classification of commitment scenarios, but also provides data support for algorithm recognition, SOP setting and recommendation.

[0046] In some embodiments, to manage the commitments made by the dialogue service client to users in a unified manner, when a user is detected engaging in a dialogue with the first dialogue service client (i.e., a user enters the line), the server can create a monitoring event for this dialogue. This monitoring event may include, for example, two monitoring nodes: monitoring node one monitors the event of the first dialogue service client sending commitment information, and monitoring node two monitors the execution status of the task work order for fulfilling the commitment. For example, the server can bind the monitoring event to the session identity (Session ID) of this round of dialogue.

[0047] For example, after confirming that the event processing of monitoring node one is completed (i.e., the server receives the commitment information), the server executes steps S101 and S102, and after sending at least one task work order to the corresponding dialogue service client, runs the monitoring event of monitoring node two.

[0048] For monitoring node one, the server can monitor the session status between the user and the first dialogue service client; if the session status is that the session has ended and the commitment information has not been received, a timer is started; if the timer duration reaches a first preset duration and the commitment information is still not received, a first timeout reminder is sent to the first dialogue service client to remind the first dialogue service client to send the commitment information.

[0049] For example, the server can monitor the processing status of the first dialogue service client towards the monitoring node by detecting the client's generation status of the commitment information. For instance, if the client's generation status is "processing," it can be determined that the client has not generated or sent the commitment information. If the session status is determined to be session ended, the server can create a delayed task for the client, with a delay duration of, for example, 1 hour. If, after 1 hour, the client's generation status is still "processing," a first timeout reminder is sent to the client. If, within 1 hour, the client generates and sends the commitment information, the processing status of the client towards the monitoring node is changed to "completed."

[0050] For example, the first timeout reminder can be sent via in-site message, and the first timeout reminder may include, for example, the user identifier and the session ID.

[0051] In some implementation scenarios, service personnel typically construct and generate cards containing commitment information (such as cards) through the first dialogue service client during the session. Figure 3B (as shown), and send the card containing the commitment information to the server.

[0052] After creating at least one task order corresponding to the fulfillment task based on the task execution rules matching the commitment information, the server can monitor the monitoring events of monitoring node two. For example, for any task order, the server can record the duration of non-execution if the second dialogue service client has not executed the task corresponding to the task order. If the duration of non-execution reaches a second preset duration, a second timeout reminder is sent to the second dialogue service client to remind it to execute the task corresponding to the task order. If it is determined that the task corresponding to the task order was completed before the duration of non-execution reaches the second preset duration, it can be determined that the task order has been completed.

[0053] In some embodiments, the second preset duration can be the same as the first preset duration, for example, both the second preset duration and the first preset duration are 1 hour. In some embodiments, the second preset duration can be different from the first preset duration, for example, the second preset duration is 40 minutes, and the first preset duration is 30 minutes.

[0054] For example, the second timeout reminder can be sent via in-site message, and the second timeout reminder may include, for example, the user identifier and the task work order identifier.

[0055] In some embodiments, the server may send the commitment information and the execution status of the fulfillment task to the user's client in the form of a preset content template. The display style of the preset content template is as follows: Figure 4 As shown.

[0056] This application embodiment monitors tasks pending processing from different dialogue service clients by creating different monitoring nodes. This not only provides unified management of the execution status of tasks within the same session from discrete task executors, but also streamlines the fulfillment process. Furthermore, through collaborative management of multiple dialogue service clients, it improves the professionalism and accuracy of fulfillment. Setting timeout reminders helps control fulfillment deadlines, ensures task execution efficiency, avoids task backlog, and enhances the user experience.

[0057] In this context, a fulfillment task is a task that completes a promised event for the user within a specified timeframe. If the fulfillment task requires offline execution, the server can determine the specific operation instructions and parameters (such as refund amount, payment account, tracking number, etc.) based on task execution rules, and create a task work order based on these instructions and parameters. The task work order, as the operational unit of the fulfillment task, can be associated with a matching dialogue service client, allowing the server to track and monitor its processing status. The dialogue service client matched with the task work order refers to a dialogue service client with the necessary permissions to execute that task work order.

[0058] In some implementation scenarios, the server can receive commitment information from multiple first-party dialogue service clients simultaneously, and create fulfillment tasks for each commitment. Correspondingly, the server can assign task numbers to each fulfillment task to distinguish them. For example, the task number for a fulfillment task can be a Session ID.

[0059] In some implementation scenarios, a single dialogue process within the same primary dialogue service client may involve commitments to multiple orders. For multiple different orders, commitments with the same commitment scenario may be included. In this case, the fulfillment task corresponding to the dialogue process can create multiple task work orders with the same content.

[0060] For example, the first dialogue service client "Xiao A" makes commitments for products 01, 02, and 03 inquired by the user. For product 01, the commitment includes the scenario of "return and exchange"; for product 02, the commitment also includes the scenario of "return and exchange"; and for product 03, the commitment includes the scenario of "expediting delivery". Correspondingly, the fulfillment task generated for this dialogue can create two task orders with the commitment scenario of "return and exchange" and one task order for "expediting delivery". Similarly, if the first dialogue service client "Xiao C" makes a commitment to "return and exchange" for product 08 inquired by the user, the fulfillment task created by the server based on the commitment information from the first dialogue service client "Xiao C" also includes a task order with the commitment scenario of "return and exchange".

[0061] Since the fulfillment task is created based on the dialogue between the first dialogue service client and the user, and the task ticket is created based on the SOP, in order to facilitate the maintenance of the relationship between multiple fulfillment tasks and task tickets, after creating at least one task ticket corresponding to the fulfillment task based on the task execution rules matched by the commitment information, for any task ticket, the server reads the first commitment scenario and the first task number corresponding to the task ticket. The first task number is used to indicate the fulfillment task to which the task ticket belongs. From the pre-generated multiple fulfillment tasks, a target fulfillment task corresponding to both the first commitment scenario and the first task number is determined. If the creation time of the task ticket is later than the end time of the session corresponding to the target fulfillment task, a binding relationship is established between the task ticket and the target fulfillment task.

[0062] Furthermore, once it is determined that the task of any task order has been completed, the server can detect whether other task orders bound to the target fulfillment task of that task order have been executed. In response to determining that all task orders bound to the target fulfillment task have been executed, the server determines that the target fulfillment task has been completed.

[0063] In some embodiments, the server receives a commitment event completion indication from a first dialogue service client, or a task work order completion indication from a second dialogue service client, and determines that the corresponding performance task has been completed.

[0064] In some embodiments, the server receives a revocation instruction for a commitment event from the first dialogue service client and terminates the fulfillment task.

[0065] It is evident that by adopting this implementation method, binding scattered task orders with fulfillment tasks, it is beneficial to conduct full-link monitoring and management of the fulfillment status of commitments corresponding to each session.

[0066] The task management method of this application embodiment has been described above from the perspective of the server. Correspondingly, the task management method of this application embodiment will be described below from the perspective of the dialogue service client.

[0067] Please refer to Figure 2B , Figure 2B An exemplary task management method is shown, which can be implemented by... Figure 1 This is executed by any of the dialog service clients shown. It should be understood that... Figure 2B The illustrated method and Figure 2A The illustrated method corresponds to, Figure 2B Zhongyu Figure 2A The relevant features can be referenced. Figure 2A The explanations provided are omitted here.

[0068] This task management method may include the following steps: In step S201, during the dialogue with the user, the dialogue information is sent to the server.

[0069] In step S202, in response to receiving information corresponding to the three elements of commitment event, performance method and performance time limit sent by the server, commitment information is generated based on the information corresponding to the three elements.

[0070] In step S203, the commitment information is sent to the server.

[0071] Upon receiving the commitment information, the server generates a fulfillment task based on the commitment information. If it is determined that the fulfillment task needs to be executed offline, it creates at least one task order corresponding to the fulfillment task based on the task execution rules matched by the commitment information. For any task order, the server sends the task order to the second dialogue service client and monitors the execution status of the task order until all tasks corresponding to the at least one task order have been executed. For the specific implementation on the server side, refer to [reference needed]. Figure 2A The illustrative embodiments are described in detail here.

[0072] Combination Figure 1 As described in the illustrated embodiment, the dialogue service client can be an application hosted on an electronic device with a display screen, such as a mobile phone or tablet. The application can display the dialogue's GUI on the electronic device's screen. The GUI can include media interfaces for user input of dialogue information, such as interfaces for receiving text, audio, and images. For example, a text box might be used for receiving text; a control for receiving audio might be used to call an audio acquisition component (e.g., a recording component); and a control for receiving images or video might be used to call a camera component. After receiving user input and dialogue information, the dialogue service client can display different GUI interfaces as the dialogue progresses.

[0073] The following description, with reference to the GUI of a dialogue service client displayed on an electronic device, illustrates the implementation scenario of task management in this application embodiment.

[0074] In some embodiments, after step S201 and before generating commitment information based on the information corresponding to the three elements, the first dialogue service client may receive task execution rules and prompt templates from the server, i.e., the aforementioned SOP, and receive input dialogue matching the commitment scenario to confirm the information of the three elements with the user. The task execution rules match the commitment scenarios corresponding to the user's historical dialogue information, and the prompt templates are used to instruct the user to inquire about the information of the three elements.

[0075] The commitment scenario is determined by the server based on the user's historical dialogue information with the intelligent dialogue service client. This historical dialogue information is obtained by the server when the user connects to the dialogue server client. See the description in the foregoing embodiments for details, which will not be elaborated here.

[0076] like Figure 3A As shown, Figure 3A An exemplary GUI for a dialog interface provided in embodiments of this application. Figure 3A This diagram illustrates an exemplary GUI that guides users to confirm three elements: the promised event, the fulfillment method, and the fulfillment deadline. The GUI includes a contact bar 311, a dialog window 312, and a reference information bar 313. The contact bar 311 displays the number of currently incoming users and the number of unread messages sent by each user. The number of users can be displayed as user avatars, and each user avatar can serve as an interface to enter the dialog window with that user. The dialog window 312 includes a dialog information display window 3121 and an information input window 3122. The dialog information display window 3121 can display historical dialog information between the dialog service client and the current user, as well as scripted prompts from the server, for example... Figure 3A The message displayed reads: "Reminder: This is a service commitment scenario; key commitment elements (commitment event, fulfillment method, and fulfillment timeframe) are required." Information input window 3122 provides service personnel with dialogue information input controls. Reference information bar 313 displays information or links related to this dialogue, such as order information and SOPs. Figure 3A The SOP displayed is "Can we deliver to your door?". As the dialogue service client provides the three elements of the commitment event, fulfillment method, and fulfillment timeframe in the dialogue information with the current user, it receives the initial commitment information from the server. Figure 3A The GUI shown is updated to Figure 3B The GUI shown.

[0077] In some embodiments, the dialogue service client displays initial commitment information composed of information corresponding to the three elements respectively. If a send operation is received, the initial commitment information is sent to the server as the commitment information. If a modification operation is received for any element, the original information of the element is replaced with the modified information. After receiving the confirmation operation, the initial commitment information after modification is sent to the server as the commitment information.

[0078] like Figure 3B As shown, Figure 3B Another exemplary GUI for the dialog interface provided in the embodiments of this application. Figure 3B An exemplary GUI for generating commitment information cards is illustrated. This GUI includes a contact bar, a dialog window, and a reference information bar. The functions and interface layout of the contact bar, dialog window, and reference information bar can be found by referring to... Figure 3A As shown in the example, the details will not be repeated here. In this example, the dialog information display window can display card 320 containing the initial commitment information. Card 320 may display, for example, order number: 21123256; commitment event: contact supplier team; fulfillment method: phone or SMS; fulfillment time limit: 24 hours. Card 320 can also display two controls: Edit 321 and Send 322. Edit 321 provides an entry point for modifying the initial commitment information in card 320, and Send 322 provides an entry point for sending the initial commitment information in card 320.

[0079] For example, in response to a service worker's click on edit 321, both the commitment event information display box and the performance deadline information display box can display drop-down menu buttons. The service worker can change the corresponding information by selecting an option in the drop-down menu. The performance method information display box is a text box, and the service worker can change the performance method by entering information in the text box. In some embodiments, to improve the user experience, the commitment information and the current fulfillment status of the committed events in the commitment information can be displayed to the user in the form of an information card. The information card, for example... Figure 4 As shown.

[0080] It should be understood that Figures 3A to 4 This illustration is for informational purposes only and does not constitute a limitation on the embodiments of this application. In the embodiments of this application, the GUI may display different interface elements and content than those shown in the illustration, depending on the order type and commitment scenario. No limitations are imposed here.

[0081] In summary, by generating fulfillment tasks from received commitment information, and then creating task work orders for fulfillment tasks that require subsequent execution by the dialogue service client, and allocating and monitoring the execution status of task work orders, an automated fulfillment management mechanism is constructed, encompassing fulfillment records, task breakdown, and task execution monitoring. This mechanism supports effective management of commitment fulfillment status. Furthermore, this embodiment creates task work orders based on task execution rules matching commitment information. Therefore, this embodiment categorizes and manages commitment information, thereby supporting the accurate creation of task work orders for fulfillment tasks. This facilitates standardized management of commitments and process monitoring of fulfillment tasks. Thus, by adopting this implementation method, through standardized task construction, management, and monitoring, it ensures that commitments to users are fulfilled in a timely manner, resolving issues such as "long-term non-fulfillment" and "mismatch between fulfillment results and commitments," thereby improving the user experience.

[0082] The above embodiments describe various implementation methods of the method provided in this application from the perspectives of identifying information on three elements: the commitment event, the fulfillment method, and the fulfillment time limit; creating task work orders; monitoring the processing status of tasks; and providing timeout reminders. It should be understood that, corresponding to the above processing steps, the embodiments of this application can implement the above functions in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0083] For example, if the above implementation steps are achieved through software modules to realize the corresponding functions. Figure 5A As shown, a task management device is provided, which may include a generation module 511, a creation module 512, and a monitoring module 513. This task management device can be used to perform the above-described tasks. Figures 2A to 4 Some or all of the operations on the server.

[0084] For example: Generation module 511 is used to generate a performance task based on the commitment information received from the first dialogue service client in response to the commitment information received. The commitment information includes three elements: commitment event, performance method, and performance time limit. The commitment information is generated based on the dialogue information between the first dialogue service client and the user. Creation module 512 is used to create at least one task work order corresponding to the performance task based on the task execution rules matched by the commitment information when it is determined that the performance task needs to be executed offline. Monitoring module 513 is used to send the task work order to the second dialogue service client for any task work order and monitor the execution status of the task work order until all tasks corresponding to the at least one task work order have been executed.

[0085] Optionally, the task management device may further include an identification module and a sending module. The identification module is used to identify whether the dialogue information contains information of any one of the three elements in response to detecting that a user is having a dialogue with the first dialogue service client. The sending module is used to send a prompt template to the first dialogue service client if the dialogue information contains information of any one of the three elements. The prompt template is used to instruct the first dialogue service client to inquire about information of the three elements. And if the information of the three elements is extracted, the module sends an initial commitment information composed of the information of the three elements to the first dialogue service client so that the first dialogue service client can confirm whether the initial commitment information is the commitment information.

[0086] Optionally, the task management device further includes a determination module, and the identification module is further configured to identify a commitment scenario based on the user's historical dialogue information in response to detecting that the user is having a dialogue with the first dialogue service client; the determination module is configured to determine the task execution rule that matches the commitment scenario from a preset task execution rule library; and the sending module is further configured to send the task execution rule to the first dialogue service client to trigger the first dialogue service client to output a speech that matches the commitment scenario.

[0087] Optionally, the task management device further includes a timing module and a monitoring module 513, which are also used to monitor the session status between the user and the first dialogue service client; the timing module is used to start timing when the session status is that the session has ended and the commitment information has not been received; the sending module is also used to send a first timeout reminder to the first dialogue service client if the timing duration reaches a first preset duration and the commitment information is still not received, so as to remind the first dialogue service client to send the commitment information.

[0088] Optionally, the task management device further includes a reading module, which is used to read the first commitment scenario and the first task number corresponding to any task work order, wherein the first task number is used to indicate the performance task to which the task work order belongs; a determination module, which is also used to determine the target performance task corresponding to both the first commitment scenario and the first task number from a plurality of pre-generated performance tasks; and a creation module 512, which is also used to establish a binding relationship between the task work order and the target performance task if the creation time of the task work order is later than the end time of the session corresponding to the target performance task.

[0089] Optionally, the monitoring module 513 is further configured to record the duration of non-execution when the second dialogue service client has not executed the task corresponding to the task work order; if the duration of non-execution reaches a second preset duration, send a second timeout reminder to the second dialogue service client to remind the second dialogue service client to execute the task corresponding to the task work order; if it is determined that the task corresponding to the task work order has been completed before the duration of non-execution reaches the second preset duration, detect whether other task work orders bound to the target fulfillment task have been executed; in response to determining that all task work orders bound to the target fulfillment task have been executed, determine that the target fulfillment task has been completed.

[0090] Optionally, the sending module is also used to send the commitment information and the execution status of the performance task to the user's client in the form of a preset content template.

[0091] like Figure 5B As shown, a task management device is provided, which may include a sending module 521 and a generating module 522. This task management device can be used to perform the above-described tasks. Figures 2A to 4 Some or all of the operations of the dialogue service client.

[0092] For example: the sending module 521 is used to send dialogue information to the server during a dialogue with the user; the generation module is used to generate commitment information based on the information corresponding to the three elements of commitment event, performance method and performance time limit sent by the server in response to receiving such information; the sending module 522 is also used to send the commitment information to the server so that the server generates a performance task based on the commitment information, and if it is determined that the performance task needs to be executed offline, creates at least one task work order corresponding to the performance task based on the task execution rules matched by the commitment information; for any task work order, the task work order is sent to the second dialogue service client and the execution status of the task work order is monitored until all tasks corresponding to the at least one task work order are executed.

[0093] Optionally, the task management device further includes a receiving module. The receiving module is used to receive task execution rules and prompt templates from the server, wherein the task execution rules match the commitment scenarios corresponding to the user's historical dialogue information, and the prompt templates are used to instruct the user to inquire about the information of the three elements; the receiving module is also used to receive input dialogue matching the commitment scenarios to confirm the information of the three elements with the user.

[0094] Optionally, the generation module 522 is further configured to display initial commitment information composed of information corresponding to the three elements respectively; if a sending operation is received, the initial commitment information is sent to the server as the commitment information; if a modification operation is received for the information of any element, the original information of the element is replaced with the modified information, and after receiving the confirmation operation, the initial commitment information after modification is sent to the server as the commitment information.

[0095] It is understandable that the above division of modules is only a logical functional division. In actual implementation, the functions of the above modules can be integrated into hardware entities. For example, the function of the sending module 521 can be integrated into the transceiver, and the functions of the generating module 511, the creation module 512, and the monitoring module 513 can be integrated into the processor, etc.

[0096] Please refer to Figure 6 , Figure 6 An electronic device 6 is provided, which can be implemented as carrying Figure 1 The electronic device includes a server 10 and any dialogue service client. It may include a processor 61, a transceiver 62, and a memory 63, which are connected and communicate via a communication bus 64. The transceiver 62 can be used for communication to transmit dialogue information and instructions related to task management. The memory 63 stores computer programs and data generated during task management; when the computer program is invoked, it causes the processor 61 to execute the aforementioned commands. Figures 2A to 4 The operation of some or all of the electronic devices.

[0097] For details on the implementation process, please refer to [link / reference]. Figures 2A to 4 The relevant descriptions are omitted here.

[0098] It should be understood that, in some feasible implementations, Figure 6 The processor illustrated can be a central processing unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. Figure 6The memory illustrated may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of the memory may also include non-volatile random access memory. For example, the memory may also store information such as the device type.

[0099] This application also provides a computer-readable storage medium storing image processing instructions, which, when executed on a computer, cause the computer to perform the aforementioned actions. Figures 2A to 4 Some or all of the steps in the method described in the illustrated embodiments.

[0100] This application also provides a computer program product that includes task management instructions, which, when run on a computer, causes the computer to perform the aforementioned... Figures 2A to 4 Some or all of the steps in the method described in the illustrated embodiments.

[0101] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0102] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0103] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0104] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0105] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, smartphone, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0106] Although alternative embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make further changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0107] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this application should be included within the scope of protection of this invention.

Claims

1. A task management method characterized by, The method comprises: in response to receiving commitment information sent by the first dialogue service client, generating a fulfillment task based on the commitment information, the commitment information comprising information of three elements of a commitment event, a fulfillment mode and a fulfillment time limit, the commitment information being generated based on dialogue information between the first dialogue service client and the user; in a case where it is determined that the fulfillment task needs to be executed offline, creating at least one task work order corresponding to the fulfillment task based on the task execution rule matched based on the commitment information; for any task work order, sending the task work order to the second dialogue service client and monitoring the execution of the task work order until the tasks corresponding to the at least one task work order are executed.

2. The method of claim 1, wherein, Before generating the fulfillment task based on the commitment information, further comprising: in response to detecting that the user is in dialogue with the first dialogue service client, identifying whether the dialogue information contains information of any one of the three elements; in a case where the dialogue information contains information of any one of the three elements, sending a prompt template to the first dialogue service client, the prompt template being used to instruct the first dialogue service client to ask for information of the three elements; in a case where the information of the three elements is extracted, sending initial commitment information composed of the information of the three elements to the first dialogue service client to enable the first dialogue service client to confirm whether the initial commitment information is the commitment information.

3. The method of claim 2, wherein, Further comprising: in response to detecting that the user is in dialogue with the first dialogue service client, identifying a commitment scenario based on historical dialogue information of the user; determining the task execution rule matched with the commitment scenario from a preset task execution rule library; sending the task execution rule to the first dialogue service client to trigger the first dialogue service client to output a script matched with the commitment scenario.

4. The method of claim 3, wherein, Further comprising: monitoring a session state of the user with the first dialogue service client; in a case where the session state is session end and the commitment information is not received, starting timing; if the commitment information is not received when the timing duration reaches a first preset duration, sending a first timeout reminder to the first dialogue service client to remind the first dialogue service client to send the commitment information.

5. The method of claim 1, wherein, After creating the at least one task work order corresponding to the fulfillment task based on the task execution rule matched based on the commitment information, further comprising: for any task work order, reading a first commitment scenario and a first task number corresponding to the task work order, the first task number being used to indicate a fulfillment task to which the task work order belongs; determining a target fulfillment task corresponding to both the first commitment scenario and the first task number from a plurality of pre-generated fulfillment tasks; if a creation time of the task work order is later than an end time of a session corresponding to the target fulfillment task, establishing a binding relationship between the task work order and the target fulfillment task.

6. The method of claim 5, wherein, The monitoring of the execution of the task work order comprises: in a case where the second dialogue service client does not execute the task corresponding to the task work order, recording a duration of non-execution; if the unexecuted duration reaches a second preset duration, sending a second timeout reminder to the second dialogue service client to remind the second dialogue service client to execute the task corresponding to the task order; if it is determined that the unexecuted duration reaches before the second preset duration, the task corresponding to the task order is completed, and whether other task orders bound by the target performance task are executed is detected; in response to determining that all task orders bound by the target performance task are executed, it is determined that the target performance task is completed.

7. The method of claim 1, wherein, After generating the performance task based on the commitment information, further comprising: sending the commitment information and the execution status of the performance task to the client of the user in a preset content template manner.

8. A task management method characterized by, The method comprises: sending dialogue information to a server in the process of dialogue with a user; in response to receiving information corresponding to three elements of a commitment event, a performance mode and a performance time limit sent by the server, generating commitment information according to information corresponding to the three elements respectively; sending the commitment information to the server, so that the server generates a performance task based on the commitment information, and creates at least one task order corresponding to the performance task based on the task execution rule matched by the commitment information in the case that the performance task needs to be executed offline; for any task order, the task order is sent to a second dialogue service client, and the execution of the task order is monitored until the tasks corresponding to the at least one task order are executed.

9. The method of claim 8, wherein, Before generating the commitment information according to information corresponding to the three elements respectively, further comprising: receiving task execution rules and prompt templates from the server, the task execution rules matching the commitment scene corresponding to the historical dialogue information of the user, and the prompt templates being used to instruct to inquire the information of the three elements; receiving inputted dialogue matching the commitment scene to determine the information of the three elements with the user.

10. The method according to claim 8 or 9, characterized in that, The commitment information generated according to the information corresponding to the three elements respectively comprises: displaying initial commitment information composed of information corresponding to the three elements respectively; if a sending operation is received, the initial commitment information is sent to the server as the commitment information; if a modification operation for the information of any element is received, the original information of the element is replaced with the modified information, and after receiving the confirmation operation, the initial commitment information after modification is sent to the server as the commitment information.

11. A task management system, characterized by The system comprises a server and a plurality of dialogue service clients, a first dialogue service client, configured to send dialogue information to the server in the process of dialogue with a user; the server is configured to identify information corresponding to three elements of a commitment event, a performance mode and a performance time limit from the dialogue information, and send information corresponding to the three elements of the commitment event, the performance mode and the performance time limit to the first dialogue service client; the server is configured to identify information corresponding to three elements of a commitment event, a performance mode and a performance time limit from the dialogue information, and send information corresponding to the three elements of the commitment event, the performance mode and the performance time limit to the first dialogue service client; The first dialogue service client is further configured to generate commitment information according to information corresponding to the three elements respectively, and send the commitment information to the server. The server is further configured to generate a performance task based on the commitment information, and create at least one task work order corresponding to the performance task based on a task execution rule matched by the commitment information in a case where the performance task needs to be executed offline; for any task work order, send the task work order to a second dialogue service client, and monitor execution of the task work order until tasks corresponding to the at least one task work order are all executed. The first dialogue service client and the second dialogue service client belong to the plurality of dialogue service clients.

12. A task management apparatus characterized by comprising: The apparatus comprises: The generating module is configured to generate a performance task based on commitment information in response to receiving the commitment information sent by the first dialogue service client, the commitment information including information of three elements of a commitment event, a performance mode, and a performance time limit, the commitment information being generated based on dialogue information of the first dialogue service client and a user; The creating module is configured to create at least one task work order corresponding to the performance task based on a task execution rule matched by the commitment information in a case where the performance task needs to be executed offline. The monitoring module is configured to send the task work order to a second dialogue service client for any task work order, and monitor execution of the task work order until tasks corresponding to the at least one task work order are all executed.

13. A task management apparatus characterized by comprising: The apparatus comprises: The sending module is configured to send dialogue information to a server in a process of dialogue with a user; The generating module is configured to generate commitment information according to information corresponding to the three elements respectively in response to receiving information corresponding to three elements of a commitment event, a performance mode, and a performance time limit respectively sent by the server; The sending module is further configured to send the commitment information to the server, so that the server generates a performance task based on the commitment information, and creates at least one task work order corresponding to the performance task based on a task execution rule matched by the commitment information in a case where the performance task needs to be executed offline; for any task work order, sends the task work order to a second dialogue service client, and monitors execution of the task work order until tasks corresponding to the at least one task work order are all executed.

14. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the method of any one of claims 1-10.

15. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-10.

16. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-10.

Images