Multi-channel communication platform with dynamic response goals

Abstract

To provide a method and a system for simplifying a conversation and providing omni-channel communication of a variety of relations and support on a large scale.SOLUTION: A multi-channel communication system 10 includes a messaging engine 22, a routing engine 28, and a queue manager 30. The messaging engine receives a plurality of textual messages from a user through any of a plurality of different messaging services 24 in communication with the messaging engine. The plurality of textual messages form a message thread and include at least one query requesting a reply. The routing engine determines a momentum of the plurality of textual messages and assigns the message thread to a message queue associated with an agent. The queue manager specifies a response time goal for providing the reply to the at least one query, where the response time goal is inversely proportional to the determined momentum.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] (Reference to Related Application) This application claims the benefit of priority from U.S. Provisional Patent Application No. 62 / 855,917, filed May 31, 2019, which is incorporated by reference in its entirety.

[0002] (Technical field) The present disclosure relates to a multi-channel communication platform for managing communications and workflow. [Background technology]

[0003] With the rise of mobile internet technology, the way individuals and businesses communicate is rapidly changing. Unlike voice communication, where individuals can generally maintain only one conversation at any given time, new forms of communication (e.g., SMS, MMS, IP-based client messaging) allow users to converse with multiple different parties simultaneously. In addition to being able to handle more simultaneous conversations, these new communication methods each have acceptable response times that can vary based on the user's urgency. For example, an active user with an urgent inquiry may require an immediate, near-real-time response. Conversely, a user with a quick question sent via SMS may put their device down after asking the question and not check it again for several hours. One study found that a standard web chat, which involved an average of 8 minutes of handle time over an 8-minute continuous block of time, had a similar average of 8 minutes of handle time, while an SMS chat, spread over 1.5 hours of sporadic contact, involved a similar average of 8 minutes of handle time.

[0004] The challenge of managing acceptable response time targets becomes particularly problematic if agents are required to converse across multiple messaging platforms, with each messaging platform having different expectations of what constitutes an acceptable delay in receiving a response. If longer response times are acceptable, staffing requirements may be reduced, which provides cost savings for businesses. Thus, the transition to new forms of communication provides an opportunity to balance customer service response workloads that are not available in live phone conversations. Summary of the Invention

[0005] The present disclosure provides, among other things, a Robotic Optimized Clienteling Communications platform (ROOCo) that can provide a dynamic customer service experience between consumers and businesses. The robotic nature can leverage machine learning and natural language understanding to enhance live agent capabilities / responsiveness while providing a superior level of service to consumers. The system may allow clienteling at scale to create durable, long-term relationships while also enabling cross-platform communications that can pivot to real-time consumer demands. In broad terms, the goal of the system is to simplify conversations while providing relationship-rich omnichannel communications and assistance at scale.

[0006] In some embodiments of the present disclosure, a multi-channel communication platform includes a messaging engine, a routing engine, and a queue manager. The messaging engine may be operative to receive a plurality of text messages from a user through any of a plurality of different messaging services in communication with the messaging engine. The plurality of text messages form a message thread and include at least one query requiring a reply. The routing engine may be operative to determine a momentum for the plurality of text messages. Finally, the queue manager may assign the message thread to a message queue associated with an agent. The message queue identifies a response time target for providing a reply to the at least one query, the response time target being inversely proportional to the determined momentum.

[0007] A further extension of the present disclosure provides a system that assists a live agent in providing customer service to a user and / or answering a user's queries. Such a system may include an automated agent with natural language processing capabilities that provides the live agent with suggested response language to address the user's query. In some embodiments, the automated agent may fill a support window on the live agent's user interface with information about the user. Such information may include, but is not limited to, the user's product preferences, the user's size, a display of the user's recent browsing history, a summary of the user's product interests, a summary of the user's consumption patterns, a summary of previous message threads with the user, a summary of the user's tagged products, or a summary of the user's purchasing history.

[0008] Additionally, the automated agent may generate and display one or more hyperlinks on the support window to Internet web pages where the products are offered for sale. Such links may be derived from the context of the message thread between the user and the live agent. In one embodiment, the Internet web pages may belong to the retailer but may allow inventory from third parties to be purchased through the retailer's web page. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a schematic diagram of a multi-channel communication system that may be used to provide customer service and / or support to users.

[0010] [Figure 2] 2 is a schematic flow diagram for managing one or more conversation threads in a multi-channel communication system such as that shown in FIG. 1.

[0011] [Figure 3] 10 is a schematic graph of response time targets set as a function of speech momentum distribution;

[0012] [Figure 4] FIG. 1 is a schematic flow diagram for initially responding to a user via an automated agent.

[0013] [Figure 5] FIG. 1 is a schematic flow diagram for determining conversation momentum.

[0014] [Figure 6] 1 is a schematic table illustrating a queue of message threads that may be managed by a customer service agent.

[0015] [Figure 7]1 is a schematic display screen that may be presented to a customer service agent for purposes of managing multiple messaging threads and providing a quick response to a user.

[0016] [Figure 8] FIG. 1 is a schematic flow diagram illustrating a process for integrating multiple customer support agents into a single conversation with a user.

[0017] [Figure 9] FIG. 1 is a schematic flow diagram illustrating a system for generating e-commerce links for product sales from a retailer or one of multiple third-party retailers.

[0018] [Figure 10] 1 is a schematic flow diagram illustrating a system for creating an elastic pool of live customer service agents to accept inquiries from a user population. DETAILED DESCRIPTION OF THE INVENTION

[0019] The following discussion and accompanying drawings disclose a multi-channel communication system (e.g., system 10 of FIG. 1) that may be used to provide customer service and / or support to users. In many embodiments, the users may be end users and / or existing or prospective customers. However, in other embodiments, the users may be retail sales personnel, and the system may respond to questions regarding specific product information, style advice, and / or custom product ordering.

[0020] As a matter of general terminology, when this disclosure refers to a "user," it is intended to refer to a person seeking support. In a retail context, a user is typically an existing or potential customer. Furthermore, information providers and / or people who respond to inquiries are referred to as "agents" or "specialists."

[0021] In some embodiments, the system may be configured to determine appropriate response time goals for agents based on the user's speaking speed and / or the perceived urgency of the user's message. In doing so, the system differs from traditional systems in which response time goals are based solely on messaging modality (e.g., an agent may maintain five simultaneous SMS threads).

[0022] The system may further operate to improve the quality and / or speed of service agent responses by analyzing user queries and routing threads or queries to agents or specialists who are most knowledgeable on that particular subject matter. When multiple queries on different subject matters are made in close proximity to one another, each query may be routed separately to a different agent. To provide a better flow to the conversation with the user, one agent may be considered the primary responding agent, and all other secondary responding agents may feed their responses to that primary responding agent for synthesis into the conversation.

[0023] The system may also support the agent's ability to provide relevant product or support information by coordinating the messaging client with the user's account information. In this way, the agent's display may be populated with specific sales information (e.g., to provide shipping or return assistance), customer-specific preferences / sizes, purchasing trends, or other such relevant information. In some embodiments, this auxiliary information may be based on user account data, and in some embodiments, this auxiliary information may be further refined by the context of the received message.

[0024] 1, the multi-channel communication system 10 may include a messaging engine 22 in communication with one or more messaging services 24, a thread management system 26, a routing engine 28, and a queue manager 30. In some embodiments, the routing engine 28 may include an automated agent 32 and a momentum monitor 34.

[0025] The various messaging services 24 are typically managed by external providers, and each may operate on a different communication network, utilize one or more different transport protocols, and / or communicate with different endpoint devices. Examples of different messaging services 24 include short message service (SMS), multimedia messaging service (MMS), push notification services, Internet Protocol (IP) messaging services, dedicated third-party messaging services, email services, and / or any suitable communication service. Each of the messaging services 24 may include dedicated communication service instances, channels, and different routing options.

[0026] The messaging engine 22 may include messaging clients configured to communicate through each or any of the connected messaging services 24 or may be operatively connected to such messaging clouds. The messaging clients may serve as a front end for communication via the messaging engine 22 and may include, for example, a voice and / or text-based interface through which users can communicate. The messaging engine 22 may be used to send messages via the messaging clients, receive messages, and manage synchronous / asynchronous communication sessions. In one configuration, the messaging engine 22 may be configured to communicate using multiple different communication protocols that may be specified and / or utilized by different messaging services 24. For example, for SMS messages, communication may rely on SMPP connections to various service provider destinations, for MMS messages, communication may rely on SMTP connections to various service provider destinations (for MM4), or alternatively, they may rely on service resources accessed through HTTP / SOAP (for MM7). Often, the service provider responsible for a particular messaging service 24 may offer an API that enables two-way communication with other clients / users on that service.

[0027] 2 illustrates generally how messaging engine 22 takes messages received from messaging service 24, organizes them into message threads, and passes them to message routing engine 28, as shown in FIG. 1. As generally shown, after receiving (at 50) a message from messaging service 24, messaging engine 22 may be configured to extract (at 52) ​​both user identification information and message content from the message. User identification information may be, for example, a phone number, a username, a user number, a device ID number, or the like. In many cases, user identification information may be encoded as part of the message and / or may precede the message in a header block. Once extracted, this information may be passed to thread management system 26, where the message content may be associated with a user account maintained in user database 36.

[0028] The thread management system 26 may generally be responsible for maintaining one or more ongoing message threads for each user, regardless of when the message is received. Continuing to refer to FIG. 2, if the user identification information from the message is recognized (at 54) from a user database, the thread management system 26 may check that user's account to determine whether an existing communication thread is open. If there is an existing open thread, the message content may be added (at 58) to the open thread. If no open thread exists, the thread management system 26 may create (at 60) a new thread and pass (at 62) the thread to the routing engine 28.

[0029] If the user identity is not recognized (at 54), a new temporary account may be created (at 64), or the user may be prompted by a return message (via the same messaging service 24) to provide identity information that may allow the user account to be accessed. In some instances, for example, once order-specific details are provided to an agent, an orphan thread or the temporary account created may be migrated to the user's account after the conversation. As an example, if the user's message indicates that the user wishes to return an item, user identity information may flow from the message content, such as an order number, which may ultimately be linked to the user account.

[0030] Referring again to FIG. 1 , routing engine 28 may generally be responsible for routing new message threads and new messages (including any secondary information related to the message thread) to appropriate live agents that may best support the user's query. As mentioned above, in some embodiments, routing engine 28 may include an automated agent 32 or artificial intelligence capable of understanding the nature and context of a message, and a momentum monitor 34 that operates to determine the momentum of a message thread. Knowing the nature and context of a message may enable routing engine 28 to identify an appropriate agent (or pool of qualified agents) to handle a query based on the subject matter, technical expertise, or sensitivity of the request. Furthermore, by knowing the momentum of a message thread, the system may become more adept at balancing message loads among individual agents according to the sensitivity and / or message frequency of a particular thread.

[0031] The automated agent 32 may include a natural language response engine capable of understanding the nature and content of the request. In some embodiments, the automated agent 32 may further include an artificial intelligence component that operates to conduct preliminary discussions with the user after receiving an initial message. For example, the automated agent 32 may handle simple requests such as obtaining specific contact information, obtaining a retail address, determining order status, and the like. Additionally, the automated agent 32 may function to obtain essential information that may be needed by a live agent. For example, if a return is requested, the automated agent 32 may inquire about the specific product, order number, and / or the underlying reason for the return.

[0032] In general, including an automated agent 32 in initial message receipt can provide several benefits. First, it can process simple requests at a lower cost than if a live agent were required. Second, it can gather information that may be needed by an agent to answer a particular query. In this way, a live agent need not spend response time / effort conducting preliminary fact-finding. Third, the automated agent 32 can engage with the user in a prompt manner to provide a sense of initial responsiveness to the user, even if a live agent is not currently available or has a large queue of queries to answer. This responsiveness can help prevent user frustration from building or escalating. Finally, interactions with the automated agent 32 can generate a base message thread, from which a momentum monitor 34 can determine the momentum of the conversation and set appropriate response time targets for the live agent.

[0033] The concept of conversation momentum recognizes that when conversing on a text-based messaging platform, different users may send messages at different rates and with different levels of urgency. A user engaged in a synchronous conversation (i.e., real-time interaction) may have a high rate, which may require greater agent capacity (i.e., if an agent is engaged in a real-time interaction, they have less capacity to handle additional message threads with other users). Conversely, a user who sends messages in an asynchronous manner may have a slower rate (i.e., a user may put their phone down for several hours between text message responses, or may only check email periodically throughout the day). This slower rate may not require the same rapid response required in a synchronous conversation. Thus, a slower rate may allow an agent to handle relatively more message threads in any given period of time.

[0034] Similar to speed, the urgency and mass of a query must also be taken into consideration when determining response targets. Highly urgent requests, or requests that make users feel more frustrated or angry, may require a more rapid agent response to avoid unnecessarily escalating concerns. Conversely, casual requests (e.g., what new things are coming out this weekend?) may have a relatively lower mass that does not require the same level of immediate attention. In one embodiment, conversation mass may be determined by a natural language processing algorithm that may aim to understand the nature of the request along with the level of emotion conveyed by the thread.

[0035] In some embodiments, conversation mass may be further influenced by one or more attributes of the user's account. For example, a message from a retail store employee may be assigned a higher mass than a user with no prior experience with the company. Similarly, other factors such as sales history, social media exposure, public influence, company involvement, and / or customer demographics may also affect mass. For example, a celebrity with high social media exposure, high public influence, and corporate sponsorship from the company may have a higher mass than a customer with minimal sales history and no social media exposure. While mass should not affect the attention a user receives, mass can be used to adjust an agent's queue size or the number of other message threads the agent may be handling simultaneously with the request. In this example, a celebrity may consume an agent's entire queue, preventing the agent from handling other message threads. Similarly, a sporadic consumer may be assigned to an agent who is simultaneously managing multiple message threads.

[0036] In one embodiment, conversation mass may be scored by the automated agent 32 on a scale of 0 to 100. This scoring may be percentile-like, where 0 represents absolutely no urgency or emotion and 100 represents pure urgency and pure emotion (i.e., both numbers are theoretically unobtainable). Each message or collection of messages may then be scored according to their use of expressive or evocative words, phrases, or contexts that imply time-sensitive queries. Message rate may be scored, for example, as the frequency of received messages (i.e., the inverse of the instantaneous or average period between messages). Conversation momentum may therefore be equal to the relative scored mass multiplied by the average frequency.

[0037] Histograms of conversation momentum 65 have generally been found to take the form of a normal distribution / bell curve (i.e., conversation momentum represented on the horizontal x-axis and frequency represented on the y-axis), as shown in FIG. 3 . In some embodiments, the momentum distribution 65 may be used to set a response time target 66 (represented on the secondary y-axis). For example, a conversation with momentum in the lowest decile 68 (i.e., the lowest momentum constituting a relatively slower messaging rate and a relatively lower urgency) may have a response time target set at a first value 70, such as 15 minutes. Conversely, a conversation with momentum in the highest decile 72 (i.e., the highest momentum constituting a relatively higher messaging rate and a relatively higher urgency) may have a response time target set at a second value 74, such as 15 seconds. Finally, a conversation with momentum at the median 76 of the momentum distribution may have a response time target set at a third value 78, such as 30 seconds. In one configuration, as shown via the example target, the response time objective function across the distribution may be nonlinear because it is known that differences in user expectations at the high end of the distribution vary only slightly, whereas acceptable response times at the low end of the distribution are more influenced by the user's sporadic speech patterns, which result in significantly larger response times. Thus, the applicable response time objective may vary inversely, but nonlinearly, with the determined momentum. In another embodiment, not shown, the applicable response time objective may vary inversely and linearly with the determined momentum.

[0038] 1, in one configuration, momentum monitor 34 may analyze preliminary conversations between a user and automated agent 32 to assess the quality of queries along with the rate at which the user is speaking. Quantitative measures of these two factors may then be combined to form a momentum measure that is used to dynamically set agent response time goals, adjust agent queue sizes, and enable agents to prioritize which outstanding queries to respond to first.

[0039] 4 illustrates a schematic diagram of a method for initially responding to a user query, as might be performed by the automated agent 32. As illustrated, once a message thread (or some indication that a new thread has been opened) is passed to the routing engine 28, the automated agent 32 may (at 80) review the initial message using one or more natural language algorithms to determine the nature and urgency of the request. The automated agent 32 may then (at 82) respond to the user with a greeting, an acknowledgment of the user's request, and either an answer to the user's request or a follow-up question. After receiving a subsequent message from the user, the automated agent 32 may determine (at 84) whether the previous response satisfied the user's query. If so, the automated agent 32 may close (at 86) the thread. If not, the agent 32 may either follow up with the user (at 88) or pass the thread to the momentum monitor 34 (at 90).

[0040] FIG. 5 schematically illustrates one method of operation of the momentum monitor 34. As shown, the momentum monitor 34 may review threads and determine (at 92) a conversation rate based on the average time it takes users to respond (i.e., initiate or send a response). In one embodiment, the rate may reflect a grand average of all response times. In another embodiment, the rate may reflect a simple moving average or an exponential moving average (which may place more weight on recent user response times than on initial user response times). The momentum monitor 34 may then perform (at 94) a conversation quality assessment based on at least one of a natural language assessment of the message sentiment (e.g., strongly positive to strongly negative) and / or the nature of the request (e.g., normal to urgent), or user characteristics, demographics, company affiliation or involvement, sales history, public impact, social media presence, and / or the like.

[0041] From the calculated velocity and determined mass, the momentum monitor 34 may then calculate (at 96) a momentum score that reflects the combination of the two parameters. This momentum score, along with any available conversational context from the automated agents, may then be used by the routing engine 28 to dynamically assign message threads to available live agents. Once assigned, the threads may be passed (at 98) to the queue manager 30 for monitoring the timeliness of responses in each user's respective queue.

[0042] Referring again to FIG. 1 , the system typically includes multiple live agents (A1-An), each with their own respective message queue (Q1-Qn) that the live agent is responsible for answering / managing. Generally, a message queue may include one or more conversation threads to which the live agent is responding at any given time. FIG. 6 schematically illustrates an example message queue 38 including multiple open message threads 100, each with a determined thread momentum 102. Each live agent may have a predetermined maximum response capacity 104 that represents the agent's skill and throughput. The routing engine 28, in combination with the queue manager 30, must operate such that the sum of the thread momentum 102 in a live agent's queues 38 does not exceed the agent's maximum response capacity 104. The queues 38 may further represent the agent's available capacity 106, which is the agent's maximum capacity 106 minus the sum of the thread momentum 102 in the queues 38.

[0043] In one embodiment, the routing engine 28 may maintain one or more unassigned message threads that have not yet been assigned to a live agent but that have been assigned to a respective thread momentum 102. In such cases, the routing engine 28 may first filter the pool of all agents to identify a subset that has the technical and / or customer service expertise to handle queries as best understood by the automated agent 32. The routing engine 28 may then consult the queue manager 30 to determine which agents within this subset can accept new threads and have available capacity to handle unassigned threads without exceeding their available capacity 106. In one embodiment, once assigned by the routing engine 28, the queue manager 30 may then transfer the unassigned threads 108 to the agent's queue 38 and update the available capacity. In another configuration, a live agent may be able to see the entire pool of unassigned message threads for which the live agent has the relevant expertise to answer and may then be able to select or opt in to a conversation.

[0044] Once a message thread is loaded into an agent's queue 38, the queue manager 30 may operate to assign a response time goal 112 to the thread 100 based on the thread's determined momentum score / value. Generally, the response time goal is the target maximum time allocated by the agent to respond to outstanding user queries. The response time goal may vary inversely with the momentum value, such that high momentum threads have relatively shorter response time goals than lower momentum threads. In one embodiment, each thread 100 may further reflect the amount of time 114 remaining within a given response window. This time-remaining metric 114 may reflect the response time goal minus the elapsed time since the last message was received from a user in that thread 100. This time-remaining metric 114 may resemble a countdown timer that indicates to each agent 36 how much time is still available to respond.

[0045] In one embodiment, if the time remaining metric 114 reaches zero (i.e., the entire response time window has elapsed) and the agent has not yet begun entering a response, the queue manager 30 may be configured to intervene. Such intervention may include the queue manager 30 sending a message to the user to indicate that the agent is researching the question and needs additional time. In one configuration, this intervention may be represented as if the agent had personally sent the message. In one embodiment, this intervention message starts a secondary timer, shown as a negative number associated with “User D” in FIG. 6, which may then be monitored for performance evaluation purposes and / or to adjust the agent's maximum response capacity 104.

[0046] Referring again to FIG. 1 , once a response is provided by an agent to an outstanding query, it is fed back to the thread management system 26, where the agent response is appended to the end of a message thread associated with the user's account. From there, the message is passed to the message engine 26, where it is sent back to the user via one or more of the messaging services 24. In one embodiment, the system operates independently of how messages are received and / or sent, so that some or all of a message thread may be made available through different messaging services. For example, a user may begin a conversation with an agent through SMS messaging while traveling, then switch to an IP app when they arrive home. In such an example, the messaging engine 22 may make the entire message thread (or at least a predetermined number of the most recent messages) available via the IP app.

[0047] In some embodiments, the routing engine 28 may be persistent and may monitor each incoming message as it is added to a message thread. For example, in some embodiments, the momentum monitor 34 may continuously update the momentum of a conversation, using, for example, a simple moving average or an exponential moving average, or other weighting scheme that may assign greater weight to more recent momentum calculations than more distant ones. In this way, users wishing to engage in a synchronous conversation after a period of extended delay may have their message threads assigned more quickly with faster response time goals. In some embodiments, if the updated momentum for a particular thread 100 causes the sum of the thread momentum 102 in the agent's queue 38 to exceed the agent's maximum response capacity 104, the routing engine 28 may automatically or after confirmation by a live agent reassign the particular thread (e.g., a thread with updated user interest or a thread with relatively lower mass or momentum) to a different live agent. In another embodiment, if the sum of thread momentum 102 only slightly exceeds the agent's maximum response capacity 104 (i.e., by less than a predetermined amount), routing engine 28 may simply prevent additional threads from being added to the queue, or may take such into account when evaluating the agent's performance / responsiveness. Furthermore, in some embodiments, a buffer capacity may be maintained between the sum of thread momentum 102 and the agent's maximum response capacity 104, so that fluctuations in momentum may be accommodated without exceeding the agent's maximum capacity.

[0048] In addition to continuous thread momentum updates, in some embodiments, the routing engine 28 / automated agent 32 may continuously evaluate user messages after they are received using natural language processing algorithms to assist the live agent in providing support. More specifically, the automated agent 32 may analyze each received user message individually and / or in the context of the broader thread for the purpose of generating auxiliary information that may be useful to the live agent and that may be forwarded to the live agent along with the newly received message. Such auxiliary information may include, for example, potential answers to the user's query, template response language, related product information, related order information, and the like. In the case of suggested response language, the live agent may have final discretion to include the suggested language in their response, modify / supplement the suggested language in their response, or ignore the suggested language entirely. The live agent's final response may then be used to train the automated agent's machine learning model so that the automated agent may provide improved and / or more relevant suggestions in the future.

[0049] 7 schematically illustrates an example of a screen / interface 140 that may be presented to a live agent. As generally shown, the interface 140 includes a representation of the agent's queue 38 (similar to that shown in FIG. 6), an active chat thread 142 for interacting with the user, and a support window 144 in which any supplemental information received (from the automated agent 32) may be displayed. The agent's queue 38 may include multiple active threads 100, including a first plurality of active threads 146 awaiting an agent's response and a second plurality of responded active threads 148 awaiting user follow-up. Each thread 100 may include an associated name 150 (e.g., username or user's name), a message status identifier 152, and a time remaining metric 114. Clicking or otherwise selecting one of the threads 100 populates the chat thread 142 with historical and ongoing message threads between the agent / company and the user. Further selection of one of the threads 100 may bring up in a support window 144 recently provided supporting information relating to the user and / or the user's query.

[0050] As generally shown in FIG. 7, chat thread 142 may include a mixture of messages / queries to agent / company 160, messages 162 from automated agent 32 to a live agent (e.g., to facilitate handoff), automatically generated responses 164 to the user from or on behalf of the live agent, and messages from the live agent to the user.

[0051] During a chat, the support window 144 may serve as the agent's primary source of information about the user and the user's query. By consolidating this information into a single window / area of ​​the display, the system may enable the agent to respond to the user more quickly. In some embodiments, the support window 144 may include a user attributes section 170 and a suggested responses section 172. The user attributes section 170 may provide the agent with gained insight into the user's interests, preferences, purchasing history, and the like, while the suggested responses section 172 may include potential response language provided by the automated agent 32 (via natural language processing algorithms) in an effort to guide or streamline the live agent's response.

[0052] In some embodiments, the user attribute section may include, for example, user profile information 180, user history information 182, and user account information 184. Profile information 180 may include, for example, a brief summary of the user 190, the user's product preferences 192 (e.g., typical products, styles, and / or colors the user may purchase), the user's recent browsing history 194, the user's interests, the user's engagement with mobile applications or web pages, the user's consumption patterns, and / or the user's contact information. History information 182 (i.e., the history information that may be filled once a tab header is selected) may include, for example, summaries of previous conversations with other agents, the user's social media engagement, tagged products, shared products, product suggestions from previous agents, and the like. Finally, account information 184 may include summaries of the user's previous orders, ordered products, preferred products, product offers sent to the user, discount offers sent to the user, and the like.

[0053] The system may be further configured to utilize multiple specialized live agents within the course of a chat to provide the user with the best quality answer. For example, if a user makes an unrelated request during the course of a conversation / query, previous systems may require the agent to complete the current conversation and then transfer the conversation to a second agent who may assist with the unrelated request. In the present system, the secondary agent may become an assistant to the primary agent who is maintaining an active conversation with the user. In this way, the entire conversation is seamless from the user's perspective while including multiple experts on the agent side.

[0054] 8 provides a flow diagram of a process 200 for integrating input from multiple agents into a support conversation while providing a seamless experience to the user. As generally shown, the process begins at 202 when routing engine 28 detects one or more questions in a question thread. This may occur using one or more natural language processing algorithms that continuously monitor the incoming message flow. In one embodiment, the one or more questions may be contained within a single user message. In another embodiment, the one or more questions may be split across multiple messages from the user that may immediately follow or have intervening agent responses.

[0055] Once the various questions are identified at 202, each question may be coded (at 204) as an object in software and assigned to a general topic or category. The system may then check (at 206) whether the user has an existing thread open. If not, routing engine 28 may begin by identifying a primary question / query at 208. A primary question may be one determined to have the greatest volume or urgency, the greatest potential for growth, and / or that can be answered by the widest number of agents (according to predetermined agent scoring indicating the agents' level of specialization and their sophistication). In a general sense, knowledgeable, expert agents (e.g., Olympic athletes) are a more expensive resource than less knowledgeable agents. Continuing with FIG. 8 , once the primary question has been determined (at 208), an agent with appropriate experience and available capacity for the question may be assigned (at 210) as the primary agent.

[0056] If or when an agent is assigned to a thread, process 200 may include passing (at 210) the received and analyzed message to that agent. The assigned primary agent may then be prompted (prompted) or alerted (at 214) that a different question / object exists in the message or thread. In one configuration, the primary agent may select one of the non-primary objects (i.e., a secondary question / object) and choose (at 216) to forward that secondary question to a secondary agent. The secondary agent may then answer the question, and the response may be sent (at 218) back to the primary agent for potential inclusion in the conversation. By prompting the primary agent first, this process allows the primary agent to answer questions they are comfortable with while referring them to more difficult questions or questions requiring more specialized knowledge.

[0057] In one configuration, when an object is created (at 204), the routing engine 28 may determine one or more topic categories to which the query falls. These categories may be pre-configured to match existing departments / specialties and / or developed organically to provide flexibility to the system. Nevertheless, when the primary agent is prompted (at 214) to hand off the secondary question, the prompt may include a list of available live agents appropriate for the determined categories. Alternatively, agent selection may still be based on the suitability of the determined topic category for the query, but may occur outside the primary agent's view. In yet other embodiments, the primary agent may flag the topic for assistance, which may route the query back to a wider pool of live agents from which other available agents may select the query or otherwise opt in to the secondary conversation. The response time goal for the secondary agent may be determined by the response time goal for the primary conversation. More specifically, the response time goal for the secondary agent may be less than the response time goal for the primary agent. In one configuration, it may be a fixed duration that is shorter than the primary response time goal.

[0058] Referring again to FIG. 7 , the support window 144 may further assist the agent by providing one or more deep links (i.e., links similar to those shown as the user's browsing history 194) to specific product pages where the user can purchase the referenced product. These links may be populated by the automated agent 32 and easily copied into the chat window by the live agent. FIG. 9 schematically illustrates one embodiment of a system / method 250 that may be used to generate relevant deep links to specific product pages where the user can purchase the suggested product. As shown, the automated agent 32 may begin by assembling a database 252 of available inventory. This database 252 may identify some or all of the product inventory maintained by the retailer's brick-and-mortar store(s) 256, the retailer's e-commerce business 258, one or more third-party brick-and-mortar store(s) 260 (e.g., stores located proximate to the user), and / or one or more third-party e-commerce businesses 262. As used herein, database 252 may be a persistent database that is updated periodically, or database 252 may be generated on-demand by automation agent 32 polling one or more of stores / businesses 256, 258, 260, 262 after identifying suggested products.

[0059] The link creation process generally begins after receiving a product request 264 from a user or live agent, or when the automated agent 32 recognizes the user's product history or is able to identify a particular product (266) from the context of a discussion between the user and the agent. Once this occurs, the automated agent 32 may consult the database 252 to determine whether the product is available from a retailer or participating third party. If the agent 32 determines that the product is in stock, it generates a link 270 to a website where the product may then be purchased. This link 270 is sent to the live agent and displayed in the support window 144, where the live agent may copy it into a chat interface 272.

[0060] When linking to a particular product or making a product available for purchase, the automation agent 32 may generally be configured to prioritize product inventory maintained by the retailer, all other factors being equal. However, in situations where a user's requested timeline cannot be met by the retailer, the timeline may dictate referencing third-party inventory. For example, if a user requests same-day pickup, the automation agent 32 may prioritize a brick-and-mortar store over an e-commerce site, even if that means linking to a third party rather than the retailer's own inventory. In this way, knowledge of the user's location and the location of the associated inventory is important in creating the most on-point product link. With this knowledge of third-party inventory, the live agent can be a single source of information regarding product availability, and using the automation agent 32 in this support role eliminates the need for either the user or the live agent to hunt down a third party to determine availability.

[0061] Regardless of where the product originates, in one configuration, link 270 may direct the user to a front-end user interface, such as an internet app or product website 280 maintained by the retailer, which serves as the sales interface for all purchases. More specifically, link 270 may direct the user to an app or product website where local pickup or shipping options are both available (if available inventory supports this). If the sale is completed through the front-end user interface for local pickup at a local third-party retailer, automation agent 32 (or other associated e-commerce system) coordinates the purchase with that retailer, instructing the third party to hold the product for pickup. In other embodiments, link 270 may direct the user to a third-party website for direct purchase through those sites.

[0062] Referring again to FIG. 7, the user interface for agents may dynamically change based on the consumer they are assisting. For example, the interface may provide relevant product searches (nearby inventory availability) where the consumer is located, switch language spell checkers based on the consumer's preferred language, ensure prices are only in the consumer's correct currency, etc. This can then enable agents around the world to assist any customer as long as they can speak / write the same language as the consumer they are assisting. For example, if a live agent in the United States is assisting a consumer in China, the support window 144 will switch to relevant response information for China, access inventory in Chinese stores, and all product prices are in the RBM.

[0063] FIG. 10 illustrates a system in which multiple live agents 302 (e.g., agents A1-A2 of FIG. 1) are deployed to respond to inquiries / communications 304 from a user population 306. n3 illustrates a system level architecture 300 that may utilize multiple live agents 302. In one configuration, multiple centralized live agents 308 (Agent 1 through Agent N ) and / or a plurality of distributed live agents 310 (agents D1 or agent DN ) Alternatively, the plurality of live agents 302 may include a plurality of dedicated live agents 308 (i.e., if customer service is their primary function, even if they work in a physically distributed manner) and / or a plurality of on-demand live agents 310. Generally, the centralized / dedicated live agents 308 may be a group of agents whose primary task is to provide customer service to the user population 306. In one configuration, all of these agents may be located in a common call center. Conversely, the distributed / on-demand live agents 310 may include individuals working in a more individualized or distributed capacity or individuals who have the ability to flex their hours to provide customer support from different responsibilities. In one embodiment, these distributed / on-demand live agents 310 may include retail associates from a brick-and-mortar store who have available hours during slow retail periods. Additionally, in some embodiments, these distributed / on-demand live agents 310 may include enthusiasts who are familiar with a particular industry but are not directly employed in a retail capacity (e.g., athletes supporting other athletes, employees of non-retail companies or consumer-facing roles, and the like).

[0064] One or more rewards 312 may be provided to encourage an elastic agent pool, particularly among distributed / on-demand live agents 310, to accommodate the needs of the user population 306, and to support the overall objectives of the business. In one configuration, the magnitude of the reward 312 may be scaled via a supply / demand pricing module 314 to adjust the reward according to one or more inquiry pricing metrics 316 and / or the size 318 of the agent population eligible to handle the inquiry. Such inquiry pricing metrics 316 may include the technical complexity of the request, the total number of outstanding / unassigned user inquiries, and / or the mass of the particular request. More complex inquiries, larger inquiries, as well as a larger volume of unassigned inquiries, may dictate a larger reward.

[0065] In one embodiment, live agents 302 may each be scored based on their relevant technical expertise and / or expertise in an agent capacity, and their relative scores or capabilities may make them better suited to handle particular inquiries. For example, in the athletics context, a college athlete may be considered to have greater technical expertise in their sport than a high school athlete, but relatively less expertise in a different sport. Similarly, a career customer service (CS) professional may have greater expertise in handling sensitive inquiries / customer concerns than an athlete with little formal CS experience. Furthermore, a career CS agent for a particular sport may have developed more technical expertise in that sport than an amateur athlete, even if the CS agent does not personally play that sport. In one embodiment, expertise may be conveyed as an experience point (XP) value or as a level where a certain amount of experience is required to advance to the next level.

[0066] 10 , each user query 304 may be evaluated by the automated agent 32 using its natural language processing to determine the query's emotional strength and required technical expertise. This evaluation may then adjust the agent filter 320 to limit the pool of available agents to only those with relevant technical and customer service expertise (e.g., scores). In this way, a marathon runner with an urgent pre-race query may have their query filtered so that only agents with a certain level of running experience and a demonstrated level of responsiveness / problem-solving ability may see their query.

[0067] Following this filtering, if the volume of new conversations does not exceed the agent's available predetermined capacity, an available agent may opt in to the conversation / inquiry and establish a chat session 322 with the user. Each chat session 322 may be continuously evaluated by a reward adjustment module 324 according to various dispute resolution and business promotion metrics. In this example, positive dispute resolution results and advancement of business promotion goals may trigger a positive reward adjustment, whereas increased disputes and anti-business statements may trigger a negative reward adjustment. Examples of positive business practices that should be rewarded include, for example, signing a user up for a new customer account, prompting a user to log in to an existing account, establishing a relationship with the consumer so that an inquiry or contact occurs following resolution of the initial inquiry, getting a user to click on a link to a product page, and making a sale. Examples of negative business practices that should be penalized include, for example, making comments that disparage the company, product, or consumer. Similarly, dispute resolution outcomes may be based, for example, on a customer satisfaction survey following the session.

[0068] Once the query is resolved and the reward value is determined, the reward is credited to an account belonging to the agent. In one embodiment, the reward may have direct monetary value and may be exchanged for cash, merchandise, and / or discounts via the rewards store 326. In another embodiment, the reward may be a token or credit that does not have direct monetary value, but may be exchanged for one or more digital items or a gacha-style game to receive a loot box / prize box via the store 326. The loot box may contain one or more digital items of different rarity that may be used, for example, to decorate the user's account and / or to be displayed with an avatar belonging to the user. In one embodiment, the gacha-style game may allow the agent to receive one or more digital collectibles, which may be uniquely stored / identified / verified on a blockchain ledger (i.e., where the digital collectibles directly correspond to tokens stored on a distributed blockchain ledger) to ensure their rarity. In a further enhancement, this digital collection may be usable in one or more video game applications to improve a user's character or gameplay attributes, as described in U.S. Patent Application No. 16 / 707,741, filed December 9, 2019, the entire disclosure of which is incorporated by reference herein.

[0069] In a further extension of the architecture shown in FIG. 10, in one embodiment, each agent may have an avatar that may act as a positive image of the agent to the user (as shown in the upper left corner of the user interface shown in FIG. 7). In one embodiment, one or more attributes of the avatar may evolve or exist according to the agent's scored technical expertise. For example, as the agent becomes more knowledgeable about running, the avatar may acquire different or rarer running shoes. In some embodiments, the agent's selection of avatar adornments (clothing, accessories, activities, scenes, etc.) may provide insight into the agent's interests, which may further aid in routing user queries.

[0070] In yet another embodiment, the system may be used to assist a user in designing a custom product (e.g., a shoe or apparel item) via a web interface, such as the NIKEID® or NIKE BY YOU® systems commercialized by Nike Inc. If the user needs assistance or creative inspiration, the user may have the option to connect with a live agent through the system. Similarly, if the user ponders a particular design choice for more than a predetermined amount of time or changes those choices more than a predetermined number of times, the automated agent 32 may see that the consumer is struggling and may automatically notify the design agent for assistance. The connected live agent may then have the option to chat with the user to assist with the design, take over UI control for the user, or open a video chat session to further engage with the user. Additionally, as the user designs the product, the user interface / experience can be recorded, which may then be converted into a time-lapse video that the consumer can share to their social networks or which can be used by the agent as a record to better assist the consumer next time. In some embodiments, data may be extracted from the video to learn more about how to improve the creation experience for consumers and subsequent users.

[0071] While the above disclosure focuses primarily on a retail / customer service context, this example of current functionality should not be construed to unnecessarily constrain the present technology. Instead, it is an example of the technology being used to facilitate business-to-consumer communications. However, in other examples, the technology may be used to manage communications between companies (e.g., a supply base communicating with an OEM) or even between individuals within a single organization (e.g., a manager and his or her team).

[0072] In these business-to-business examples, the methods of communication are often not that different from retail / customer support contexts. Employees, project teams, and suppliers are exploring new ways to communicate, including SMS / MMS messaging, IP-based chat systems, and other such means of communication. The concept of conversational momentum may be used in a similar way to manage individual response priorities, although explicit response times may not apply to the same extent (i.e., a supervisor texting synchronously may have both high velocity and high mass, whereas an office manager soliciting RSVPs for a pizza lunch via email may have low mass and low velocity). Similar concepts of automated responses may apply in intra-business or inter-business contexts as well.

[0073] In a further enhancement of the system, because the routing engine 28 and automated agents 32 may be persistent and process each message as it is received, the system is particularly well-suited for determining macro-level issues and trends. Furthermore, as the system understands user characteristics, it may be configured to identify the demographics, interests, and / or geographic regions driving the issue / trend. In any instance, this real-time information allows the company to pivot to better meet consumer needs and / or demands (e.g., fine-tuning messages to resolve issues, modifying development / product plans to more quickly respond to trends). Similarly, the agents 32 may be better positioned (i.e., prior to live agent engagement) to assess user response and satisfaction with particular answer types. With this macro-level understanding, the automated agents 32 may adapt their response strategies over time to drive greater user satisfaction. Additionally, the automated agents 32 may use actual live agent responses to users as training data to improve their ability to respond directly to users and / or to provide meaningful, suggested responses to live agents. This training data may also be weighted according to the relative rank or customer service score of the live agents, where the responses of more skilled agents have a greater weight in the training data set than the responses of less skilled agents.

[0074] In one embodiment, the automated agent 32 may have a defined personality for the purpose of generating natural language responses with an appropriate tone. For example, if the system is used to support an athletic goods / equipment brand, the automated agent 32 may be configured to resemble a 25-30 year old D1 athlete (e.g., an All-American runner) after college graduation; a DNA-level athlete but a swaggering beast in the office; an avid brand advocate / ambassador; someone who deals in exclusive sneakers but believes you should wear your kicks from social media to the sports field; someone who has serious opinions about who the GOAT is and what the best meal is after a tough workout; a witty person; a cheeky person; a pro who cultivates long-lasting inside jokes; a friend who never argues with you but is very passionate and very confident (not arrogant); someone who is normal but not out of line; someone who celebrates high-class love. Other personality types may also be used. Finally, an automated agent may have a name like Eugene, but those who know it well may simply call it Rocco.

[0075] Aspects of the present disclosure may be implemented, in some embodiments, through computer-executable programs of instructions, such as program modules, commonly referred to as software applications or application programs, executed by any of the controllers or variations of controllers described herein. Software may include, by way of non-limiting examples, routines, programs, objects, components, and data structures that perform particular tasks or implement particular data types. Software may form interfaces that allow a computer to react according to input sources. Software may cooperate with other code segments to initiate various tasks in response to received data as well as sources of received data. Software may be stored on any of a variety of memory media, such as CD-ROMs, magnetic disks, bubble memory, and semiconductor memory (e.g., various types of RAM or ROM).

[0076] Moreover, aspects of the present disclosure may be implemented with a variety of computer system and computer network configurations, including multiprocessor systems, microprocessor-based or programmable consumer electronics devices, minicomputers, mainframe computers, and the like. In addition, aspects of the present disclosure may be implemented in distributed computing environments where tasks are performed by both resident and remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including memory storage devices. Thus, aspects of the present disclosure may be implemented in connection with a variety of hardware, software, or combinations thereof, in a computer system or other processing system.

[0077] In one configuration, various aspects of Figure 1 may be implemented as executable code within a distributed, cloud-based computing infrastructure that includes one or more server-class computing devices that operate to manage the flow and processing of digital information. A user display such as that shown in Figure 7 may be viewed on a user device, for example, via a dedicated application or an internet browser. The information populating the user display of Figure 7 may be provided, for example, by the server-class computing device used to implement Figure 1. It should be understood that other hardware or computer configurations may be used to embody and / or implement the systems described herein.

[0078] Any of the methods described herein may include machine-readable instructions for execution by (a) a processor, (b) a controller, and / or (c) any other suitable processing device. Any algorithm, software, control logic, protocol, or method disclosed herein may be embodied as software stored on a tangible medium, such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory device. Alternatively, the entire algorithm, control logic, protocol, or method and / or portions thereof may be executed by a device other than a controller and / or embodied in firmware or dedicated hardware, in an available manner (e.g., implemented by an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a field-programmable logic device (FPLD), discrete logic, etc.). Furthermore, although particular algorithms are described with reference to flowcharts shown herein, many other ways of implementing the example machine-readable instructions may alternatively be used.

[0079] Further disclosure of the present technology is provided in the following sections.

[0080] Clause 1. A multi-channel communications platform including a messaging engine, a routing engine, and a queue manager, the messaging engine operative to receive a plurality of text messages from a user through any of a plurality of different messaging services in communication with the messaging engine, the plurality of text messages forming a message thread and including at least one query requesting a reply, the routing engine operative to determine a momentum of the plurality of text messages to assign the message thread to a message queue associated with an agent, and the queue manager operative to identify a response time target for providing a reply to the at least one query, the response time target being inversely proportional to the determined momentum.

[0081] Clause 2. The multi-channel communications platform of Clause 1, wherein the plurality of different messaging services includes at least two of a short message service (SMS), a multimedia messaging service (MMS), a push notification service, an Internet Protocol (IP) messaging service, or an email service.

[0082] Clause 3. The multi-channel communications platform of clause 1 or 2, wherein the routing engine is an automated agent, the automated agent including a natural language response engine configured to understand the context of the at least one query.

[0083] Clause 4. The multi-channel communications platform of clause 3, wherein the automation agent is configured to respond to a first received query of the at least one query.

[0084] Clause 5. The multi-channel communications platform of any one of clauses 1-4, wherein momentum is a function of message thread mass and velocity, wherein message thread mass is a measure of the urgency of the message thread and velocity is a measure of how quickly multiple text messages are received.

[0085] Clause 6. The multi-channel communications platform of any one of clauses 1-5, wherein the message queue includes a plurality of message threads, each message thread having a different momentum value, the message queue has a maximum momentum, and a sum of the momentum values ​​from each message thread of the plurality of message threads in the message queue is less than the maximum momentum.

[0086] Clause 7. The multi-channel communication platform of any one of clauses 1-6, further including an agent interface, the agent interface including a representation of a message queue associated with a live agent, an active chat thread operative to display the message thread and receive a reply from the live agent, and a support window operative to display information about the user.

[0087] Clause 8. The multi-channel communications platform of clause 7, wherein the routing engine includes an automated agent, the automated agent operative to analyze the query and provide one or more suggested responses to a live agent via a support window.

[0088] Clause 9. The multi-channel communications platform described in clause 8, wherein the automated agent is operative to analyze the message thread and, in response, provide a hyperlink to an internet web page where the product is offered for sale, the product being referenced in the message thread.

[0089] Clause 10. The multi-channel communications platform of clause 9, wherein the multi-channel communications platform further includes a database of available product inventory, and wherein the automated agent is operative to provide the hyperlink only if the product is present in the available product inventory.

[0090] Clause 11. The multi-channel communication platform of clause 9 or 10, wherein the hyperlink can be copied into an active chat thread by a live agent.

[0091] Clause 12. The multi-channel communications platform of any one of clauses 7 to 11, wherein the information about the user includes at least one of the user's product preferences, the user's size, an indication of the user's recent browsing history, an indication of the user's product interests, an indication of the user's consumption patterns, a summary of previous message threads between a live agent and the user, a summary of user-tagged products, or a summary of the user's purchasing history.

[0092] Clause 13. The multi-channel communications platform of any one of clauses 7-12, wherein the message queue includes a plurality of message threads, each message thread including a plurality of text messages having a different respective user.

[0093] Clause 14. The multi-channel communications platform of any one of clauses 1 to 13, wherein the queue manager is operative to provide a reward to the agent following a response to a query.

[0094] Clause 15. The multi-channel communications platform of clause 14, wherein the rewards include digital currency, and the platform further includes an avatar representing the agent operative to be displayed to the user, and a digital rewards store operative to provide digital embellishments for display with the avatar in lieu of digital currency.

[0095] Clause 16. The multi-channel communications platform as set forth in Clause 15, wherein the digital adornment is uniquely stored in a token stored on a decentralized blockchain ledger.

[0096] Clause 17. A customer service system that facilitates text exchanges between a user and a live customer service agent, the customer service system including a messaging engine and a routing engine, the messaging engine operative to receive a plurality of text messages from a user through any of a plurality of different messaging services in communication with the messaging engine, the plurality of text messages forming a message thread and including at least one query requesting a reply, the routing engine operative to analyze the message thread and provide auxiliary information related to at least one of the user, the message thread, or the query to the live customer service agent, the customer service system including an automated agent.

[0097] Clause 18. The customer service system of clause 17, wherein the automated agent includes a natural language response engine configured to understand the context of the at least one query.

[0098] Clause 19. The customer service system of clause 17 or 18, wherein the customer service system further includes an agent interface, the agent interface including an active chat thread operative to display the message thread and receive a response from a live agent, and a support window operative to display auxiliary information.

[0099] Clause 20. The customer service system of any one of clauses 17-19, wherein the automated agent is operative to analyze the query and the auxiliary information includes one or more suggested responses to the query.

[0100] Clause 21. The customer service system of any one of clauses 17-20, wherein the auxiliary information includes a hyperlink to an Internet web page where the product is offered for sale, the product being referenced in the message thread.

[0101] Clause 22. The customer service system of clause 21, wherein the customer service system further includes a database of available product inventory, and wherein the automated agent is operative to provide the hyperlink only if the product is present in the available product inventory.

[0102] Clause 23. The customer service system of any one of clauses 17-22, wherein the auxiliary information includes at least one of the user's product preferences, the user's size, an indication of the user's recent browsing history, an indication of the user's product interests, an indication of the user's consumption patterns, a summary of previous message threads between a live agent and the user, a summary of user-tagged products, or a summary of the user's purchasing history.

Claims

1. 1. A method of providing customer service, comprising: electronically receiving a query from a user via a messaging engine; analyzing the inquiry to determine inquiry parameters selected from the group consisting of complexity of the inquiry, number of outstanding inquiries, and urgency of the inquiry; adjusting a reward amount based on the query parameters, the reward amount increasing as the complexity, number of outstanding queries, or urgency increases; providing the adjusted reward amount to a pool of agents; assigning the query to a message queue of an agent from the pool of agents that accepts the provided adjusted reward amount. method.

2. The method of claim 1 , wherein the pool of agents includes a plurality of dedicated agents and a plurality of on-demand agents.

3. determining a required experience level in response to said query; providing the adjusted reward amount only to agents in the pool of agents that have at least the required experience level. The method of claim 1.

4. receiving a response to the query from the assigned agent; evaluating the response according to at least one business driving metric selected from the group consisting of proactive dispute resolution, encouraging account participation, encouraging account login, building a relationship with the user, getting the user to click on a link, and making a sale; further adjusting the reward amount based on the evaluation; and providing the further adjusted reward amount to the assigned agent. The method of claim 1.

5. The method of claim 1 , wherein the reward amount comprises digital currency.

6. The method of claim 5 , further comprising allowing the assigned agent to exchange the digital currency for a digital item associated with an avatar representing the assigned agent.

7. 10. The method of claim 1, further comprising determining a momentum score for the query based on a rate of user messages and a mass of the query, the mass being determined by a natural language processing algorithm that evaluates the sentiment and nature of the query.

8. The method of claim 7 , wherein the urgency of the query is based on the determined momentum score.

9. 10. The method of claim 1, further comprising filling a support window on the assigned agent's user interface with information about the user, the information including at least one of the user's product preferences, the user's size, a display of the user's recent browsing history, a summary of the user's product interests, a summary of the user's consumption patterns, a summary of previous message threads with the user, a summary of user-tagged products, or a summary of the user's purchase history.

10. 10. The method of claim 1, further comprising generating, by an automated agent, one or more hyperlinks to Internet web pages where products are offered for sale, said hyperlinks being derived from the context of said inquiry.

11. 11. The method of claim 10, wherein the internet web page belongs to a retailer and allows inventory from third parties to be purchased through the retailer's web page.

12. 1. A system for providing customer service, comprising: a messaging engine operative to receive a plurality of text messages from a user, the plurality of text messages forming a message thread and including at least one query requesting a reply; an analysis module configured to analyze the query to determine query parameters selected from the group consisting of: complexity of the query, number of outstanding queries, and urgency of the query; a pricing module configured to adjust a reward amount based on the query parameters, the reward amount increasing as the complexity, number of outstanding queries, or urgency increases; and an agent pool including a plurality of agents; a queue manager configured to provide the adjusted compensation amount to the agent pool and assign the query to an agent from the agent pool that accepts the provided adjusted compensation amount. system.

13. The system of claim 12 , wherein the agent pool includes a plurality of dedicated agents and a plurality of on-demand agents.

14. The method further includes a response evaluation module, the response evaluation module comprising: receiving a response to the query from the assigned agent; evaluating the response according to at least one business driving metric selected from the group consisting of proactive dispute resolution, encouraging account participation, encouraging account login, building a relationship with the user, getting the user to click on a link, and making a sale; adjusting the reward amount based on the evaluation; It is configured as follows: the pricing module is further configured to provide the adjusted compensation amount to the assigned agent. The system of claim 12.

15. 13. The system of claim 12, further comprising a momentum monitor configured to determine a momentum score for the query based on a rate of user messages and a mass of the query, the mass being determined by a natural language processing algorithm that evaluates a sentiment and a nature of the query.

16. The system of claim 12 , wherein the messaging engine is configured to receive messages from a plurality of different messaging services, and the message thread is made available across the plurality of different messaging services.

17. 13. The system of claim 12, further comprising an automated agent configured to conduct preliminary discussions with the user after receiving an initial message, the automated agent operative to handle simple requests to obtain necessary information requested by a live agent.

18. 13. The system of claim 12, wherein the queue manager is further configured to set a response time target for the assigned agent to provide a reply to the query, the response time target being inversely proportional to the determined momentum of the message thread.

19. 13. The system of claim 12, further comprising a routing engine configured to identify a primary question and one or more secondary questions in the query, assign the primary questions to a primary agent, and enable the primary agent to forward the one or more secondary questions to one or more secondary agents.

20. 20. The system of claim 19, wherein responses from the one or more secondary agents are sent to the primary agent for composition into a conversation with the user.

Images