VIRTUAL PERSONAL ASSISTANT SYSTEMS AND METHODS

Methods and systems for managing agents and threads that form part of a virtual personal assistant system. One of the methods includes receiving a user request; associating a first agent with a triage state and a second agent with a queue state; providing a first thread associated with the user request to the first agent; receiving from the first agent at least one task to be performed to respond to the user request, the task forming part of the first thread; providing the first thread to the second agent, and removing the first thread from the second agent if the second agent does not act on the first thread according to a specified criteria, wherein an agent can only be in one of the triage state or the queue state at one time and an agent can work on a second thread only after stopping work on the first thread.

BACKGROUND

This specification relates to computer-implemented systems and methods for managing agents that perform work for a virtual personal assistant system.

A user of a virtual personal assistant system can send a request for an action to be completed by the system. One challenge faced by a virtual personal assistant system, that includes human agents, is tracking the time that human agents spend working on various tasks associated with fulfilling a user's request.

SUMMARY

One embodiment of a virtual personal assistant system can receive a user request in any of a variety of ways, e.g., by email, text, or voice command. In one embodiment, a virtual personal assistant system allows a user to make a request whenever the user desires regardless of whether a particular human assistant is available and the system will begin processing the user's request upon receipt increasing the usefulness of the system to the user. A virtual personal assistant system can include a plurality of human agents. Oftentimes, a virtual personal assistant system aims to record the time that a human agent spends working to fulfil a user request. One embodiment of a virtual personal assistant system described in this specification distinguishes between the time that the agent spends working and how the agent works (e.g., triaging a thread or working on a task that forms part of the thread), and the time the agent spends not working on a task, e.g., in a meeting on a different topic, on a break or at lunch.

One aspect provides a system including: one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations including: receiving a user request; associating a first agent with a triage state and a second agent with a queue state; providing a first thread associated with the user request to the first agent; receiving from the first agent at least one task to be performed to respond to the user request, the task forming part of the first thread; providing the first thread to the second agent, and removing the first thread from the second agent if the second agent does not act on the first thread according to a specified criteria, wherein an agent can only be in one of the triage state or the queue state at one time and an agent can work on a second thread only after stopping work on the first thread.

The operations can include separately, or in combination: moving an agent from a first state to a second offline state in response to inactivity by the agent for a specified period of time; and associating each of a plurality of agents with one of a plurality of states and where an agent can only be in one state at one time. The operations can include: receiving a work request from an agent in the queue state; determining if there is a thread to be provided to the agent in response to the work request; and moving the agent from the queue state to an on-deck state if there is no thread to provide to the agent. The operations can further include: receiving a first indication that the first agent associated with the triage state has provided a task to be performed to respond to the user request, the task forming part of the thread; awarding the first agent associated with the triage state a first type of credit in response to the first indication; receiving a second indication that the second agent associated with the queue state has worked on a task forming part of a thread; and awarding the second agent associated with the queue state a second type of credit, different from the first type of credit, in response to the second indication that the second agent has worked on the task forming part of the thread.

Another aspect described in this specification provides a system including: a state management engine configured to associate a first agent with a triage state and a second agent with a queue state and to associate an agent with only one of the triage state and the queue state at one time; a triage engine configured to receive a user request, to provide a thread associated with the user request to a first agent, and to receive from the first agent at least one task to be performed in order to respond to the user request, the task forming part of the thread; a queue engine configured to receive the thread from the triage engine, to provide the thread to the second agent, and to receive from the second agent an indication that the second agent has worked on a task forming part of the thread; and a thread management engine configured to provide a second thread to an agent only if the agent has provided an indication that the agent has stopped working on a first thread.

Yet another aspect described in this specification provides a computer-implemented method including: receiving a user request; determining that a first agent is in a triage state and that a second agent is in a queue state; providing a thread associated with the user request to the first agent; receiving from the first agent at least one task to be performed to respond to the user request, the task forming part of the thread; providing the thread to the second agent; and removing a thread from an agent if the agent does not act on the thread according to a specified criteria, wherein an agent can only be in one of the triage state or the queue state at one time and an agent cannot work on a second thread until after the agent's work on a first thread has stopped.

Removing a thread from an agent if the agent does not act on the thread according to a specified criteria can include removing a thread from an agent if the agent does not act on the thread within a specified period of time. In one embodiment, the work on a thread has stopped when the agent working on the thread has indicated completion of the work and/or when the agent working on the thread has requested a pause of work on the thread.

A method can include moving an agent from a first state to a second offline state in response to inactivity by the agent for a specified period of time. The method can include associating each of a plurality of agents with one of a plurality of states and allowing an agent to be in only one state at one time. The plurality of states can include a triage state, a queue state, an on-deck state, a project state, a lobby state, and a meeting state.

A method can include receiving a work request from an agent; determining if there is a thread to be provided to the agent in response to the work request; and moving the agent from the queue state to an on-deck state if there is no thread to provide to the agent. A method can include: receiving a first indication that the first agent associated with the triage state provided a task to be performed to respond to the user request, the task forming part of the thread; awarding the first agent associated with the triage state a first type of credit in response to the first indication; receiving a second indication that the second agent associated with the queue state has worked on a task forming part of a thread; and awarding the second agent associated with the queue state a second type of credit, different from the first type of credit, in response to the second indication that the second agent has worked on the task forming part of the thread.

A method can include: determining an agent productivity goal; and determining, for an agent, a percentage of the agent productivity goal reached by the agent. Determining the agent productivity goal can include determining a number of credits awarded to an agent, the duration of time in which the agent is associated with a state, the number of tasks worked on by the agent, and the number of threads provided to the agent.

In one embodiment, a primary agent cannot work on a thread that has been provided to a secondary agent while the secondary agent is working on the thread unless the primary agent is a higher priority agent than the secondary agent. In one embodiment, the primary and secondary agents are the same as the first and second agents, respectively.

Another aspect provide a computer-implemented method including: receiving a user request; associating a first agent with a triage state and a second agent with a queue state; providing a thread associated with the user request to the first agent; receiving from the first agent at least one task to be performed to respond to the user request, the task forming part of the thread; providing the thread to the second agent, and removing a thread from an agent if the agent does not act on a thread according to a specified criteria, wherein an agent can work on a second thread only after the agent no longer has the ability to work on the first thread in real-time.

The subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages. The subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages. An agent of the virtual personal assistant system is able to work on one user request at a time. In addition, once the agent receives the user request from the system, other agents are not permitted to work on the user request while the agent is working on the user request. These features improve the virtual personal assistant system by ensuring there is no duplication of work and that work can be tracked accurately. Tracking work accurately allows for better performance management. These features also improve the efficiency of the virtual personal assistant system, with regard to how quickly and accurately it is able to complete user requests, by ensuring every agent focuses all of his or her attention on completing a single user request at a time. Other advantages include 1) building a data-set which allows prediction regarding the time to complete similar tasks, and 2) early warning when a task is not being completed correctly by associating each action taken to a specific work request.

DETAILED DESCRIPTION

FIG. 1is a diagram of the components of an exemplary agent management system100. With reference toFIG. 1, one of the roles of an agent is to respond to a user request, such as user request132, when the request is sent to agent management system100. User request132can take many forms such as a request for a restaurant reservation, a purchase of an item, a gift or tickets, or the arrangement and calendaring of a meeting.

FIG. 1includes a triage engine102, a queue engine104, a state management engine106, a thread management engine108, and a credit engine110. User request132can be processed by triage engine102into a format called a thread. Before being triaged, a thread can be formatted to include information such as the content of the user request and the time at which the user sent the request. The thread is then “triaged” to determine what tasks need to be performed to respond to the user's request. An agent of the system can triage threads. For example, the triaging agent can identify one or more tasks to be added to a thread. A triaging agent can add tasks to at most one thread at a time. In one embodiment the triage engine102can assign some threads to a human agent for triage and can automatically triage other threads.

After being triaged, a thread can include one or more tasks, i.e., actions that an agent can perform to respond to the user request and, in certain embodiments, a priority associated with the user request. A triaged thread, such as triaged thread144, can then be sent from triage engine102to thread management engine108, which is configured to store threads.

AlthoughFIG. 1shows two agents, agent management system100can manage a large number of agents. Each agent interacting with agent management system100is associated with a state. Agent management system100includes a plurality of states, such as a triage state120and a queue state122, both shown inFIG. 1. Agent management system100can also include more states such as an offline state202, a lobby state204, a meeting state206, a project state208, a break state210, a lunch state212, and an on deck state214, which are described in more detail below. In embodiments described in this specification, each agent managed by agent management system100is in only one state at any one time.

Each state is associated with one or more rules that govern the work that can be done by an agent in that state. Certain states permit an agent to work on threads, while other states do not permit an agent to work on threads. For example, triage state120, queue state122, meeting state206, project state208, and on deck state214all permit an agent to work on threads. However, offline state202, lobby state204, break state210, and lunch state212do not permit an agent to work on threads.

The one or more rules associated with each state also govern the movements of the one or more agents into and out of the state. Agent management system100includes state management engine106, which is configured to monitor which state each agent is in and ensure that each agent is associated with exactly one state. An agent can choose to move manually from one state to another in accordance with the rules of the relevant states. For example, with reference toFIGS. 1 and 2, while in lobby state204, agent124can send a movement request134ato state management engine106that represents a request to move to triage state120. In response to movement request134a,state management engine106can record agent124as no longer being in lobby state204, and instead being in triage state120. As another example, agent126can request to be moved to queue state122by sending a movement request134bto state management engine106. In response to movement request134b,state management engine106can record agent126as being in queue state122.

In some cases, state management engine106rejects a movement request and does not record an agent as being in the state specified by the movement request. For example, an agent can only enter a so-called on deck state214from queue state122, after requesting work from the agent management system100when there is no work available to provide in response to the request. In other words, an agent cannot enter on deck state214by sending a movement request. Therefore, a movement request to enter this state will be denied by state management engine106.

An agent can also be moved from one state to another by state management engine106not as a result of a request from the agent in question. For example, if an agent is in queue state122for more than a threshold amount of time without engaging with a thread, then state management engine106can move the agent from queue state122to offline state202.

In certain embodiments, not only can an agent manually move from one state to another by sending a movement request, the agent can also move from one state to another by sending a work request to thread management engine108. For example, although not shown in the figures, an agent in lobby state204can send a work request to thread management engine108. If the thread management system has either a thread or a triaged thread, it can provide either one to the agent. For example, if thread management engine108has a thread (i.e., that has not been triaged) it can provide the thread to the agent in response to the work request. Thread management engine108can also indicate to state management engine106that the thread has been provided to the agent. In response to the indication, state management engine106can move the agent to triage state120.

As previously mentioned, triage engine102is configured to receive a user request132. However, in certain embodiments, a user request can be processed by the asset management system prior to being provided to the triage engine. Triage engine102is configured to process user request132into thread140. After processing user request132into thread140, triage engine102can send thread140to thread management engine108.

Agent124in triage state120can send work request136ato thread management engine108. In response to receiving work request136afrom agent124, thread management engine108can provide agent124with exclusive access to thread140. Thread management engine108can also send thread140to triage engine102, in anticipation of thread140being triaged. After receiving thread140, agent124can identify one or more tasks, such as task142, to be performed to complete the user request. Agent124can send task142to triage engine102. The triage engine adds task142to thread140. As a result of triaging, thread140becomes triaged thread144, which includes task142. Triage engine102can then send triaged thread144to thread management engine108. Once thread140is triaged to become thread144, agent124no longer has access to thread140. Triaged thread144can then be provided to the same or different agent of agent management system100to be worked on further.

When thread140or triaged thread144is provided to an agent, it is “locked” meaning that the agent is granted exclusive access to the thread and the agent is said to have a lock on that thread. For example, when thread management engine108provides agent124with thread140, agent124has the lock for thread140. When agent124has this lock, only agent124can access thread140. In other words, only agent124can provide triage engine102with task142.

As another example, if agent126is provided with triaged thread144, then that agent is granted exclusive access to triaged thread144during the time the agent has a lock on the thread. This means that only agent126can work on task142that forms part of triaged thread144while that agent has the lock on the thread.

As previously mentioned, in certain embodiments an agent can only actively work on one thread at a time. In other words, a thread can be referred to as locked when an agent has been assigned the thread. This means that an agent can be actively working on at most one locked thread at any time. Locks can also be associated with a type. In certain embodiments, types of locks include triage, conversation, and review; a thread with a triage lock can only be worked on by an agent in triage state120or queue state122; and a thread with a conversation lock or review lock can only be worked on by an agent in triage state120, queue state122, meeting state206, and project state208.

Agent management system100can remove or “unlock” a locked thread (also referred to simply as a lock) from an agent if the agent is inactive for more than a threshold period of time. The threshold period can vary depending on the type of lock. In one embodiment, a triage lock is removed from an agent after five minutes of inactivity, while a conversation lock and a review lock can be removed from an agent after 15 minutes of inactivity. In other embodiments the threshold period can range from 1 minute to 30 minutes.

In one embodiment, thread management engine108can remove a lock from an agent. For example, thread management engine108can remove a lock from an agent if the agent is inactive for more than a threshold period. To determine how long the agent has been inactive, thread management engine108records the time elapsed since an agent has worked on a locked thread. Working on a locked thread can include inputting data into the system that reflects progress in responding to the user request.

In another example, thread management engine108can provide a conversation lock to agent126in queue state122. After receiving the conversation lock, if the agent126is inactive for more than the threshold period, thread management engine108will unlock the conversation lock and in response to a work request from an alternative agent, thread management engine108can provide the unlocked thread to the alternative agent in queue state122.

In one embodiment, an agent that has a conversation or review lock can pause the lock. In certain embodiments, while an agent can have at most one active lock at a time, an agent can have more than one paused lock. An agent might pause a first locked thread or lock to allow the agent to work on a higher priority thread that the agent became aware of after starting work on the first locked thread. In one embodiment, while conversation and review locks can be paused, triage locks cannot. An agent with a conversation or review lock can send a pause request to thread management engine108. When thread management engine108receives a pause request, the engine can mark the corresponding lock as paused.

An agent with a paused thread can also un-pause the thread, to continue working on it. For example, an agent can pause a conversation thread and begin working on a high-priority triage thread. When the agent has finished working on the high-priority triage thread, the agent can then unlock the high-priority triage thread, so that the agent no longer has access to the high-priority triage thread. After unlocking the high-priority triage thread, the agent can unpause the prior conversation thread, and continue working on it. In one embodiment, if an agent unpauses the conversation thread before unlocking the triage thread, the system will automatically unlock the triage thread.

In one embodiment, receiving a triage thread can automatically pause a conversation or review thread. For example, an agent with a conversation or review thread can request a triage thread. When the agent receives the triage thread, the conversation or review thread that the agent has is automatically paused. Such a scenario might occur if an agent becomes aware of a high-priority triage thread after starting work on a conversation or review thread.

Just as work done by an agent in triage state120is sent to triage engine102, work done by an agent in queue state122is sent to queue engine104. Queue engine104is configured to receive one or more threads from triage engine102and to store the received threads.

As previously mentioned, after triaging thread140to form triaged thread144, triage engine102can send triaged thread144to thread management engine108. Agent126in queue state122can communicate a work request136bto thread management engine108. In response to work request136b,thread management engine108can provide agent126with triaged thread144and as a result, the engine locks the thread. The agent can then work on task142that forms part of triaged thread144. After performing task142, agent126can send an indication146to queue engine104.

If, for example, user request132corresponds to a dinner reservation request, then indication146can include a confirmation of a restaurant reservation, e.g., a confirmation number, time, date, and location of the restaurant. Indication146can also include a contact number and website for the restaurant. As another example, if user request132corresponds to a shopping request, then indication146can include a date, time, and description of a purchase along with a tracking number and vendor contact information.

Indication146can also include metadata related to the task. As an example, the metadata can include how long it took agent126to perform the task, the time that agent126performed the task, and the resources that agent126used to perform the task. When agent126transfers indication146to queue engine104, the queue engine can indicate this to credit engine110, via work report144. In response, credit engine110awards a credit to agent126.

Credit engine110can award a credit to an agent in response to an action performed by an agent. A credit can also be awarded based on other metrics such as, an amount of time an agent worked on a particular thread, an amount of time an agent spent in a certain state, the number of work requests an agent sent while in a certain state, the number of tasks worked on by an agent, and the number and type of each thread that an agent locked while in a certain state. These metrics, and the number of credits awarded to one or more agents, can be used to determine a productivity goal for certain agents. Agent management system100can use the number of credits an agent has to determine the agent's progress towards his or her productivity goal.

In certain embodiments, not only can thread management engine110remove a locked thread from an agent, agents can also remove locked threads from each other. For example, a managing agent may become aware of new information that modifies a request from a high-priority user. Such a managing agent can override a lock on a thread being worked on by agent126. In such a situation, the managing agent, being a higher priority agent, can remove the thread from agent126.

An exemplary agent management system can include more states than those discussed with regard toFIG. 1. In certain embodiments, an agent can enter and exit multiple states over a period of time but the agent exists in only in one state, e.g., a triage state or a queue state, at a particular time.FIG. 2is a diagram of the states of an agent management system, such as agent management system100.FIG. 2includes agent124, triage state120, queue state122, offline state202, lobby state204, meeting state206, project state208, break state210, lunch state212, and on deck state214.FIG. 2also shows an number of arrows, pointing from one state to another. An arrow indicates that an agent is able to move from one state, i.e., the state at the tail of the arrow, to another state, i.e., the state at the head of the arrow. The diagram includes two types of arrows to differentiate between two types of movements: automatic (as depicted by the thinner arrows) and manual (as depicted by the thicker arrows).

Agent management system100can move an agent between two states, for example, in response to determining that the agent has been inactive for longer than a threshold period of time. This specification refers to movements made by the agent management system100without a request by an agent or administrator as automatic. As illustrated by the arrows shown inFIG. 2, state management engine106can automatically move agent124to offline state202from triage state120, queue state122, meeting state206, project state208, break state210, lunch state212, lobby state204, or on deck state214. state management engine106can make these movements after determining that agent124has been inactive for more than a threshold period of time. In one embodiment, state management engine106can move an agent from triage state120to offline state202if the agent is in triage state120for more than a specified period of time (e.g., a period of between 10 minutes and 3 hours such as for example two hours) without requesting a thread on which to work. Also in this embodiment, state management engine106can move an agent from queue state122to offline state202if the agent is in queue state122for more than five minutes without requesting a thread on which to work. In other embodiments, the threshold period can be longer, e.g., 6-50 minutes.

Apart from being automatically moved by agent management system100, an agent can also choose to move manually from one state to another. As illustrated by the arrows shown inFIG. 2, agent124can manually move to offline state202from triage state120, queue state122, lobby state204, meeting state206, project state208, break state210, lunch state212, and on deck state214. To perform a manual movement, agent124can send a movement request to state management engine106, which can respond by associating agent124with the new state indicated by the movement request.

If an agent is the only agent in a state or one of few agents in a state, state management engine106can message the agent if the agent sends a movement request to leave the state. For example, agent124can be the only agent in triage state120. If agent124sends a movement request to state management engine106, then state management engine106can respond by alerting agent124that exiting triage state120would result in there being no or few agents in this state and in one embodiment, the state management engine106can prevent or delay the movement until the state management system106can locate a replacement or additional agents for that state. In one embodiment, the state management engine106may message potential agents that additional credits are available for agents who join the depleted state for a specified period of time or while the shortage lasts.

In one embodiment, before interacting with agent management system100, an agent, such as agent124, must log in to the system. Prior to logging in, agent124is in offline state202. An agent in offline state202cannot request or receive threads, work on tasks, transfer indications, or be awarded credit. Once agent124logs in, the agent is moved from offline state202to lobby state204. While in lobby state204, agent124can also be logged out by agent management system100. In this case, the agent is automatically moved from lobby state204to offline state202. In one embodiment, when an agent is in lobby state204, the agent cannot obtain a thread on which to work. As a result, the agent cannot work on any tasks.

An agent can enter meeting state206to indicate the agent is attending a meeting. While in meeting state206, the agent can send a work request to thread management engine110. The agent can also receive a thread from thread management engine110in response to the work request, work on a task associated with the thread, and return the result to the engine handling the thread, e.g., triage engine102or queue engine104. Triage engine102or queue engine104can indicate the completion of the task associated with the thread to credit engine110, e.g., through a work report. In turn, credit engine110can award the agent a credit for completing the work request. In this embodiment, because the agent completed the task while in meeting state206, the credit awarded to the agent is different from the credit awarded to another agent that completed a task while in triage state120or queue state122.

In this embodiment, state management engine106moves an agent from meeting state206to offline state202if the agent is inactive for more than a threshold period of four hours. In other embodiments, the threshold period can range from half an hour to four hours.

Just as an agent can move from lobby state204to meeting state206, the agent can also move from lobby state204to project state208. An agent can move to project state208to indicate that he or she is working on a project. Similar to being in meeting state206, the agent can also request work, work on a task that makes up the thread, transfer an indication, and be awarded credit for completing the task. The credit awarded to the agent while in project state208is different from the credit awarded to another agent that completed work while in the triage state120or the queue state122.

In one embodiment, state management engine106moves an agent from project state208to offline state202if the agent is inactive for more than a threshold period of four hours. In other embodiments, the threshold period can range from half an hour to four hours.

Agent124can also move from lobby state204to break state210. agent124can move to break state210to indicate that the agent is taking a break. An agent in break state210cannot request or receive threads, work on tasks, transfer indications, or be awarded credit.

In this embodiment, state management engine106moves an agent from break state210to offline state202if the agent is inactive for more than a threshold period of 25 minutes. In other embodiments, the threshold period can range from 10 minutes to 60 minutes.

Agent124can also move from lobby state204to lunch state212. agent124can move to lunch state212to indicate that he or she is eating lunch. An agent in lunch state212cannot request or receive threads, work on tasks, transfer indications, or be awarded credit.

In this embodiment, state management engine106moves an agent from lunch state212to offline state202if the agent is inactive for more than a threshold period of 80 minutes. In other embodiments, the threshold period can range from 30 minutes to 90 minutes.

In one embodiment, agent management system100can automatically move an agent from queue state122to on deck state214if the agent requests work when there is no work available. For example, when agent124is in queue state122, the agent can send a work request to thread management engine110. If thread management engine110does not have a thread to provide the agent, then thread management engine110can communicate this to state management engine106via a no thread alert148. The information communicated to state management engine106via a no thread alert148can include the time agent124sent the work request and an identifier for the agent, i.e., to identify the agent as the agent that sent the work request. In response to the no thread alert148, state management engine106can move the agent from the queue state122to on deck state214.

While an agent is in on deck state214, thread management engine110continuously checks to determine if a new thread has been received. If a new thread is received, then thread management engine110assigns the agent the new thread. Thread management engine110also sends a thread alert150to state management engine106to communicate that the agent has been assigned the new thread. In response to thread alert150, state management engine106can move the agent from on deck state214to queue state122.

In this embodiment, state management engine106moves an agent from on deck state214to offline state202if the agent is without a thread for more than a threshold period of one hour. In other embodiments, the threshold period can range from 30 minutes to 2 hours.

FIG. 3is a flowchart for an exemplary method of managing work by an agent management system. When appropriately configured, the agent management system100can perform the example method.

The agent management system receives a user request (305). A user request corresponds to an action that a user wants to be performed by one or more agents of the agent management system. The user request is sent from a user to a thread management engine of the agent management system.

The agent management system associates a first agent with a triage state and a second agent with a queue state (310). The agent management system can include a state management engine that associates an agent with one of a plurality of states of the agent management system. The state management engine associates an agent with only one state at a time. The state management engine also keeps track of the state with which each agent is associated.

The agent management system can provide a first thread associated with the user request to the first agent (315). The thread management engine can provide a thread to the first agent. The thread includes information corresponding to the actions that the user wants performed by the one or more agents of the agent management system.

The agent management system receives from the first agent at least one task to be performed to respond to the user request, the task forming part of the first thread (320). The first agent identifies one or more tasks that can be performed by the one or more agents of the agent management system in order for these agents to complete the user request. The first agent sends the one or more tasks to the triage engine. The engine then triages the first thread such that the first thread includes the one or more tasks necessary to complete the user request associated with the thread.

The agent management system provides the first thread to the second agent (325). The thread management engine can provide the first thread, which has been triaged, to the second agent, in response to the second agent requesting work from the thread management engine. The thread management engine can also record the time in which it provides the triaged first thread to the second agent. Once the triaged first thread has been provided to the second agent, the thread management engine does not provide the triaged first thread to any other agent unless the second agent returns the triaged first thread or the triaged first thread is removed by another, higher priority agent or by the agent management system.

The agent management system removes the first thread from the second agent if the second agent does not act on the first thread according to a specified criteria, wherein an agent can only be in one of the triage state or the queue state at one time and an agent can work on a second thread only after stopping work on the first thread (330). The specified criteria can be a minimum allowable timespan for the second agent to have the triaged first thread, but not work on it. If the second agent does not work on the triaged first thread within the minimum allowable timespan, then the thread management engine can remove the triaged first thread from the second agent. Once the thread management engine removes the triaged first thread from the second agent, the thread can be provided to another agent in the queue state.

FIG. 4is a flowchart for an exemplary method of awarding credit to an agent of an agent management system. When appropriately configured, the agent management system100can perform the example method.

The agent management system receives an indication that a first agent associated with a first state has worked on a task forming part of a triaged thread (405). For example, the first state can be a queue state. Correspondingly, a thread management engine can give the triaged thread to the first agent. When the first agent completes the task forming part of the triaged thread, the first agent sends an indication to the queue engine. As an example, the triaged thread can correspond to a user request for buying kitchen supplies from an online vendor. A triaging agent can triage the thread by adding tasks such as “search vendors A, B, and C for kitchen supplies” and “buy the kitchen supplies from the vendor offering the lowest price”. After receiving the triaged thread, the first agent can send an indication to the queue engine indicating that vendor A offered the lowest price for the kitchen supplies. The indication can further include the price of the kitchen supplies from each of the three vendors.

The agent management system awards the first agent associated with the triage state a first type of credit in response to the indication that the first agent has worked on the task forming part of the triaged thread (410). In response to receiving the indication, the agent management system can mark the corresponding task as completed, update the triaged thread to include the indication, and award the first agent a first type of credit. The first type of credit is indicative of the state in which the first agent completed the task.

The agent management system receives an indication that the second agent associated with a second state has worked on a task forming part of the triaged thread (415). Continuing the previous example, if the first agent stops working on the triaged thread after sending the indication, then the agent management system can provide the triaged thread to another agent, such as a second agent in a second state. For example, the second state can be a queue state. While in the queue state, the second agent can send a work request to the agent management system. In response to the work request, the agent management system can give the second agent the triaged thread that was previously worked on by the first agent.

As previously discussed, a task forming part of the triaged thread could be “buy the kitchen supplies from the vendor offering the lowest price”. The second user can determine, from the indication included in the triaged thread, that the vendor offering the lowest price is vendor A. To work on the request, the second agent can buy the kitchen supplies from vendor A, and provide an indication to indicate the purchase to the agent management system. For example, the indication can include a confirmation number for the purchase.

The agent management system awards the second agent associated with the queue state a second type of credit in response to the indication that the second agent has worked on the task forming part of the triaged thread (420). Following the previous example, the agent management system can receive the indication corresponding to the purchase of kitchen supplies from vendor A. In response, the system can award the second agent a second type of credit. Because the first agent and second agent were in different states when they worked on the triaged thread, each is awarded a different type of credit. For example, the second agent can receive the second type of credit because he or she worked on the triaged thread while in the queue state, as opposed to queue state, where the first agent worked on the triaged thread.