Multi-channel communications platform with dynamic response targets

Abstract

To provide a system capable of providing relationship-rich omni-channel communication and support at a large scale while simplifying conversations.SOLUTION: A multi-channel communication platform includes a messaging engine, a routing engine, and a queue manager. The messaging engine is operative to receive a plurality of textual messages from a user through any of a plurality of different messaging services 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 is operative to determine a momentum of the plurality of textual messages and to assign the message thread to a message queue associated with an agent. The queue manager is operative to specify 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 technologies, the way individuals and businesses communicate is rapidly changing. Unlike voice communication, where an individual can generally only maintain one conversation at any given time, new forms of communication (e.g., SMS, MMS, IP-based client messaging) allow users to converse simultaneously with multiple different parties. In addition to being able to handle many more simultaneous conversations, these new means of communication may each have an acceptable response time that may vary based on the urgency of the user. 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. In one study, a standard web chat involving an average 8-minute handle time over an 8-minute continuous block of time, whereas an SMS chat spread over 1.5 hours of sporadic contact, involved a similar average 8-minute handle time.

[0004] The challenge of managing acceptable response time targets becomes especially problematic if agents are asked 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 consumers with a superior level of service. The system may allow clienteling at scale to create long-term relationships that are less likely to break, while also enabling cross-platform communications that can pivot to real-time consumer demands. In a broad sense, the goal of the system is to provide relationship-rich omnichannel communications and assistance at scale while making conversations easy.

[0006] In some embodiments of the present disclosure, a multi-channel communications 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 requesting 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 goal for providing a reply to the at least one query, the response time goal 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 provide the live agent with suggested response language to address the user's queries. In some embodiments, the automated agent may populate 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 on the window one or more hyperlinks to Internet web pages where the product is 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 merchant's web pages. [Brief description 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] [Diagram 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] [Diagram 3] 1 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] [Diagram 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 as well as providing a quick response to a user.

[0016] [Figure 8] FIG. 1 is a schematic flow diagram illustrating a process of 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 PREFERRED EMBODIMENTS

[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 potential 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. Additionally, 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 an agent based on the user's speaking speed and / or the perceived urgency of the user's message. In doing so, the system differs from conventional 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 different agents. To provide a better flow to the conversation with the user, one agent may be considered a primary response agent, and all other secondary response agents may feed their responses to that primary response 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 manner, 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 communications network, utilize one or more different transport protocols, and / or communicate with different endpoint devices. Examples of the 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 communications service. Each of the messaging services 24 may include dedicated communications 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 with which users may communicate. The messaging engine 22 may be used in sending messages via the messaging clients, receiving messages, and managing synchronous / asynchronous communication sessions. In one configuration, the messaging engine 22 may be configured to communicate using a number of 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 provide an API that allows two-way communication with other clients / users on that service.

[0027] 2 shows generally how a message received from messaging service 24, as shown in FIG. 1, may be taken and assembled into a message thread and passed to message routing engine 28. 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 be placed in front of 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. With continued reference to FIG. 2, if the user identification information from the message is recognized from a user database (at 54), 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 the 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, an orphan thread or the temporary account created may be migrated to the user's account after the conversation once order-specific details are provided to the agent. 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, the 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, the routing engine 28 may include an automated agent 32 or artificial intelligence that can understand the nature and context of the message, and a momentum monitor 34 that operates to determine the momentum of the message thread. Knowing the nature and context of the message may enable the routing engine 28 to identify an appropriate agent (or a pool of qualified agents) to handle the query based on the subject matter, technical expertise, or sensitivity of the request. Furthermore, by knowing the momentum of the message thread, the system may become more adept at balancing the message load among individual agents according to the sensitivity and / or message frequency of the 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 an order status, and the like. Additionally, the automated agent 32 may function to obtain essential information that may be required by a live agent. For example, if a return is requested, the automated agent 32 may inquire about the specific product, the order number, and / or the underlying reason for the return.

[0032] In general, including an automated agent 32 in the initial message reception may provide several benefits. First, it may dispose of simple requests at a lower cost than if a live agent were needed. Second, it may gather information that may be needed by an agent to answer a particular query. In this way, a live agent does not have to spend response time / effort doing preliminary fact-finding. Third, the automated agent 32 may engage with the user in a rapid 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 may help prevent the creation or escalation of user frustration. Finally, interactions with the automated agent 32 may generate a base message thread from which a momentum monitor 34 may determine the momentum of the conversation and set appropriate response time targets for the live agent.

[0033] The concept of conversation momentum recognizes that different users may send messages at different rates and with different levels of urgency when conversing on a text-based messaging platform. A user engaged in a synchronous conversation (i.e., a real-time exchange) may have a high rate that may require greater agent capacity (i.e., if an agent is engaged in a real-time exchange, there is 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 as 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 the query must also be taken into consideration when determining the response target. A very urgent request, or one that leaves the user feeling more frustrated or angry, may require a more immediate agent response so as not to unnecessarily escalate concerns. Conversely, a casual request (e.g., what's new 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, the mass of a conversation 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 previous 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 the 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 is given, mass can be used to adjust an agent's queue size or the number of other message threads that an agent may be processing simultaneously with the request. In this example, a celebrity may consume an agent's entire queue such that the agent is not processing other message threads. Similarly, a sporadic consumer may be assigned to an agent who is managing multiple message threads simultaneously.

[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 a percentile-like scoring, where 0 has absolutely no urgency or emotion and 100 has 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 inquiries. 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 thus be equal to the relative scored mass multiplied by the average frequency.

[0037] A histogram of conversation momentum 65 has 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 goal 66 (represented on a secondary y-axis). For example, a conversation having momentum in the lowest decile 68 (i.e., the lowest momentum constituting a relatively slower messaging rate and relatively lower urgency) may have a response time goal set at a first value 70, such as 15 minutes. Conversely, a conversation having momentum in the highest decile 72 (i.e., the highest momentum constituting a relatively higher messaging rate and relatively higher urgency) may have a response time goal set at a second value 74, such as 15 seconds. Finally, a conversation having momentum at the median 76 of the momentum distribution may have a response time goal set at a third value 78, such as 30 seconds. In one configuration, as shown via the exemplary target, the response time target function across the distribution may be non-linear because it is found that differences in user expectations at the high end of the distribution only vary slightly, whereas acceptable response times at the low end of the distribution are more affected by the user's sporadic speech patterns, which result in significantly larger response times. Thus, the applicable response time target may vary inversely, but non-linearly, with the determined momentum. In another embodiment, not shown, the applicable response time target may vary inversely and linearly with the determined momentum.

[0038] 1, in one configuration, the momentum monitor 34 may analyze a preliminary conversation between the user and the automated agent 32 to assess the mass 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 the size of the agent's queue, and enable agents to prioritize which outstanding queries to respond to first.

[0039] 4 illustrates generally how a user query may be initially responded to by the automation agent 32. As illustrated, once a message thread (any indication that a new thread is being opened) is passed to the routing engine 28, the automation agent 32 may review (at 80) the initial message using one or more natural language algorithms to determine the nature and urgency of the request. The automation agent 32 may then respond (at 82) 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 automation agent 32 may determine (at 84) whether the previous response satisfied the user's query. If so, the automation agent 32 may close (at 86) the thread. If not, the agent 32 may follow up with the user (at 88) or pass the thread to the momentum monitor 34 (at 90).

[0040] FIG. 5 illustrates generally one method of operation of the momentum monitor 34. As shown, the momentum monitor 34 may review the 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 total 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 early user response times). The momentum monitor 34 may then perform (at 94) an assessment of the conversation mass based on at least one of a natural language assessment of the sentiment of the message (e.g., strongly positive to strongly negative) and / or the nature of the request (e.g., business as usual to urgent), or user characteristics, attributes, relationships or engagement with the company, sales history, public impact, social media presence, and / or the like.

[0041] From the calculated speed and the 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 conversation 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 generally includes multiple live agents (A1-An), each with their own respective message queues (Q1-Qn) that the live agents are involved in answering / managing. Generally, a message queue may include one or more conversation threads that the live agents are responding to at any given time. FIG. 6 shows a schematic example of a message queue 38 including multiple open message threads 100, each with a determined thread momentum 102. Each live agent may have a predefined 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 the queues 38 of the live agents does not exceed the maximum response capacity 104 of the agent. 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 have been assigned to a respective thread momentum 102. In such a case, 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 with the queue manager 30 to determine which agents within this subset will 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 that the live agent has the relevant expertise to answer, and may then be able to select or opt into the 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. In general, the response time goal is the target maximum time allocated by the agent to respond to an outstanding user query. The response time goal may vary inversely proportional to 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 a 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 on the road, 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 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, for example, using a simple or exponential moving average, or other weighting scheme that may assign greater weights to more recent momentum calculations than more distant ones. In this way, users who wish to engage in synchronous conversations 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 thread momentum 102 in the agent's queue 38 to exceed the agent's maximum response capacity 104, the routing engine 28 may reassign the particular thread (e.g., a thread with updated user interest, or a thread with a relatively lower mass or momentum) to a different live agent, either automatically or after confirmation by the 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), the 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. Additionally, 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 / automation 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 automation 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 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 the final discretion to include the suggested language in the response, modify / supplement the suggested language in the 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 such that the automated agent may provide improved and / or more relevant suggestions in the future.

[0049] 7 shows a schematic of one 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 auxiliary information received (from the automated agent 32) may be displayed. The agent's queue 38 may include a number of active threads 100, including a first number of active threads 146 that are waiting for an agent's response and a second number of active threads 148 that have been responded to that are waiting for the user's follow-up. Each thread 100 may include an associated name 150 (e.g., a user name or the 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, the chat thread 142 may include a mixture of messages / queries to an agent / company 160, messages 162 from the automated agent 32 to a live agent (e.g., to facilitate handoffs), 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 the chat, the support window 144 may serve as the agent's main source of information regarding the user and the user's queries. 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 attributes section may include, for example, user profile information 180, user history information 182, and user account information 184. The 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 that 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 spending patterns, and / or the user's contact information. The history information 182 (i.e., the history information that may be populated once a tab header is selected) may include, for example, a summary of previous conversations with other agents, the user's social media engagement, tagged products, shared products, product suggestions of previous agents, and the like. Finally, the account information 184 may include a summary of the user's previous orders, products ordered, products preferred, 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 best quality answer to the user. 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 be 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 the 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 have been 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, the routing engine 28 may begin by identifying a primary question / query (at 208). A primary question may be the question that is determined to have the greatest mass or urgency, the greatest potential for growth, and / or that may be answered by the widest number of agents (according to a predefined agent scoring that indicates the level of specialization of the agents and their sophistication). In a general sense, knowledgeable, specialized agents (e.g., Olympic athletes) are a more expensive resource than less knowledgeable agents. With continued reference to FIG. 8, once the primary question has been determined (at 208), an agent with the 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, the 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 is present in the message or thread. In one configuration, the primary agent may select one of the non-primary objects (i.e., the secondary question / object) and choose to forward (at 216) that secondary question to the 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, the process allows the primary agent to answer questions that they are comfortable with while referring them to questions that are more difficult or require 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 that fit the determined category. Alternatively, agent selection may still be based on suitability of the determined topic category for the query, but may occur outside of the primary agent's view. In yet other embodiments, the primary agent may flag the topic for assistance, which may send the query back to a broader pool of live agents from which other available agents may select the query or may 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 illustrates generally 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, the database 252 may be a persistent database that is updated periodically, or alternatively, the database 252 may be generated on-demand by the automation agent 32 polling one or more of the stores / businesses 256, 258, 260, 262 upon identification of 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 the retailer or a 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 the user's requested timeline cannot be met by the retailer, the timeline may dictate referencing third-party inventory. For example, if the 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 manner, knowledge of the user's location as well as 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 may 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 have to hunt around to third parties to determine availability.

[0061] Regardless of where the product originates, in one configuration, link 270 may take the user to a front-end user interface, such as an internet app or product website 280 maintained by the retailer that serves as the sales interface for all purchases. More specifically, link 270 may take 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 take 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 checker based on the preferred consumer language, prices are only in the consumer's correct currency, etc. This can then allow agents around the world to assist any customer as long as they can speak / write the same language as the consumer they are supporting. For example, if a live agent in the US 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-A of FIG. 1 ) are deployed to respond to inquiries / communications 304 from a user population 306. n3 shows a schematic of 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 ) live agents 302 may alternatively include multiple dedicated live agents 308 (i.e., where customer service is the primary function, even if they work in a physically distributed manner) and / or multiple on-demand live agents 310. In general, 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 who are 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 businesses or consumer-facing roles, and the like).

[0064] One or more rewards 312 may be provided to encourage elastic agent pools, particularly among distributed / on-demand live agents 310, to accommodate the needs of the user population 306, as well as 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 open / unassigned user inquiries, and / or the mass of a 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, the 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 a particular inquiry. For example, in the context of athletics, a college athlete may be deemed to have greater technical expertise in his or her 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 at which 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 agents with relevant technical and customer service expertise (e.g., scores). In this way, a marathon runner with an urgent pre-race query may have the query filtered so that only agents with a certain level of running experience and a demonstrated level of responsiveness / problem-solving ability may see the query.

[0067] Following this filtering, if the mass of new conversations does not exceed the agent's available pre-determined capacity, available agents 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 embodiment, positive dispute resolution outcomes and advancement of business promotion goals may trigger positive reward adjustments, whereas conflict escalation and anti-business statements may trigger negative reward adjustments. Examples of positive business practices that should be rewarded include, for example, getting a user to join a new customer account, encouraging a user to log into an existing account, establishing a relationship with a consumer such that an inquiry or contact occurs following resolution of an 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 customer satisfaction surveys 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 a direct monetary value and may be exchanged for cash, merchandise, and / or discounts via the reward store 326. In another embodiment, the reward may be a token or credit that does not have a 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 values ​​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 enable the agent to receive one or more digital collectables, which may be uniquely stored / identified / verified on the blockchain ledger (i.e., where the digital collectibles directly correspond to tokens stored on the distributed blockchain ledger) to ensure their rarity value. In a further enhancement, this digital collection may be used in one or more video game applications to improve a user's character or gameplay attributes, as described in U.S. patent application Ser. No. 16 / 707,741, filed December 9, 2019, the entire disclosure of which is incorporated by reference for all purposes.

[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 forward-looking 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 help a user design a custom product (e.g., a shoe or apparel product) via a web interface, such as the NIKEID® or NIKE BY YOU® systems commercialized by Nike Inc. If the user needs assistance or creative stimulation, the user may have the option to connect with a live agent via 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 the user's UI control, or open a video chat session to further engage with the user. Additionally, as the user is designing the product, the user interface / experience may be recorded, which may then be converted into a time-lapse video that is shared by the consumer to their social networks, or it may be used by the agent as a record that can 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 has focused primarily on a retail / customer service context, this example of current functionality should not be construed as unnecessarily constraining the technology. Instead, it is an example of the technology being used to facilitate business-consumer communications. In other examples, however, 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 team).

[0072] In these business-business examples, the methods of communication are often not that different from retail / customer support contexts. Employees, project teams, and suppliers are looking for new ways to communicate, including SMS / MMS messaging, IP-based chat systems, and other such means of communication. The concept of conversation 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 asking for an RSVP 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 extension of the system, since the routing engine 28 and the automated agent 32 may be persistent and may process each message as it is received, the system is particularly suited to determine macro-level issues and trends. Additionally, as the system understands the characteristics of the user, it may be configured to identify the demographics, interests, and / or geographic regions that are driving the issues / trends. In any instance, this real-time information may enable the company to pivot to better meet the needs and / or demands of the consumer (e.g., tweak messages to solve the problem, change development / product plans to respond more quickly to trends), as well as position the agent 32 well (i.e., prior to live agent engagement) to assess user response and satisfaction to a particular answer type. With this macro-level understanding, the automated agent 32 may adapt its response strategy over time to drive toward greater user satisfaction. Additionally, the automated agent 32 may use actual live agent responses to users as training data to improve its ability to respond directly to users and / or to improve its ability to provide meaningful suggested responses to live agents. This training data may further 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 personality defined for purposes 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 post-college D1 athlete (e.g., All-American runner), a DNA level athlete but a pompous 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 on who is the GOAT and what is the best meal after a tough workout, a witty person, a sassy person, a pro at cultivating long-lasting inside jokes, a friend who never argues with you but is very passionate and very confident (not arrogant), a person who is normal but not out of line, someone who celebrates high-end love. Other personality types may also be used. Finally, the 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 through computer-executable programs of instructions, such as program modules, generally referred to as software applications or application programs, executed by any of the controllers or variations of controllers described herein in some embodiments. Software may include, in 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 the computer to react according to input sources. Software may work in conjunction with other code segments to initiate various tasks in response to data received as well as sources of data received. 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 disclosure may be implemented in 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 disclosure may be implemented in distributed computing environments where tasks are performed by 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 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 in a distributed, cloud-based computing infrastructure including 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 overall algorithm, control logic, protocol, or method and / or parts thereof may be executed by devices other than a controller and / or embodied in firmware or dedicated hardware in an available manner (e.g., may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Furthermore, although certain algorithms are described with reference to the flow charts 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 goal for providing a reply to the at least one query, the response time goal 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 clauses 1 or 2, wherein the routing engine is an automation agent, the automation agent including a natural language response engine configured to understand a 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 mass and velocity of a message thread, the mass of the message thread being a measure of the urgency of the message thread and velocity being 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 communications platform of any one of clauses 1-6, further comprising 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 automation agent, the automation 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 of 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 communications 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 following: 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, the platform further comprising 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 described in clause 15, wherein the digital adornments are uniquely stored in tokens stored on a decentralized blockchain ledger.

[0096] Clause 17. A customer service system that facilitates text exchange 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 a context of the at least one query.

[0098] Clause 19. The customer service system of clause 17 or 18, further comprising 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 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. A messaging engine; A routing engine; A queue manager, an agent interface; the messaging engine is 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; the routing engine is operative to send the message thread to a message queue associated with a live agent, receive a reply from the live agent, and send the reply to the user; The agent interface includes: an active chat thread operable to display the message thread and receive the reply from the live agent; a support window operative to display contextual information to the live agent about at least one of the user or the message thread; the queue manager is operative to identify a response time goal for providing the reply to the at least one query; the queue manager is operative to provide a reward to the live agent following a response to the query; the reward is a variable reward based on one or more of the perceived complexity of the query, the number of open or unassigned queries, or the perceived urgency of the query; the routing engine is further configured to determine a momentum of the plurality of text messages, the response time goal varying inversely with the determined momentum. A multi-channel communication platform.

2. 2. The multi-channel communication platform of claim 1, wherein the routing engine includes an automated agent configured to analyze the query and provide one or more suggested responses to the query to the live agent via the support window.

3. the automated agent is operative to analyze the message thread and, in response, provide a hyperlink to the live agent via the support window; the hyperlink operatively references an Internet web page where a product is offered for sale, the product being referenced at least in part in the message thread; The multi-channel communications platform of claim 2 .

4. 4. The multi-channel communications platform of claim 3, further comprising a database of available product inventory, and wherein said automated agent is operative to provide said hyperlink only if said product is present in said available product inventory.

5. The multi-channel communication platform of claim 3 , wherein the hyperlink can be copied by the live agent from the support window to the active chat thread.

6. 2. The multi-channel communications platform of claim 1, wherein the contextual 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 products tagged by the user, or a summary of the user's purchasing history.

7. The multi-channel communications platform of claim 1, wherein the momentum is a function of mass and velocity of the message thread, the mass of the message thread being a measure of the urgency of the message thread and the velocity being a measure of how quickly the multiple text messages are received.

8. the message queue includes a plurality of message threads, each message thread having a different momentum value; the message queue has maximum momentum; 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; The multi-channel communications platform of claim 7.

9. The multi-channel communication platform of claim 1 , wherein the routing engine includes an automation agent, the automation agent including a natural language response engine configured to understand a context of the at least one query.

10. The reward includes digital currency; The multi-channel communication platform includes: an avatar representing the live agent operable to be displayed to the user; a digital rewards store operative to provide digital ornaments for display with the avatar in lieu of the digital currency. The multi-channel communications platform of claim 1 .

11. The multi-channel communications platform of claim 10 , wherein the digital ornament is uniquely stored in a token that is stored on a distributed blockchain ledger.

12. the live agent has an associated experience score; the routing engine is operative to analyze the message thread to determine a required experience for responding to the query; the routing engine is operative to send the message thread to the message queue associated with the live agent if the experience score associated with the live agent is greater than the determined required experience for responding to the query. The multi-channel communications platform of claim 1 .

13. The multi-channel communication platform of claim 1 , wherein the routing engine selects the live agent from a pool of live agents.

14. The multi-channel communication platform of claim 13 , wherein the pool of live agents includes a plurality of dedicated live agents and a plurality of on-demand live agents.

Images