Softdial Contact Center™ (SCC) provides unique functionality for partners and customers, yet what makes it unique in the industry is how we have stood by our vision.
The vision behind SCC
Whenever people ask what is unique about a product, they are presented with sweeping statements such as “Our product does XYZ which others don’t do, or don’t do as well as we do”.
Yet a full understanding of what partners and customers gain by working with SCC requires a deeper level of engagement with the vision, rather than just looking at the benefits.
Truly successful products in the marketplace, in whatever form, have survival value that is beyond what the product actually does.
Take the iPhone for example. There are, and have been, many equally function-rich and arguably ‘better’ smartphones released during the course of the history of smartphones. The iPhone wins and continues to win because of three things:
- Everything in the ecosystem is logically consistent and cohesive
- Default behaviours are carefully researched to avoid users having to configure stuff
- Anything that gets added is made to fit the design and operating principles.
Similarly, the vision behind SCC comprises five primary principles:
- Proper automation
- Future-proofing
- Ease of integration into a customer’s business
- Ability to extend
- Longevity.
While SCC has plenty of unique functionality for partners and customers, its most compelling advantages, unique in the industry, are due largely to how we have implemented this vision.
In the beginning
The fundamental principle behind the ACD model in SCC is to automate everything that can be automated.
This started back in 1997 with our predictive dialer engine. Anybody who worked with other predictive dialers in the ‘90s would know that there was nothing really predictive about them. We encountered resistance in the early days from dialer managers, whose job it was to monitor and tweak the dialer. This, to us, was nonsense. A human cannot analyse, make conclusions and react quickly enough to make sure agents are kept busy or avoid spikes in abandoned calls.
We overcame this resistance because a few early adopters bought in to the idea and Sytel gained a reputation as the smart young upstarts disrupting the dialer industry.
As the business grew, we stuck to this principle.
An intelligent machine given the right data and rules can solve problems a whole lot more effectively than a human being.
A full-featured cloud contact center solution
SCC has expanded considerably since then. The platform today is a fully-fledged multimedia and multisession ACD, with powerful scripting, data management and reporting tools. Everything that can be automated about the real-time operation of the platform, is automated. For example:
- Agents are automatically redeployed to work different projects to meet changing demand (assuming they have the skills and subject to rules on how the business operates).
- Blending works across the whole of the estate. This means that as long as you have enough resource, the system will automatically make sure service levels are met, and deploy agents to outreach and other work during periods of lower inbound demand.
- In cases of extremes of load, queue behaviours adapt automatically, for example offering callbacks if average customer wait is likely to be unacceptable.
SCC automatically…
- makes best use of agent time
- keeps customer wait times as low as possible
- gives customers a choice when wait times are longer
A strong foundation in design
Throughout, we have stuck to a number of design principles:
- An ACD/ dialer should monitor and react in real-time to deploy resources in the most efficient way possible. If a supervisor has to tweak settings and/or redeploy resources to get best performance then the design is wrong.
SCC automatically achieves the best possible use of agents’ and supervisors’ time
- SCC captures and manages everything in the system. The system should view an IVR bot and a human agent in the same way. An agent is an agent, whether this is a human agent in the call center or remote, a chatbot, an IVR bot, or an external party. All agents have consistent behaviours and capabilities. The same is true of media. It doesn’t matter whether the media is voice, video, chat, email. The system should route, queue and handle media of all types consistently. Having everything appear to be the same to the ACD enables management of multi-dimensional problems, like queue load-balancing, blending, skills matching in real-time.
Real-time management of resources guarantees the best possible performance in the contact center given constantly changing conditions.
- Design for clean separation of concerns. An example of this is the data management component, Softdial Campaign Manager™. It acts as the single point of contact with the customer’s line-of-business data, and offers up APIs to other services to allow retrieval and controlled update. This allows database communication to be optimised to maximise throughput and means you only have one application that has to be concerned with data integrity and rollforward recovery on failover.
A single point of contact minimises contention and maximises efficiency.
- Design for multiplexing. To do this for a real-time system with complex interactions is not straightforward. Some necessary contact center behaviours are stateful by definition. Only by developing an API ecosystem that facilitates multiplexing along the fault-lines that are natural to a large-scale contact center can you have a solution that works as well for 10 users as 10,000.
SCC is designed for maximum scalability with no degradation
The DNA of SCC
SCC as an organised ACD API ecosystem has been in existence since 2001. No other manufacturer has achieved this level of longevity of core product. We have managed to retain our DNA through continuous improvement and sticking to design principles that work.
The DNA of SCC is the core API which is designed with the following factors in mind:
- Everything in the world of communications is a request which may succeed or fail, and will succeed or fail in a timescale that the user does not control
- Consumers of the API may be clients handling individual resources or servers delivering aggregate behaviour
- API messages are as small as practically possible
- Core applications are able to process API messages without blocking, providing throughput and scale.
The work done in SCC V11 extends this design to address:
- Multiplexing of core services to deliver linear scale for cloud (for all practical purposes)
- Comprehensive handling of resource failure so that the software suite becomes self-healing.
The APIs
The APIs were originally designed for third parties to be able to model complex interactions necessary when writing line-of-business services but limiting application complexity.
A good example of this is the CTI server. This only needs to concern itself with media session lifetime and taking instruction from the controller for actions on the media session. It does not need to be aware of constructs like queues and campaigns.
The various interfaces that the core API exposes provide clear separation of concerns.
Originally these APIs were used by third parties. We used these APIs internally to develop the suite of services we now know as SCC.
Line-of-business services that do one main job can be built relatively quickly, robustly and be capable of multiplexing to deliver scale.
So we have a contact center API ecosystem and a suite of applications that deliver a functionally rich and flexible contact center stack.
How does it get deployed?
The deployment model
The SCC platform deployment model is based on long experience of delivering contact center technology at scale in partnership with service providers and larger end customers.
Key to this is provider-agnostic orchestration. SCC has its own service orchestration infrastructure. This allows deployment of services directly to a guest OS without the need for a container. Containers solve problems of poor service design and come with 2 costs:
- Provider lock-in – Use a particular cloud provider’s container infrastructure and you’ll be stuck with that provider unless you do some costly re-engineering
- Lack of efficiency – Containers are another level of indirection in a virtualisation infrastructure. They are less efficient than deployment directly to the OS for anything at scale, and more costly in terms of subscriber costs coming from your cloud service provider.
SCC service orchestration…
- allows flexibility of service provider without major work
- provides efficiency at scale
- minimises service cost
With SCC a service provider or customer stands up a series of standardised VMs pre-configured with SCC’s orchestration bootstrapper. From there, deployments are managed via a landlord Web UI so that, for example, adding a new tenant to the platform takes minutes, not hours and days. It also means activities like expanding a media cluster to add capacity can be done on demand during live operation, as can activities like reconfiguring all your SBCs to work with a new carrier.
Deployment is rapid, and standard tasks are quick and easy
SCC gives users the flexibility and control of an in-house platform, but delivered as cloud infrastructure.
