The video in this post shows a demo contact center system that I built. Okay. So what? It’s a contact center system. Seen it, done it, got the T-Shirt to prove it.
What if I said that it’s built using Amazon Connect, and demonstrates real world midsize enterprise functionality? A little more interesting, maybe.
What if I told you that, after figuring out what we wanted the demo to be, that the implementation of EVERYTHING IN THE DEMO took about one day. EVERYTHING, including all call flows, multilingual support AND translations, the survey, the queue behaviors, the customer authentication, the dynamic messages. EVERYTHING. And that it’s production grade.
What if I told you that there’s only about 30 Amazon Connect function blocks used?
The Path to Lightning
In my last post, I discussed my experiments building a system using only the facilities available from the Amazon Connect dashboard. For the next phase, I involved my buddy Igal and his team from Redleaf Solutions to see what we could do with a little coding.
Our experiments quickly moved from figuring out the basics to something far more useful.
Building a Contact Center
With premise based platforms, and even some SaaS platforms, initial setup can be difficult. Now, Amazon Connect has done a brilliant job of making setup trivial. But, initial setup is table stakes.
The real work in creating a contact center is configuring it to match the needs of the business. You need to design the call flows, the IVR paths, the queues, the workgroup hierarchies, the hours of operations handling. Each customer concern has to be routed to an agent that is capable of helping. Customers must be treated humanely when the conditions are less than ideal – during call floods, short staffing, shift transitions, etc. And you have to continually adapt as the business changes – and (guaranteed), it WILL change.
Straightforward with a small operation. Exponentially harder as the size of the operation increases.
The Goldilocks Problem
Until now, all center platforms have fit into two buckets. There’s the baby platform, which is easy to configure, but is too limited. You can’t build the kind of call flows nor support the workflows for anything but the simplest operations.
There’s the big boy platform, which can fill the needs of the enterprise, but gets really complex.
When the big boys first entered the market, configuration was an exercise for programmers. Flexible – yes, you could do almost anything. Simple, no. Next came “drag-and-drop” builder tools, where you tied together function blocks. This was a great step forward, but it was still programming, albeit visual programming. Unfortunately, this did not help the programmer understand all the complex subtleties of real world contact centers.
What has been missing is something in the middle, something “just right”. A platform that helps you build an enterprise center with the absolute minimum of visual programming. One with best practices built in. One that makes implementation simple without sacrificing flexibility and power.
In my work with contact centers, I came to realize that there a general workflow model that could be exploited, driven by call drivers, agent attributes and call center realities. The model was more complex than I would have liked, but it was practical. So, in customer engagements, I started to implement the model as an overlay to their existing enterprise system. It worked very well indeed. Still, I was frustrated as I was limited in what I could do by the constraints of the vendor’s platform.
After our first experiments, it became clear that Amazon Connect was the perfect vehicle to implement the workflow model and ultimately simplify call center configuration. So, we built Lightning.
Lightning is an overlay to Amazon Connect that lets you build an Amazon Connect based contact center using a table-like editor. Rather than working with function blocks, you work with and configure call center elements such as call flows, call drivers, menus and queues. With Lightning:
- Call center structures, “best practices” and standard components that support real world enterprise call centers are built in
- All configuration is moved from within the Amazon Connect blocks and wiring into a central configuration.
- The IVR structure is visible at a single glance, at the appropriate level of detail
- Hours of operation and holiday treatments are built in at various levels
- Error handling and flow tracking is inherent
In most deployments, some custom programming will still be necessary for integration to CRMs, databases and other systems, and for tailored voice applications. Lightning in no way restricts you from integrating custom flows that you create using the Amazon Connect tools. It’s extremely easy to do, and you can take advantage of Lightning facilities such as string manipulation, counters, external prompts/variables, translations, etc, to simplify and speed up your custom development.
Though I’ll be writing more about Lightning in future posts, you can find out more now here.