To-do task notification method and apparatus

Abstract

Embodiments of the present application relate to a to-do task notification method and device, and the embodiments of the present application obtain historical task handling data of each different entity, portrait the target entity according to the historical task handling data, determine the disposal probability distribution of the to-do task in different dimensions, then calculate the notification strategy score of different candidate notification strategies according to the disposal probability distribution, and further determine the initial notification strategy based on the notification strategy score, and notify the to-do task according to the initial notification strategy. Therefore, different entity internal organization structures and different actual management can be compatible, the portrait of the entity is formed, the notification strategy is flexibly selected based on the actual situation of each entity, so that the reach rate and disposal rate of the to-do task notification message are ensured, and the operation efficiency of the collaboration system is improved. Further, the production efficiency can be improved.

Description

Technical Field

[0001] This invention relates to the fields of information technology and the Internet, and specifically to a method and apparatus for notifying users of pending tasks. Background Technology

[0002] Mobile internet technology, through big data and instant messaging technologies, enables large-scale human resources to conduct complex collaborative labor and business operations based on communication terminals and servers. In these collaborative systems based on the internet and other communication systems, pending tasks are continuously generated according to the actual needs of business operations. These tasks are then notified and assigned to the personnel requiring processing via communication terminals. Delayed processing can negatively impact the customer experience of the entire business operation. This is particularly prominent in user-facing businesses. Furthermore, different personnel, as part of the organization, are assigned to different teams or more independent self-operated entities. The internal organizational management methods and personnel composition of different teams or entities vary significantly.

[0003] Therefore, there is an urgent need for information interaction methods adapted to the above scenarios to ensure that to-do task notifications can be effectively delivered and processed and responded to. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method and apparatus for notifying pending tasks, so as to improve the reach and processing rate of pending task notification messages in collaborative computer systems and improve the notification efficiency of collaborative computer systems.

[0005] Firstly, a method for notifying users of pending tasks is provided, wherein the method includes:

[0006] Obtain historical task handling data of the target entity, wherein the historical task handling data includes the event type and handling information of the historical task, and the handling information includes the handling time, the notification channel that triggered the handling and the notification role, and the target entity is an organization with multiple roles, and each event type corresponds to at least one role;

[0007] Based on the historical task handling data, determine the handling probability distribution of each event type of the target entity in terms of notification time dimension, notification channel dimension, and notification role dimension.

[0008] In response to the generation of a new task, determine the target event type of the task.

[0009] Based on the target entity and the target event type, multiple candidate notification strategies are determined, and the notification strategy includes notification time, notification channel and notification role;

[0010] The notification strategy score corresponding to each candidate notification strategy is calculated based on the notification time dimension, notification channel dimension, and notification role dimension of the notification probability distribution of the target event type of the target entity.

[0011] An initial notification strategy is determined from multiple candidate notification strategies based on the notification strategy score.

[0012] The notification information for the pending task is sent according to the initial notification strategy.

[0013] Secondly, a task notification device is provided, wherein the device includes:

[0014] The acquisition unit is used to acquire historical task handling data of the target entity. The historical task handling data includes the event type and handling information of the historical task. The handling information includes the handling time, the notification channel that triggered the handling, and the notification role. The target entity is an organization with multiple roles, and each event type corresponds to at least one role.

[0015] The distribution determination unit is used to determine the handling probability distribution of each event type of the target entity in terms of notification time dimension, notification channel dimension, and notification role dimension based on the historical task handling data.

[0016] A type determination unit is used to determine the target event type of a new task in response to its generation.

[0017] The candidate strategy determination unit is used to determine multiple candidate notification strategies based on the target entity and the target event type. The notification strategy includes notification time, notification channel and notification role.

[0018] A calculation unit is used to calculate the notification strategy score corresponding to each candidate notification strategy of the target entity;

[0019] A strategy determination unit is used to determine an initial notification strategy from multiple candidate notification strategies based on the notification strategy score.

[0020] The notification unit is used to send notification information for the pending task according to the initial notification strategy.

[0021] Thirdly, an electronic device is provided, the controller including a memory and a processor, the memory for storing one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in the first aspect.

[0022] Fourthly, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the method described in the first aspect.

[0023] This invention, through its embodiments, acquires historical task processing data from various entities within a collaborative computer system. Based on this data, it creates a profile of the target entity, determines the probability distribution of task processing across different dimensions, calculates notification strategy scores for different candidate notification strategies based on these probability distributions, and then determines an initial notification strategy. The system then notifies user terminals of the tasks to be completed according to this initial notification strategy. This approach is compatible with different internal organizational structures and management practices of entities, creating a profile of each entity and allowing for flexible selection of notification strategies based on the specific circumstances of each entity. This ensures high reach and processing rates for task notification messages, improving the operational efficiency of the collaborative system and ultimately enhancing productivity. Attached Figure Description

[0024] The above and other objects, features and advantages of the present invention will become clearer from the following description of embodiments of the invention with reference to the accompanying drawings, in which:

[0025] Figure 1 This is a block diagram of the to-do task notification system according to an embodiment of the present invention;

[0026] Figure 2 This is a software architecture diagram of the server-side application of the to-do task notification system according to an embodiment of the present invention.

[0027] Figure 3 This is a flowchart of the to-do task notification method according to an embodiment of the present invention;

[0028] Figure 4 This is a flowchart illustrating the acquisition of historical task processing data according to an embodiment of the present invention;

[0029] Figure 5 This is a data flow diagram of the to-do task notification method according to an embodiment of the present invention;

[0030] Figure 6 This is a schematic diagram of the to-do task notification device according to an embodiment of the present invention;

[0031] Figure 7 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0032] The present application is described below based on embodiments, but it is not limited to these embodiments. In the detailed description of the present application below, certain specific details are described in detail. Those skilled in the art can fully understand the present application without these details. To avoid obscuring the substance of the present application, well-known methods, processes, flows, elements, and circuits are not described in detail.

[0033] Furthermore, those skilled in the art should understand that the accompanying drawings provided herein are for illustrative purposes only and are not necessarily drawn to scale.

[0034] Unless the context explicitly requires it, words such as "including" or "contains" throughout the application should be interpreted as including rather than exclusive or exhaustive; that is, meaning "including but not limited to".

[0035] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0036] The solutions described in this specification and embodiments, if involving the processing of personal information, will be processed only under the premise of having a legal basis (such as obtaining the consent of the personal information subject, or being necessary for the performance of a contract), and will only be processed within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0037] In the following description, the example of a pending task notification in charging station operation is used for illustration. It should be understood that the methods and apparatus of the embodiments of the present invention can also be applied to other collaborative computer systems with multiple relatively independent operating entities, each entity having multiple different operating or management role accounts.

[0038] In the operation of charging stations, due to offline operations, numerous tasks need to be handled, including finance, hardware technology, customer service, and events related to the power system. Typically, charging stations assign these tasks to different role accounts (hereinafter referred to as roles). For example, finance is handled by the finance department, hardware technology by engineers, power system management by administrators, and customer service includes both online and offline support. Online customer service answers user questions via the internet or telephone, while offline customer service provides on-site service to users charging at the station. To organize all personnel to collaborate and ensure the normal operation of the charging station, the collaboration system assigns different role accounts to different personnel and notifies the corresponding role account's user terminal of pending tasks according to the division of labor. For example, if a charging user needs an invoice, the pending task will be notified to the finance department in the collaboration system. Similarly, if charging equipment malfunctions and needs repair, the pending task will be notified to the engineers. Furthermore, if a user finishes charging but occupies a charging space, and needs to be notified to move their vehicle, the pending task will be notified to customer service. However, in existing collaborative systems, tasks are actually scattered across different modules of the client application, requiring users with different roles to search for their tasks in different parts of the application. Furthermore, due to busy schedules, some tasks are often left unfinished for extended periods, impacting user experience, reducing operational efficiency, and even causing security issues. Therefore, a better method and device for notifying users of tasks is needed to improve the efficiency of information exchange and task processing.

[0039] Figure 1 This is a block diagram of a to-do task notification system according to an embodiment of the present invention. Figure 1 As shown, the to-do task notification system of this invention includes a server 1 and a user terminal 2. The server 1 and the user terminal 2 are interconnected via a network 3 to achieve information and data interaction.

[0040] Server 1 should be understood as a device that provides data processing, database, and communication facilities. For example, server 1 may refer to a single physical processor with associated communication, data storage, and database facilities, or it may refer to a networked or aggregated collection of processors, associated networks, and storage devices, operating software and one or more database systems and application software that support the services provided by the server. Server 1 may be a monolithic server or a distributed server spanning multiple computers or computer data centers. Server 1 may be various types of cloud servers. In some embodiments, each server 1 may include hardware, software, or embedded logic components or combinations of two or more such components for performing suitable functions supported or implemented by the server.

[0041] User terminal 2 can be a mobile phone, tablet computer, PDA, wearable device, etc. User terminal 2 has a communication module capable of wired or wireless communication. In one embodiment, user terminal 3 includes at least one remote communication module, such as any module for WLAN, GPRS, 2G / 3G / 4G / 5G remote communication. User terminal 2 may also include at least one short-range communication module, such as any module for short-range wireless communication based on short-range wireless communication protocols such as Bluetooth, ZigBee, NFC, UWB, etc. User terminal 2 also has an input device, which may include, for example, a touchscreen, buttons, pressure sensors, etc., through which user terminal 2 can receive user commands.

[0042] User terminal 2 and server 1 can communicate via network 3. User terminal 2 has a client application installed, and server 1 has a server application installed. Server 1 can send in-app messages, SMS messages, or make phone calls to the client application of user terminal 2 through the server application, thereby issuing notifications and assigning pending tasks to the client application and realizing collaborative business operations.

[0043] Figure 2 This is a block diagram of the server-side application according to an embodiment of the present invention. Figure 2As shown, the server-side application 11 includes a business module service 111, a queue service 112, a task notification service 113, a database 114, and a reach service 115. In this embodiment, the business module service 111 is used to provide business-level logic management, particularly in response to user requests or the triggering of actual events (such as detecting a hardware failure in charging equipment) to generate tasks to be processed. After generating tasks to be processed, the business module 111 publishes them to the queue service 112. The queue service 112 can manage the tasks to be processed in different channels according to the target entity (i.e., a specific charging station) corresponding to the task. The queue management can include sorting the queues, adjusting the order, and pushing or sending the tasks in the queues to the subsequent task notification service. The task notification service 113 is used to receive new tasks from the queue service 112, determine the notification strategy, and then use the reach service 115 to notify the user terminal 2 of the tasks to be processed. The notification channels (also called notification methods) include in-app messages, SMS, and voice calls. Simultaneously, in-application messages can be categorized into different levels for notification with varying priorities. The task notification server 113 also receives processing feedback information from the business module service 111 after tasks have been processed. The task notification service 113 can maintain data in the database 114 based on this processing feedback information. For example, task processing information for different target entities in the database 114. The task notification service 113 can select notification strategies based on the data maintained in the database 114. It should be understood that server-side services refer to applications or functional modules running on a server, responsible for handling requests from clients and returning corresponding responses. These services typically include web applications, API interfaces, database management, and file services. The core task of a service is to receive client requests, parse the request content, execute corresponding data processing logic (such as database queries and data processing), generate response data, and finally send the response back to the requesting client. These services communicate with clients or other services via network protocols (such as HTTP and HTTPS) to implement their respective data processing logic.

[0044] Figure 3 This is a flowchart of the to-do task notification method according to an embodiment of the present invention. Figure 3 As shown, the method of this embodiment of the invention includes the following steps:

[0045] Step S100: Obtain historical task handling data of the target entity.

[0046] The historical task handling data includes the event type and handling information of the historical tasks. The handling information includes the handling time, the notification channel that triggered the handling, and the notification role. In this implementation, the target entity is an organization with multiple roles, such as the operating organization of a charging station, which may be an independent company or an independent department within a company. Each employee in the target entity is assigned a corresponding role. These roles correspond to event types. In this embodiment, each event type corresponds to at least one role. Simultaneously, each role may correspond to one or more event types. Furthermore, in a collaborative system, the roles of "administrator" and / or "super administrator" are typically set up. In this embodiment, "administrator" and / or "super administrator" can correspond to all event types. Therefore, various types of pending tasks related to the charging station can be handled by the "administrator" and / or "super administrator".

[0047] In one alternative implementation, the historical task processing data of the target entity can be obtained by executing pending task notifications according to a predetermined pattern within a predetermined time period, and then accumulating the handling information of the pending tasks.

[0048] Figure 4 This is a flowchart illustrating the acquisition of historical task processing data according to an embodiment of the present invention. Figure 4 As shown, the process of acquiring historical task processing data includes:

[0049] Step S110: Determine the new task to be done.

[0050] If a business module service receives a user request (e.g., a request to issue an invoice) or is triggered by an automatically detected event, a new to-do task is generated. It should be understood that the to-do tasks mentioned above and in this document refer to data objects that can be processed and displayed on the server and user terminal, pointing to events that actually require processing.

[0051] Step S120: Notify the pending tasks according to the notification strategy.

[0052] When notifying users of pending tasks for the first time, a default notification strategy is used. This default notification strategy includes a default notification time, a default notification method, and a default notification role. This default notification strategy is preset.

[0053] Step S130: Determine whether processing feedback information has been received within the predetermined time period. That is, determine whether the pending task notification has effectively reached the corresponding role and whether the role has effectively processed the task. If not, proceed to step 140; if yes, proceed to step 150.

[0054] Step S140: If no processing feedback information is received within the predetermined time period, then based on the default notification policy, one or more of the following are performed to determine a new notification policy: change the notification time, upgrade the notification channel, or upgrade the notification role. At least one of the notification time, notification channel upgrade, or notification role in the new notification policy differs from the original notification policy.

[0055] In step S150, if processing feedback information is received within a predetermined time period, processing information is collected. Then, the collected processing information and relevant information about the pending tasks (e.g., event type) can be stored as historical task processing data in a database.

[0056] Let's take the example of a user at a charging station requesting an invoice through the charging user application. Issuing invoices is a core responsibility of the finance role. If a new invoice issuance task is generated, the initial notification will follow the default notification time (when the request is received), the default channel (the lowest response level system message), and the default role (the finance role responsible for the task). This way, the finance user's terminal will immediately receive the system message from the server.

[0057] If the finance department promptly checks the system messages and issues an invoice, the business module will send a processing feedback message.

[0058] If the finance department fails to complete the invoice issuance task within the predetermined timeframe, the business module will be unable to send processing feedback information. The notification strategy will be redefined and upgraded to increase the probability of being processed or reached. For example, the new notification strategy could change the notification time to the working hours of 8:00-16:00, upgrade the notification channel to SMS or telephone, or upgrade the notification role. In this example, the role chain corresponding to the invoice issuance event type, ranked by priority, is Finance, Finance Supervisor, and Administrator. The Finance Supervisor is the Finance Department's superior. The Administrator is responsible for coordinating all work of the corresponding target entity. Therefore, to upgrade the notification role, the new notification strategy can set the notification role to the higher-level Finance Supervisor. If necessary, the notification role can also be directly upgraded to Administrator. It should be understood that the new notification strategy can upgrade only one notification element or upgrade multiple notification elements simultaneously. Furthermore, if the task still cannot be processed in a timely manner after being notified based on the new notification strategy, a new notification strategy will be determined again, and this process will be repeated until the task is processed or all possible notification strategies have been adopted.

[0059] Through the above steps, after a period of operation, historical task handling data for each target entity can be accumulated. This historical task handling data includes the event type and handling information of the historical tasks. The handling information includes the handling time, the notification channel that triggered the handling, and the notification role. The notification channel and notification role that triggered the handling refer to the notification channel and notification role corresponding to the notification strategy of the most recent notification before the pending task was processed. This completes the data accumulation for the target entity.

[0060] After accumulating data, data analysis can be used to create a "profile" for each target entity.

[0061] In step S200, the probability distributions of notification time, notification channel, and notification role for each event type of the target entity are determined based on the historical task handling data.

[0062] Because different event types correspond to significantly different roles, data analysis is conducted separately for each event type. Since notification strategies involve three elements—notification time, notification channel, and notification role—further statistical analysis is performed on each of these three dimensions to examine the impact of different choices on the handling of pending tasks.

[0063] For example, charging equipment fault repair and charging equipment maintenance are different tasks, but since both are handled by maintenance engineers, they both fall under the category of equipment maintenance. Therefore, we can obtain information on all charging equipment fault repair and maintenance tasks from historical task handling data, or information from a predetermined time period (e.g., the past two months), to determine the handling probability distribution for different notification times, different notification channels, and different notification roles. In the time dimension, a day can be divided into different time periods, such as working hours and off-hours, or even every two hours. Then, for all historical task handling data of all equipment maintenance types, the number of samples whose notification time falls within a certain time period A and is handled within a predetermined time cycle is denoted as X; the number of samples whose notification time falls within a certain time period but is not handled within a predetermined time cycle is denoted as Y. The handling probability corresponding to time period A can be determined by X / (X+Y). Similarly, by calculating the handling probability for each time period, we can obtain the processing probability distribution in the time dimension. The probability distribution of the treatment can be stored in a table or fitted as a curve with time as the coordinate axis.

[0064] Similarly, at the notification channel level, for different notification channels, the number of samples that are notified through a certain notification channel B and then processed within a predetermined time period is denoted as M; the number of samples that are notified through a certain notification channel B and then fail to be processed within the predetermined time period is denoted as N. The processing probability corresponding to notification channel B can be determined by M / (M+N). By calculating the processing probability of each notification channel in this way, the processing probability distribution at the notification channel level can be obtained.

[0065] In the notification role dimension, for different notification roles, the number of samples that are notified to a certain notification role C and then receive action within a predetermined time period is denoted as P; the number of samples that are notified to a certain notification role C and then fail to receive action within the predetermined time period is denoted as Q. The action probability corresponding to notification role C can be determined by P / (P+Q). By calculating the action probability for each notification role in this way, the processing probability distribution of the notification role dimension can be obtained.

[0066] It should be understood that the above-mentioned disposal probability can also be calculated in other ways. For example, the disposal probability can be calculated as the ratio of the disposal samples for the corresponding dimension of notification time / notification channel / notification role to the total number of samples.

[0067] Based on the disposal probability distribution obtained in this step, we can determine the likelihood of using different notification strategies to ensure timely notification of pending tasks for specific event types of the target entity.

[0068] Step S300: In response to the generation of a new task, determine the target event type of the task.

[0069] Step S400: Based on the target entity and the target event type, determine multiple candidate notification strategies. The notification strategy includes notification time, notification channel, and notification role.

[0070] Specifically, step S400 includes:

[0071] Step S410: Based on the role and responsibility information of the target entity and the target event type, determine multiple candidate notification roles, wherein the candidate notification roles are those whose responsibilities include the target event type.

[0072] The mapping between notification roles and event types can be predefined. Furthermore, multiple notification roles corresponding to the same event type can have different priorities. In this description, role priority refers to notification priority; notifications for pending tasks should prioritize roles with matching responsibilities and lower positions.

[0073] Step S420: Determine multiple candidate notification channels and multiple candidate notification times.

[0074] Candidate notification channels and candidate notification times represent all possible notification channels and times to choose from. Different candidate notification channels can also be assigned different priorities. For example, system notifications have a higher priority, while telephone notifications have a lower priority because they are more disruptive to the recipient.

[0075] Step S430: Determine the multiple candidate notification strategies based on the candidate notification role, candidate notification channel, and candidate notification time.

[0076] Specifically, multiple different candidate notification strategies can be determined by arranging and combining all candidate notification roles, candidate notification channels, and candidate notification times.

[0077] Step S500: Calculate the notification strategy score corresponding to each candidate notification strategy based on the notification time dimension, notification channel dimension, and notification role dimension of the notification probability distribution of the target event type of the target entity.

[0078] In this step, for each candidate notification strategy, the corresponding handling probability for each dimension is obtained based on the notification time, notification channel, and notification role in the notification strategy. Then, the notification strategy score corresponding to the candidate notification strategy is calculated based on the handling probabilities of the three dimensions.

[0079] In one optional implementation, the notification strategy score is calculated by weighted summation of the probabilities of action corresponding to the notification time, the notification channel, and the notification role of the candidate notification strategy. That is, the probability of user action influenced by notification time is denoted as pT, the probability of user action influenced by notification channel is denoted as pC, and the probability of user action influenced by notification role is denoted as pR. Weights wT, wC, and wR are assigned to each dimension:

[0080] Notification strategy score = wT*pT + wC*pC + wR*pR.

[0081] In some implementations, the weights are preset.

[0082] In other implementations, the weights change dynamically based on the current notification round. As the notification round increases, the weights wC and wR are gradually increased, thereby increasing the influence of the notification channel and notification role on the selection of candidate notification strategies.

[0083] Step S600: Determine an initial notification strategy from multiple candidate notification strategies based on the notification strategy score.

[0084] In some implementations, the candidate notification strategy with the highest score can be selected as the initial notification strategy, thereby ensuring the highest reach rate and processing rate of pending tasks.

[0085] In some implementations, rule constraints can be added to the notification strategy score. That is, the initial notification strategy is determined from multiple candidate notification strategies based on the notification strategy score and preset rule constraints. This is because, for initial notifications, the lowest-level roles should be prioritized. Simultaneously, high-reach-rate but highly disruptive telephone calls should be avoided to achieve a balance between timely handling of pending tasks and minimizing disruption to operational processes. Therefore, certain constraints need to be placed on notification roles and channels. For example, a rule can be set that when determining the initial notification strategy, the N highest-priority notification channels and roles (N greater than or equal to 1) must be selected. As mentioned above, high-priority notification channels and roles are those with less disruption and lower-ranking roles. This avoids notifying higher levels of pending events every time. Alternatively, a rule can be set to apply a certain attenuation coefficient to low-priority notification channels and roles in the notification strategy. If a notification strategy includes a low-priority notification channel or role, the notification strategy score is multiplied by this attenuation coefficient before selecting the initial notification strategy. Furthermore, as the number of notification rounds increases, the attenuation coefficient gradually increases, thereby gradually removing the restrictions on low-priority notification channels or notification roles.

[0086] Step S700: Send notification information for the pending task according to the initial notification policy or the upgrade notification policy.

[0087] Specifically, notification information is sent to the user terminal of the notification role in the notification policy according to the notification event and notification channel in the notification policy.

[0088] In step S800, in response to the failure to receive feedback information on the handling of the pending task within the predetermined time period, an escalation notification strategy is determined, and the process returns to step S700.

[0089] In some implementations, upgrading the notification policy can be achieved by: identifying time periods with higher probability of action; identifying notification channels with higher response priority; or identifying a higher-level notification role among the candidate notification roles. Upgrading the notification policy can also be accomplished through one or more of the above operations.

[0090] In other implementations, the scope of candidate notification strategies can be gradually increased based on rules as the notification rounds increase. For example, at the initial notification, the scope of candidate notification strategies does not include notification strategies that use low-priority notification channels and / or low-priority notification roles. However, as the notification rounds increase, notification strategies that use low-priority notification channels and / or low-priority notification roles are also added as candidate notification strategies. The strategy with the highest notification strategy score is then re-determined as the upgraded notification strategy.

[0091] In other implementations, the weights of notification channels and roles in the notification strategy scoring calculation can be dynamically increased as the number of notification rounds increases. This allows the scoring of notification strategies that would have previously used low-priority notification channels and / or low-priority notification roles to be recalculated, thus determining the upgrade notification strategy.

[0092] After determining the escalation notification strategy, the process can return to step S700 to notify the pending tasks based on the escalation notification strategy. This process iteratively executes the steps of determining the notification strategy and notifying based on the strategy until the pending tasks are processed.

[0093] The upgrade notification strategy can be a strategy that is re-established after the previous upgrade notification and the pending tasks have not been processed in a timely manner.

[0094] Furthermore, in this embodiment, after receiving feedback information on the handling of a pending task, historical task handling data for that task can also be recorded to further accumulate new data. Therefore, based on actual notifications and task handling status, the probability distribution data related to different dimensions of the target entity and task handling can be continuously updated, thereby constantly adapting to changes in the target entity and business situation and updating the data accordingly.

[0095] Figure 5 This is a data flow diagram of the to-do task notification method according to an embodiment of the present invention. For example... Figure 5As shown, firstly, the historical task handling data 51 of the target entity is determined. As mentioned above, the historical task handling data 51 is obtained by recording the handling status of a pending task notification process that runs for a period of time according to a predetermined method. Then, by analyzing the historical task handling data 51, the handling probability distributions 52a (notification time dimension), 52b (notification channel dimension), and 52c (notification role dimension) corresponding to different event types 52 can be obtained. Thus, for a new pending task 53, its target event type 54 can be determined. Based on the target event type 54, multiple candidate notification strategies 55 can be determined. Then, the corresponding notification strategy score 56 can be calculated based on the candidate notification strategies 55. The initial notification strategy 57 is determined based on the notification strategy score 56. Notification is made based on the initial notification strategy 57. If the pending task is not handled in a timely manner, that is, no task handling feedback information is received within the predetermined time, then an escalation notification strategy 58 is determined again based on the candidate notification strategy 55, or the escalation notification strategy 58 is determined based on the initial notification strategy 57, and notification is made based on the escalation notification strategy 58. And so on.

[0096] This invention, through its embodiments, acquires historical task processing data from various entities, creates a profile of the target entity based on this data, determines the probability distribution of task processing across different dimensions, calculates notification strategy scores for different candidate notification strategies based on these probability distributions, and then determines an initial notification strategy based on these scores. Task notifications are then sent according to this initial strategy. This approach is compatible with different internal organizational structures and management practices of various entities, creating a profile of each entity and allowing for flexible selection of notification strategies based on the specific circumstances of each entity. This ensures high reach and processing rates for task notification messages, improving the operational efficiency of the collaborative system and ultimately enhancing productivity.

[0097] Figure 6 This is a schematic diagram of a task notification device according to an embodiment of the present invention. Figure 6 As shown, the task notification device in this embodiment includes an acquisition unit 61, a distribution determination unit 62, a type determination unit 63, a candidate strategy determination unit 64, a calculation unit 65, a strategy determination unit 66, and a notification unit 67.

[0098] The system includes the following components: Acquisition unit 61 acquires historical task handling data of the target entity, including event types and handling information. The handling information includes handling time, the notification channel that triggered the handling, and the notification role. The target entity is an organization with multiple roles, and each event type corresponds to at least one role. Distribution determination unit 62 determines the handling probability distributions for each event type of the target entity based on the historical task handling data, including the handling probability distributions for notification time, notification channel, and notification role. Type determination unit 63 determines the target event type of a new task in response to its generation. Candidate strategy determination unit 64 determines multiple candidate notification strategies based on the target entity and the target event type, including notification time, notification channel, and notification role. Calculation unit 65 calculates the notification strategy score for each candidate notification strategy of the target entity. Strategy determination unit 66 determines an initial notification strategy from among the multiple candidate notification strategies based on the notification strategy scores. Notification unit 67 sends the notification information for the task according to the initial notification strategy.

[0099] This invention, through its embodiments, acquires historical task processing data from various entities, creates a profile of the target entity based on this data, determines the probability distribution of task processing across different dimensions, calculates notification strategy scores for different candidate notification strategies based on these probability distributions, and then determines an initial notification strategy based on these scores. Task notifications are then sent according to this initial strategy. This approach is compatible with different internal organizational structures and management practices of various entities, creating a profile of each entity and allowing for flexible selection of notification strategies based on the specific circumstances of each entity. This ensures high reach and processing rates for task notification messages, improving the operational efficiency of the collaborative system and ultimately enhancing productivity.

[0100] Figure 7 This is a schematic diagram of an electronic device according to an embodiment of the present invention. (For example...) Figure 7 As shown, the electronic device includes a general computer hardware structure, which includes at least a processor 71 and a memory 72.

[0101] Processor 71 and memory 72 are connected via bus 73. Memory 72 is adapted to store instructions or programs executable by processor 71. Processor 71 may be a standalone microprocessor or a collection of one or more microprocessors. Thus, processor 71 executes the instructions stored in memory 72 to perform the method flow of the embodiments of the present invention as described above, thereby realizing data processing and control of other devices. Bus 73 connects the aforementioned components together, and also connects the aforementioned components to display controller 74, display device, and input / output (I / O) device 75. Input / output (I / O) device 75 may be a mouse, keyboard, modem, network interface, touch input device, motion-sensing input device, printer, and other devices known in the art. Typically, input / output device 75 is connected to the system via input / output (I / O) controller 76.

[0102] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus (devices), or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0103] This application is described with reference to flowchart illustrations of methods, apparatus (devices), and computer program products according to embodiments of this application. It should be understood that each step in the flowchart can be implemented by computer program instructions.

[0104] These computer program instructions may be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including an instruction means, the implementation process of which is described in the instruction means. Figure 1 The function specified in one or more processes.

[0105] These computer program instructions may also be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, produce instructions for implementing processes. Figure 1 A device for a function specified in one or more processes.

[0106] Another embodiment of the present invention relates to a non-volatile storage medium for storing a computer-readable program for use by a computer to execute some or all of the above-described method embodiments.

[0107] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program specifying the relevant hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0108] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for notifying users of pending tasks, characterized in that, The method includes: Obtain historical task handling data of the target entity, wherein the historical task handling data includes the event type and handling information of the historical task, and the handling information includes the handling time, the notification channel that triggered the handling and the notification role, and the target entity is an organization with multiple roles, and each event type corresponds to at least one role; Based on the historical task handling data, determine the handling probability distribution of each event type of the target entity in terms of notification time dimension, notification channel dimension, and notification role dimension. In response to the generation of a new task, determine the target event type of the task. Based on the target entity and the target event type, multiple candidate notification strategies are determined, and the notification strategy includes notification time, notification channel and notification role; The notification strategy score corresponding to each candidate notification strategy is calculated based on the notification time dimension, notification channel dimension, and notification role dimension of the notification probability distribution of the target event type of the target entity. An initial notification strategy is determined from multiple candidate notification strategies based on the notification strategy score. The notification information for the pending task is sent according to the initial notification strategy.

2. The method according to claim 1, characterized in that, After sending the notification information for the pending task, the method further includes: In response to the failure to receive feedback on the handling of the pending task within the predetermined time period, an escalation notification strategy is determined; The notification information for the pending task is sent according to the upgrade notification policy, wherein at least one of the notification time, notification channel, or notification role of the upgrade notification policy is different from the initial notification policy.

3. The method according to claim 2, characterized in that, After sending the notification information for the pending task according to the upgrade notification strategy, the method further includes iteratively executing the following steps until the processing feedback information for the pending task is received: If no feedback information regarding the handling of the pending task is received within the predetermined time period, the escalation notification strategy is redefined; The notification information for the pending task is sent according to the redefined upgrade notification policy, wherein at least one of the notification time, notification channel, or notification role of the redefined upgrade notification policy is different from the upgrade notification policy of the previous iteration.

4. The method according to claim 2, characterized in that, Based on the target entity and the target event type, multiple candidate notification strategies are determined, including: Based on the role and responsibility information of the target entity and the type of the target event, multiple candidate notification roles are determined, wherein the candidate notification roles are those whose responsibilities include the type of the target event; Identify multiple candidate notification channels and multiple candidate notification times; The multiple candidate notification strategies are determined based on the candidate notification role, candidate notification channel, and candidate notification time.

5. The method according to claim 4, characterized in that, Determining or redefining the upgrade notification policy includes at least one of the following: Identify time periods with a higher probability of intervention; Determine the notification channel with higher response priority; or A higher-level notification role is determined from the candidate notification roles.

6. The method according to claim 1, characterized in that, Based on the historical task handling data, the probability distributions for handling each event type of the target entity are determined as follows: (Notification time dimension, notification channel dimension, and notification role dimension). Determine the target event type of the target entity; For the historical task handling data corresponding to the target event type, determine the number of tasks handled and the number of tasks not handled for different notification time intervals, and calculate the handling probability for each notification time interval based on the number of tasks handled and the number of tasks not handled, thereby obtaining the handling probability distribution of the notification time dimension. For the historical task handling data corresponding to the target event type, determine the number of tasks handled and the number of tasks not handled for different notification channels, and calculate the handling probability for each notification channel based on the number of tasks handled and the number of tasks not handled, thereby obtaining the handling probability distribution of the notification channel dimension. For the historical task handling data corresponding to the target event type, determine the number of tasks handled and the number of tasks not handled for different notification roles, and calculate the handling probability for each notification role based on the number of tasks handled and the number of tasks not handled, thereby obtaining the handling probability distribution of the notification role dimension.

7. The method according to claim 4, characterized in that, The notification strategy score is calculated by weighted summation of the processing probability corresponding to the notification time, the processing probability corresponding to the notification channel, and the processing probability corresponding to the notification role of the candidate notification strategy. Determining the initial notification strategy from multiple candidate notification strategies based on the notification strategy score includes: An initial notification strategy is determined from multiple candidate notification strategies based on the notification strategy score and preset rule constraints.

8. The method according to claim 4, characterized in that, The notification strategy score is calculated by weighted summation of the processing probability corresponding to the notification time, the processing probability corresponding to the notification channel, and the processing probability corresponding to the notification role of the candidate notification strategy. This includes determining or redetermining the upgrade notification policy, which includes: The notification strategy score for each candidate notification strategy is recalculated by weighting and summing the results according to the weights corresponding to the upgrade round. The upgrade notification strategy is determined based on the notification strategy score.

9. A task notification device, characterized in that, The device includes: The acquisition unit is used to acquire historical task handling data of the target entity. The historical task handling data includes the event type and handling information of the historical task. The handling information includes the handling time, the notification channel that triggered the handling, and the notification role. The target entity is an organization with multiple roles, and each event type corresponds to at least one role. The distribution determination unit is used to determine the handling probability distribution of each event type of the target entity in terms of notification time dimension, notification channel dimension, and notification role dimension based on the historical task handling data. A type determination unit is used to determine the target event type of a new task in response to its generation. The candidate strategy determination unit is used to determine multiple candidate notification strategies based on the target entity and the target event type. The notification strategy includes notification time, notification channel and notification role. A calculation unit is used to calculate the notification strategy score corresponding to each candidate notification strategy of the target entity; A strategy determination unit is used to determine an initial notification strategy from multiple candidate notification strategies based on the notification strategy score. The notification unit is used to send notification information for the pending task according to the initial notification strategy.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory being used to store one or more computer program instructions, wherein the one or more computer program instructions are executed by the processor to implement the method as described in any one of claims 1-8.

11. A computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method as described in any one of claims 1-8.

Images