Designing for the Cloud – Challenge #1 – Extensibility

In our previous blog, we introduced 6 major challenges in developing a cloud contact center platform. Here, we look further at Challenge #1 – Extensibility. How do you provide a framework for this that is easy to use and mitigates the effects of misconfiguration and third-party integrations that aren’t 100% reliable?

The short answer is by putting APIs at the heart of your platform design. But not just any APIs will do.

There are 2 common, but suboptimal, approaches to APIs in the marketplace:

• In-house platform APIs
  “Here is the documentation and training resources for our comprehensive suite of APIs.”
  Sounds great, doesn’t it? Vendors in the contact center space make lots of noise about their APIs. The sad truth is, at least for established brands, that contact center platform APIs tend to be built after the fact. The APIs may be comprehensive but are unlikely to have a natural fit.

• Cloud platform APIs
  These tend to be much better because the API is the product. However, this tends to hide a lack of depth.
  Imagine you want to customise a car that you’re buying; ideally you want a factory extra or two, and bigger alloy wheels and a custom paint job. When you get to the dealership, what do you get? A powertrain attached to a rolling chassis, primed in grey.
  So with next generation cloud contact center APIs; yes, you can have what you want, but expect to have to do some serious work to get a solution in shape.

At Sytel, we take a different approach, born of our roots as an OEM provider of technology. Here are some fundamental principles that we’ve adopted when developing our API offering:

• Own the API message routing and queueing infrastructure
  Web services and URL rewrite works (mostly) but limits scale and resilience. Beware the purists who say this is how things should be. Doubly beware of vendors who push API routing responsibility to the client application.

• Develop your APIs for your own product to consume
  For example, Softdial Pathfinder™ (Sytel’s toolset for BI-based routing and agent selection) was developed in parallel with our subscriber APIs allowing third parties to interact with the routing dialog. This approach proves out APIs in real life, being adjusted and improved wherever they are used and found to be lacking. In this way, their reliability and practical usefulness can be assured.

• Assume that everything is a request, and design handling for the failure case
  For example, if a third party application subscribes to landlord-level routing of media sessions and then crashes, the platform still needs to operate to the best of its ability with sensible default behaviours.

• Mitigate the law of unintended consequences
  If you give customers the ability to interact with the core of an ACD (or ASD – Automatic Session Distributor – the multi-media equivalent of an ACD) platform, then there will be times when any business rules implemented have unintended consequences. Services that consume APIs need to mitigate these and provide the right feedback.

• Frame your APIs to suit the integration activity
  A RESTful API makes a great deal of sense for agent/supervisor web UI, but is impractical for activities such as real-time session routing; for example, imagine an outbound screening service handling 2000 screening requests per second.

For more information about how our products are designed for the cloud, just talk to us.