Managing queue time at peak hours (queue cleanup solution)

• Brands experiencing extremely long queues and wait times.
• Multiple conversations in the queue are being abandoned by consumers and are no longer needed.
• Brands are looking for a solution to clean up the queue and close conversations where the consumer is no longer there or not responsive.
• The existing ETS solution has several disadvantages, primarily the fact that consumers need to be removed from the queue to check in with them, which affects reporting and FIFO behavior, number of different components involved, complexity of solution, influences queue wait times, etc.

• User requests conversation and enters queue to get support
• After X minutes in the queue, the consumer will be asked to reply if they still need to be connected to an agent.
• If the consumer replies with any utterance they remain in the queue on which they are waiting to be connected. The Queue position remains unchanged.
• If the consumer does not reply they will be marked as eligible for autoclose.
• Once the autoclose period has elapsed since the question was asked, the conversation will be closed on the next autoclose cycle.

1. Automatic Message
   • Waiting in Queue for X minutes
2. Autoclose
   • Based on skill
3. LP Back-end Configuration
   • Enable the new feature allowing in-queue conversations to be marked eligible for auto close in the skills managed by this solution

1. Configure Messaging Automatic Message ‘Waiting in Queue for X minutes’:
   • 30 minutes
   • Skills: BRC-General, MPSC-General, Res-General, Res-DOM-General, Refunds-General
2. Configure auto close
   • Auto Close for the BRC-General, MPSC-General, Res-General, Res-DOM-General, Refunds-General skills is set to 25 minutes

1. The consumer is transferred from the Bot to one of the human skills managed by this solution:
   • BRC-General
   • MPSC-General
   • Res-General
   • Res-DOM-General
   • Refunds-General
2. Consumer begins waiting in queue
   • I.e : waiting in BRC-General queue
3. After Consumer been waiting for 30 minutes in queue, the Waiting in Queue automatic message will be sent to the consumer
   • <If you still need help please type anything. If you don't respond within 30 minutes your conversation may be closed.>
4. If the consumer responds, the conversation will remain in queue
5. If the consumer has not responded within Y minutes the conversation will be marked as eligible for autoclose, and the next time the autoclose job runs the conversation will be closed if it has not yet been assigned to an agent.

Skill level autoclose

Pros

1. Product and supported by LP support
2. A simpler solution, with fewer points of failure, a solution owned by LP, more stable solution
3. Consumers are not removed from the queue, so they remain in the FIFO order
4. Consumers are not removed from the queue, so wait time-related metrics are accurate

Cons

1. Consumers cannot say "no" to be immediately removed
2. Time To Removal is variable, subject to autoclose cycle

The QCU BOT trigger time (# minutes a customer has been waiting in Queue after requesting agent assistance) is dynamically configurable by United. Launch time will be set to 90 minutes (as is today). *Included in Design

• Product solution does support configuring of the in-queue automatic message with configurable amount time. Stays exactly as is today

The QCU Bot trigger time and follow-up message can be differentiated between skills

• Product solution does support configuring the in-queue automatic message on different skills with configurable amount of time and message. Stays exactly as is today

Once the follow-up message is presented to the customer, at 30 minutes (Ex: Just checking in…..Do you still need help?...) – the customer will be presented 3 options that map to and will result in the following actions:

1. Yes – Receive Response (Ex: Thank you for continuing to hold……Agent will reply once assigned) Remain in Queue unchanged in priority and placement
2. No – Instantly leave the Queue. Be presented with a follow-up question (Ex: Return to Main Menu or End Conversation)
   • The product solution will not support a conversation dialog. It will ask for consumers to type any character to let us know if you need help. It is still gracefully confirming whether consumers need help and allowing them to respond if they do.
   • Also, consumers are NOT leaving the queue that they are in, therefore not losing the position in the queue.

There are 2 critical reporting/analytics components to this Action that I want to be sure are addressed with the solution:

The Estimated Wait Time and # in Queue (as represented in the Managers Workspace and for (EWT) as shown to new customers entering the Queue) for each Queue/Skill needs to be dynamically updated and reflect all Customers that respond “No”

• The Product solution does not remove consumers from the queue, therefore the EWT will be much more accurate than the custom solution.
• Also, EWT is based on valid conversations in the queue - people who still need help and people who need time to respond to the question. Everyone who has not been removed, should be counted and in the Product solution they are counted.

Reporting/Historical metrics need to reflect “Waiting for Assignment” time until the Customer says “No” and not be included in the denominator or any sort of calculation for “Average Time to Agent Assignment” or “Agent Response”

These metrics provide accurate avg wait time only for those conversations that actually got assigned to an agent, so anyone who is removed from the queue by this solution will not be included in final number/calculation

Reporting – QCU for Go Live needs to include, by Conversation ID - Custom Solution for Reporting (Messaging Interactions API)

1. Time entered Queue

• Same as for any conversation. Available in MI API (metadata)

1. Time presented QCU Followup Message

• Same as for any conversation. Available in MI API (transcript)

1. Customer Response

• Same as for any conversation. Available in MI API (transcript)

1. Time of Agent Assignment (where applicable)

• Same as for any conversation. Available in MI API (agent assignments)

1. Responsive/Non-Responsive Customer (Y/N)

• Same as for any conversation. Available in MI API (transcript)

1. Total Time spent in Queue

• Same as for any conversation. Available in MI API (metadata) OR
• Available in Messaging Operations API (Queue Health method)

No Response – Dynamic Auto close within 10 or 15 minutes (TBD by UA Business), all the while maintaining their place in Queue.

(For example: If a Customer has been waiting for 30 minutes -> Gets the QCU Followup Message -> Doesn’t respond for 7 minutes -> Reaches Agent at 9 minutes) That would be an instance where the Customer never responded to the Followup but was still assigned to an Agent. We will monitor these situations to understand the Ghost Conversation Percentage and adjust the Auto Close time.

The product solution does depend on AutoClose cycles. Minimum Auto Close cycle is 25 minutes.

The timeframe of conversation stays in queue after   25 - 50 minutes from the moment they are asked.

Today people are given 15 minutes to respond before they are considered for closure and removed.

On average, with the new solution, non-responsive customers will get removed in around ~35 minutes

Overall experience:

• Consumer didn’t reply , but still got connected to an agent
• Consumer - not a bad consumer experience.
• Operations: It can be inefficient, but overall doesn’t impact agents/consumers.

In the existing, custom solution:

• If a consumer doesn’t says yes, they will never be assigned. They are in queue and will not get back to queue, unless they said ‘Yes.

In the new, v1 product solution:

• All Consumers that are in queue can be assigned, unless enough time went by for unresponsive to get closed