The challenges of environment, functionality and scale have required us at Sytel, not simply to extend, but rather to look to new designs.
There is an orthodox approach to development for the cloud, which in contact center terms translates to limited functionality. At Sytel we’ve spent years designing our way around this challenge! In the coming months we will discuss how we do this. First, here’s a quick summary of the key challenges to whet your appetite:
Every customer of a cloud platform brings a different set of business intelligence to bear on agent selection, routing, outbound inventory practice, reporting metrics, etc. How do you provide a framework for this that is easy to configure and mitigates the effects of misconfiguration?
Ease of provisioning
Activities such as:
- provisioning a large contact center stack
- changing carrier interconnects, dial and routing plan across a distributed telephony stack
- adding new resources to an existing stack
- adding and configuring a new tenant
…should be made simpler through the right choice of infrastructure and orchestration framework.
Ease and speed of troubleshooting
If you need to use the server console to configure and manage your contact center estate, that’s a problem. It’s easy enough to have a web-based tenant UI, but it is a different scale of challenge to provide a fully web-based landlord UI. But without this, scaling beyond 1000 agents requires costly management processes.
How much of your stack has to be deployed on dedicated computing resources? Streamed media processing is a given, as is legacy SQL storage, but everything else should be architected for elastic computing. If not, those AWS/Azure bills will ravage your profit margins.
Scale vs. complexity
Consider this dichotomy:
- In order to make software components deliver at scale the information dependencies between them must be minimised, or nothing would happen in timely fashion.
- But this then limits the ability of a platform to solve complex problems of resource allocation, such as load-balancing across ACD queues for service level adherence and blending.
Solving this problem is the holy grail of cloud contact center design.
The universal law of communications is that things go wrong. Every formal signalling protocol has this fact built into its design. But all too often, this doesn’t extend to the rest of the infrastructure that runs the contact center. So… what happens when things break?