Callbacks higher priority = handled out of order

[mattknappchhj]

Hello,

We have been using this plugin for a bit now and have noticed that callers who opt for the callback option are called prior to those that wait in the queue due to the callback task having a higher set priority. Ideally, the caller would retain their spot in line vs jumping to the head of the queue, but you aren't able to programmatically set a queue entered date to tell taskrouter that the task has been in queue for longer than the created date.

This should be edited for this plugin as it creates a negative user experience, do you have any guidance on how to fix this?

[rnairtwilio]

@mattknappchhj we are currently looking at this issue and will update you in a couple of days.

[vernig]

@mattknappchhj you can change the priority for both the Voice Mail and Callback task in options.private.js. The two options to modify are:

• VoiceMailTaskPriority
• CallbackTaskPriority

Is that addressing your requirements?

[mattknappchhj]

Hi @vernig,

The challenge is that the repo is creating a new task for the callback/voicemail.

Since the Twilio TaskRouter uses a combination of the time created and priority, the queueing isn't effective for a true "callback" solution.

Here is an example:

3 callers enter the queue. Caller 1 enters at timestamp 1, caller 2 enters at timestamp 2, and caller 3 enters at timestamp 3 - in chronological order. Caller 1 should be answered first since they enter the queue first - caller 1 decides to wait on hold instead of opting for a callback. Caller 2 opts for the callback, a new task is created. If the priority is set to the same as a standard inbound call, caller 2 is placed behind caller 3 since the queue entered time is later than caller 3's, making the order 1-3-2. If you use the priority feature to prioritize the callback feature, caller 2 is placed ahead of caller 1 and "jumps the line" while caller 1 is on hold, making the order 2-1-3. Neither solution is appropriate for a "callback" - there should be a feature to supply the queueEnteredDate to preserve the queue ordering of 1-2-3.

I hope this helps clarify the challenge here - let me know if this is unclear so I can further clarify.

[vernig]

Thanks for your input @mattknappchhj. I see what you mean.

If the priority is set to the same as a standard inbound call, caller 2 is placed behind caller 3 since the queue entered time is later than caller 3's

As a matter of fact this is exactly what you want to achieve in a busy contact center. Generally speaking, callback functionality is not about maintaining the order the calls comes in but serving waiting calls as fast as possible. If caller 3 decides to wait in queue, you want to answer to them as soon as possible. Caller 2 requested a callback, so likely their request is less time sensitive, so it's fine to call them at a later stage when the contact center is less busy.

An alternative approach could be having the callback and voicemail tasks be handled by a completely different team, that works on different priorities. Yet another could consist in offering the customer a day / time for when he wants to receive the callback.

This plugin is mainly focused at showing you how to implement the prompts to the customer during the waiting. The strategy for callback should be tailored based on your need, but it could be challenging to implement a mechanism to keep the ordering of the call as they came in.

Hope that make sense?

[mattknappchhj]

If caller 3 decides to wait in queue, you want to answer to them as soon as possible. Caller 2 requested a callback, so likely their request is less time sensitive, so it's fine to call them at a later stage when the contact center is less busy.

I agree with the logic to serve "waiting" customers faster, however that means that if there are always calls in queue waiting that you would never call back those who request a callback if you de-prioritize the tasks. It also goes against the sort of best practice messaging used for callback queues i.e. "You will not lose your spot in line" etc.

For our call center, we leverage the same resources for both inbound and callback calls, which means that callback calls either have to skip the line to the front of the queue or risk a delay in return during periods of high or consistent volume. For sales, this creates a challenge as getting back to callers quickly improves our conversion rates. This seems to me more like a deficiency in the product offering vs an intended feature or CX strategy. I think being able to manually specify a queue entered date in the TaskRouter product would help this plugin (and likely many others) deliver at a higher mark than current state.

Other use cases I can think of would be re-queueing tasks that are delivered to the wrong queue. Does it make sense for that caller to jump the line to the head of the queue when they selected the wrong option for queuing? Not really. What about sending them to the back of the line where they may wait longer than if they selected the right option? Not a good CX solution either.

I agree that in an ideal scenario we would have perfect SLA's and never have to worry about this, but then again that is the whole reason why this plugin exists as that is quite challenging to plan for.

[vernig]

Thanks @mattknappchhj for the valuable input! If you are a Twilio customer already (as I guess you are since you are looking at this repo) I'd advice you to get in touch with your sales rep and ask them to file a feature request for TaskRouter, so our team can evaluate it. The "task entered time" handling is definitely a good suggestion for product improvement.

To address some of your other comments, I agree with you that there are many several use cases (support calls, sales call, lead generation, etc...) and this plugin cannot address all of them, since there is no one size fit all approach. As I mentioned in my previous comment, this plugin is more of a proof of concept of how you can go about creating a callback / voicemail mechanism, but it's not a replacement for TaskRouter functionality, and also there are many additional features that can be developed on top of it.

For example you mentioned about task starvation (if the callback task priority is set lower than the incoming call task). In this case, if the call is a support call, I can think about two approaches:

• Keep the same priority (so the callback task is just sent back to the end of the queue)
• Implement an algorithm to avoid starvation incrementing the priority based on how long the task spent waiting

Obviously if it's a sales call, then you may want to swap the priority or use a LIFO queue instead, since the probability of converting a lead is higher in the first few minutes.