It’s easy to get seduced into thinking you can use a basic cloud automatic call distribution (ACD) service for enterprise or other large-scale needs. After all, the cloud promises that ‘it just works’ and ‘it just scales.’
Signing up for such a service and commissioning queues is easy; give the queue a name, map a Direct Dialing Inward (DDI) or two, assign agent memberships/skills, and job done.
But peer a little closer, and you’ll begin to see challenges:
- Will the cloud ACD manage service level agreements (SLAs) across all of your workloads?
- Are there blending rules for withdrawing agents from outbound to meet inbound demand?
- Are there behavior rules for multisession agents?
Chances are unless you’re using an enterprise ACD dressed up as a cloud offer (which isn’t a good idea), you won’t find any of these functions. But why?
It comes down to virtually all cloud ACDs having a stateless design (this being, until now, the Holy Grail of cloud services). The uncomfortable truth is that to support enterprise ACD functionality the cloud design must be stateful. Let’s decompose the traditional Enterprise ACD to see why:
Design Challenges
There are at least 5 layers of work required, and they increase in complexity:
i. The queue mechanism
It doesn’t take too much effort to make a basic queueing system for calls. Making this queueing system stateless would involve some persistent storage of references to calls in queue and the means to query whether agents with the right skill are available.
But there’s a cost to this design; every time the queue needs to decide on connecting calls to agents, it has to gather state information (calls in queue, available agents, and skill levels) and render a decision.
This process might take several tens of milliseconds each time if you use a state caching engine. For a simple use case, the volume won’t be a problem.
ii. Queue interdependence
Next, consider that agents will have the skills to serve many queues. In our clean cloud model, queues are independent of each other. But in real life, action taken in one will remove agents from the available agent pool for another.
The queueing system must now make decisions in serial fashion across all queues. In a larger-scale contact center, that ‘few tens of milliseconds’ now become a problem.
iii. SLA for each queue
All queues must be managed for SLA, which means the order in which queues get to pair calls with agents has to be adjusted to keep to the SLA target. In a stateless model, this would mean a ‘queue manager’ polling a current snapshot of the state several times a second.
And here’s where the stateless model becomes unviable. Blending requires real-time monitoring of inbound demand, agent skills, and existing requests to push and pull between inbound and outbound workloads.
An agent may perform chat across multiple sessions in real-time, and these sessions interact. The agent may or may not handle voice as well, and again there are interactions across sessions.
This design complexity is necessary to deliver an
ACD that automates decisions and makes the service simple for the subscriber to consume. If you have 1000 agents handling calls, the ACD makes up to 5000 state-driven processing decisions every second.
So how do you make an enterprise ACD that works as a cloud service?
Designing for Success
The short answer is that you must have a stateful ACD engine to accomplish everything you need. Forget our afore-mentioned Holy Grail.
Developing and delivering this as a cloud service requires discipline. The ACD engine must be made as small as possible (i.e., an ACD instance per tenant) and a survivable landlord architecture.
Other basic design requirements are:
i. Services must do ‘just one job.’ Because the ‘one job’ of an ACD is pretty complex, anything outside of the business of ACD decisions (and communicating those decisions) doesn’t belong in the ACD.
ii. Application programming interfaces (
APIs) must be failure friendly. Because of the first requirement above, the ACD is a process that consumes state and delivers decisions on state via a published protocol (API). That means everything is a request, not a command.
iii. Protocols and routing mechanisms must be designed for multiplexing and service discovery. An application shouldn’t have to know or care where the things it talks to are or how many of them there are. The framework the application uses should hide this away.
So, what price is a fully functional ACD in the cloud? Some challenges ahead for the vendors wedded to stateless. Otherwise, to see a fully functioning Enterprise ACD in the cloud,
get in touch.
