All fair questions Paul. This one is going to be long, ill try my best to keep it succinct.
Conditional RoutingEWT was the first measure (other measures may be added later (
@Chris Bohlin to comment). The reason for EWT being chosen is that in our research the conditions people typically wanted to roll with were around wait times, another similar one was 'agent count'
Basic Example
- Group 1 for 60 Seconds
- Group 2 for >60 Seconds
The traditional method is to wait for the wait time to expire and then route the customer to the next group. After analyzing real world scenarios around interactions the reality is that the customer was made to wait longer then required in an unnecessary way when the outcome to include groups 2, 3 or 4 could have been decided from the start with EWT. Through using EWT we can optimize our customers voice minute spend, queue less and get the customer to a location that can actually help them quicker and reduce overall burden.
The use of EWT can be seen as a way to skip ring rules, for example. If everyone is in group 1 occupied and the EWT is 10mins, then groups 2, 3, 4 have to come into view (if 10mins is unacceptable).
For those following along, EWT is the projection/forecast of the the customer wait time.
Challenges with EWT.
For a detailed breakdown of how EWT works read here:
https://developer.genesys.cloud/routing/routing/estimatedwaittime-v2As your rightly point out, widely inconsistent AHT and low volume are trouble for EWT, a lot of our EWT improvements are around addressing this particular issue but there is also a break point where mathematically we run out of options. In cases with widely inconsistent AHT at scale questions are then raised if there is more then one call type occurring in this particular queue.
Detailing Issues with WFM and Bullseye.
The core of the problem is that in
certain configurations of bullseye especially when stripping skills, ring 2 and beyond can be
other planning groups.
In a nutshell we identified the location for the customer to be routed too, have a real time problem making that request complete (lack of resource, higher then projected volume) - ultimately a failure in resource availability.
If the skills are kept whole and never change. Nothing is a problem.
If the skills are stripped to find a larger body of agents. Now we are needing a new forecast and staffing model for that overflow.
The reality is the overflow cannot be modelled with a high success of accuracy. Its real time, in moment and event driven. (see complex workarounds final paragraph for views on this)
Alternatives to a lack of Resource AvailabilityDepending on your particular customer intent and customer and organization profile, legal mandates, organization KPIs and other preferences how you respond to that lack of resource problem in real time has multiple options.
- Find more people - expand the target surface
- Through bullseye with or without skills stripping
- Through best skills matching
- Through conditional group routing (new)
- Block the Interaction from occurring
- Callback is a option
- Move to another channel - offer webmessaging/sms?
- Play an IVR message to try another time (not recommended)
- Accept the Queue and wait time for what it is and potential abandonment to follow
- Follow up on abandons through an outbound dialing list (if you require)
You summarized it perfectly. Something has to give.
The choice's made may or may not impact your interaction outcome but this is very situational and environmental. Questions like; Do you queue frequently? or only at random times? Depending on the frequency of this event it may be a root cause staffing issues (not enough, not trained etc), or a temporary localized issue (weather event created a spike).
What we see in larger organizations is that there is 'lend/borrow' occurring. Interaction Type A is more important then Interaction Type B, when we lack the resources its Type B that suffers. This is where items like priority make their way into the conversation as well. Typically to date its the smaller volume queues or specialist teams who come and help where the volume is, however that smaller volume or specialist teams also need to be available incase something does come up.
Complex Workarounds
We are aware in certain environments the complexity exists. Conditional Routing goes to solving some of that complexity while retaining the ability to execute WFM capabilities accurately.
I can and have seen environments where there is simply not enough resourcing as a mainstay of the operating model, the other more common element is that the lack of resourcing is driven by some very aggressive service level goals where there isn't enough resourcing available to service it.
Myself personally; after 20 years (6 of them as a customer of Genesys, and 8 years in the field and now 6 years leading a product area). The complex routing rules are usually in place to gloss over some other challenges in and around the environment. The biggest one is typically a routing environment trying to force a service level outcome for which the resources cannot provide - which ultimately is not for routing to resolve - its a operational and business issue around staffing, performance and overall capacity.
How bad can Bullseye and WFM be together?
If you strip skills in your bullseye decisioning, WFM loses sight of the work/labor and outcome - you may have even moved the interaction from one WFM planning group to another impacting staffing plans across a larger surface area.
Genesys Cloud WFM can handle the resource sharing calculations across 1:many agents with 1:many allocations to interaction types. We can represent the true load across individual and whole groups of people to show you what will occur. At a basic level 1 agent may work 3 interactions, they are not however 33% of their time to those 3 interactions, the size of the volume and the AHT of each interaction type dictates how much of their time is allocated to each segment.
In summary
If the employee can do the work then they should be included in scheduling/net staffing for WFM. WFM can handle agents working on many things easily, its also part of the reason why we build the Business Units and Management Units Staffing as a single entity.. that load allocation is occurring in that process.
On the routing side you have options how it gets distributed real time.
- Bullseye works fine if you do not strip skills.
- Best Skills Matching does this on a tiered allocation via skills proficiency, without the timers between decisions to tier down.
- Conditional Group Routing allows organizations to put conditions in place before the tiering occurs and forces skills compliance to be one and the same which is effectively giving you the same outcome as bullseye but with complete WFM support.
In all 3 cases you are keeping the target location of the customer in the same spot. You are surfacing more people but collectively they still belong to the same planning group.
Hope that helps.
Cheers
------------------------------
Cameron Smith
VP, Product Management - Workforce Engagement Management
------------------------------
Original Message:
Sent: 09-08-2022 17:37
From: Paul Simpson
Subject: looking for in queue flows that imitate bullseye
Thank you for that clarification!
Could you provide more information about "Conditional Routing"? From what I can see, this only makes use of EWT and, unless I am very much mistaken, it's simply a case of looking at the EWT prior to putting the call in queue and making a decision based on some thresholds? (Whether that be reduced skills or a different queue when EWT is high).
The problem with this is that EWT becomes inaccurate when you have a high variability in call lengths and / or few agents. In some cases we have both.
I am aware of the way "Best Skills Matching" works, and will result in the call being answered as quickly as possible, but it does not allow for the idea that it may be preferable to actually wait in queue for a (short) time to see if a better agent becomes available.
Bullseye, in it's various forms, provides this functionality.
Now, you mention WFM and only scheduling Ring 1. Is that the only issue? Or are there other problems behind the scenes?
The reason I ask is that WFM, like a lot of components, is making predictions, educated guesses, as to what will happen. It can never be 100% accurate. If there is a sudden unexpected rise in call volume, there may well not be enough agents on queue to maintain SLAs (this is true without Bullseye.) In this situation, what should we do? Something has to give. Should we not meet our SLA? It may well be that the business decides to sacrifice a different business line, maybe who are not normally customer-facing, to deal with the rush. Bullseye allows this to happen "in the moment", whilst keeping the interactions in the same queue. So you may have Sales calls that have been waiting for over a minute being offered first to Customer Services agents, then after another minute to Finance agents, and so on. Something has to suffer, and we don't want it to be sales calls (In this example.)
You may not be aware, but the Genesys advice of "Bullseye does not work with WFM" is leading to a lot of customers creating some very complicated work-arounds that may, in fact, be even worse. Preferred Agent Routing is one solution. Another is multiple queues and moving calls as they age.
What I (and many others) are trying to ascertain, is how bad "does not work" actually is. If I have a queue with 100 agents, 50 each in rings 1 and 2, and I use WFM, I would hope that under normal circumstances agents from Ring 1 are scheduled and get the calls and deal with them. Sure Agents in Ring 2 have other work to do (perhaps being scheduled for other queues, or perhaps doing "back office" tasks) but if there is an unexpected (by WFM's predictions) rise in call volume, they will get utilized (albeit with a different business area potentially suffering.) If that is, in fact, how it works, then we can live with it. If there are other hidden issues, we need to understand them in order to make a determination as to whether the risk is worthwhile.
With respect, "Bullseye doesn't work with WFM" is too broad a statement and filled with hundreds of potential nuances!
------------------------------
Paul Simpson
Sr. Cloud Partner
AAA Club Alliance Inc.
Original Message:
Sent: 09-08-2022 17:12
From: Cameron Smith
Subject: looking for in queue flows that imitate bullseye
Sure can, we can even do one better. @Dana Eckoff's use case is a coming feature, its currently in beta and coming soon.
https://help.mypurecloud.com/articles/conditional-group-routing-overview/
@Paul Simpson, you are correct. Ring 1 is the only planning group taken into account. Where bullseye gets rough for WFM is Ring 2 could be a completely separate planning group, where the overflow volume that hits ring 2 isn't forecasted or staffed for. so forth for further rings.
Conditional Routing is built to solve for that exact purpose. We have a hierarchy of distribution where on condition = true we want something to occur. If you dont care for the time between choices then standard ACD Routing and Best Skills matching is appropriate
------------------------------
Cameron Smith
VP, Product Management - Workforce Engagement Management
Original Message:
Sent: 09-08-2022 16:32
From: George Ganahl
Subject: looking for in queue flows that imitate bullseye
@Cameron Smith can you jump in and correct my errors above, please? And expound upon the best practice a bit?
------------------------------
George Ganahl GCP (Genesys Cloud), ICCE
Principal PS Consultant
Genesys
Original Message:
Sent: 09-08-2022 16:18
From: Paul Simpson
Subject: looking for in queue flows that imitate bullseye
George,
Interesting. This is different from what I was previously told, which was that in scenario 1, WFM only considered agents in the center ring (Ring 1) when determining who was a member of the queue, and therefore who should be scheduled for the predicted volume. This would make sense, and be the desired behavior, for reasons previously stated.
------------------------------
Paul Simpson
Sr. Cloud Partner
AAA Club Alliance Inc.
Original Message:
Sent: 09-08-2022 13:52
From: George Ganahl
Subject: looking for in queue flows that imitate bullseye
In a nutshell, WFM (Genesys Cloud, NICE, whatever) looks at the total number of agents assigned as members of a queue when it is doing forecasting. It also (if capable) looks at the skills required by an interaction when it first routes to a queue.
Bullseye causes problems in both scenarios listed (as does Preferred Agent Routing).
1. If just assigning agents to rings, and you expand the pool of agents with each ring, it throws off WFM's attempt to forecast and schedule to achieve a particular Service Level, since the WFM engine thinks that all agents assigned to the queue will be considered for routing at all times, rather than a small pool, then more, and then more as time goes on.
2. If you strip skills with Bullseye, then you are again foiling the WFM calculation that just "sees" the initial skills used to route the interaction. WFM doesn't know that the final set of skills were what was actually used for routing, which again throws off forecasting and scheduling.
Folks who are knowledgeable in the "art and science" of WFM manually adjust the forecasts (which you can do in Genesys Cloud) to get closer to what actually happens...but that's why Bullseye and PAR are not "supported" with WFM. The adjustments are intuitive rather than objective, and cannot be automatically done by the system.
Also note that Genesys is now wanting to move folks toward Predictive Routing as the best way to improve CX by getting the right conversation to the right person as quickly as possible.
------------------------------
George Ganahl GCP (Genesys Cloud), ICCE
Principal PS Consultant
Genesys
Original Message:
Sent: 09-08-2022 10:51
From: Ricky Necor
Subject: looking for in queue flows that imitate bullseye
Good point! We are also deploying Bullseye with agents assigned to rings. We've asked that question as well as to how this will impact WFM since we aren't removing skills but don't seem to get some good answers on this even from WFM resources in Genesys. Anyone who may have this already deployed along with WFM, please share!
------------------------------
Ricky Necor
CNU Online Holdings, LLC
Original Message:
Sent: 09-08-2022 10:28
From: Paul Simpson
Subject: looking for in queue flows that imitate bullseye
OK, so first up, I see a lot of people talking about removing / stripping skills as the call ages, but I should point out that this isn't the only way to configure Bullseye.
You can configure it with agents assigned to rings. I don't know is all the concerns with Bullseye / WFM apply in both situations, or only when using skills. My understanding is that WFM struggles when Skills get changed as it is changing the call's actual requirements. Expanding the agent pool (with assigning agents to rings) shouldn't suffer from this issue, surely?
I'm also interested to see the comments regarding Preferred Agent routing having the same problem? Can anyone expand on this? Currently, what we are doing is to set the preferred agents based on a skill proficiency, but if what I'm reading this may have exactly the same problem?
TIA
------------------------------
Paul Simpson
Sr. Cloud Partner
AAA Club Alliance Inc.
Original Message:
Sent: 03-20-2019 19:35
From: Dana Eckoff
Subject: looking for in queue flows that imitate bullseye
Hi all - I want to use bullseye routing but don't want to loose workforce management so I'd like to imitate bullseye using in queue flows. I imagine someone must have done this before so I'm looking for suggestions or ideally an exported flow I can view. I'm happy to share back whatever solution I come up with
#Routing(ACD/IVR)
------------------------------
Dana Eckoff
Mosaic (joinmosaic.com)
------------------------------