This blog and the Amazon Connect series has been quiet over a few weeks. It’s not because I’ve abandoned my investigation. Quite the opposite, and in fact, I’ve completed the work. My investigation was based on attempting to build a call center that was a modeled after a moderately complex real world customer of mine. Mission accomplished, and much more. There are issues, though.
In the first investigation phase, I wanted to understand what it could do using only the facilities available in the Amazon Connect dashboard. Application integration excluded (i.e. let’s leave out CRM integration), could it be used to build the real world contact centers that have been built by the usual suspects enterprise systems?
The answer is, yes it could. But… I personally wouldn’t build anything beyond a very simple small workgroup system at this time1.
Yes, it could because most of the facilities I need are there, and I’ve proven to myself they work. It doesn’t take long to get your head around the drag and drop builder, which could use some polish but does what it needs to. I haven’t pushed the kind of call volume through it that a large enterprise would yet, and this is where other call center SaaS providers have typically struggled. However, nobody does high volume elastic cloud like Amazon, and I’m not concerned.
So, what’s the issue?
The issue goes with the call flows and business operations of real world call centers. Let me illustrate by providing more (anonymous) details of my moderately complex real customer off the top of my head:
- 5 locations, 150 agents
- Their customers have a high investment and ongoing interactive relationship with them
- 8 workgroups, each with the autonomy to make their own decisions
- “High drive, high expectations” culture
- Workgroups are organized based on internal requirements. Some seemingly similar customer requests need to be directed to one of 4 departments
- Each workgroup has independent hours of operation and different holiday schedules
- Some workgroups hold “all hands” team meetings during the day
- Some workgroups take calls for others during closed times
- Four main applications are used, but there are others
- Roughly 80 inbound phone numbers. They are transitioning to a single main number, but:
- A pool of roughly 10 numbers are dynamically assigned for marketing campaigns to measure demand
- Some numbers have a legacy of more than 50 years, and will get used
- They have a number of premium service lines
- A proportion of calls need to be directed to off site affiliates on different systems, preferably with a warm handoff
- The business and programs are continually changing, driving continual IVR changes.
You’re getting a small subset of the considerations here, but you get the idea.
Building a call center system to meet their requirements is tough enough regardless of platform. Building one that can survive constant tampering by 8 highly pressured autonomous workgroups is a tall order indeed. And, taller with Amazon Connect, because:
- The function blocks provided are extremely primitive, so you’re going to use many more of them to build your function than with someone else’s system. This one would take many hundreds, and perhaps upwards of a thousand blocks. The hours of operations/holidays/team close independent schedules and call rerouting would be particularly challenging.
- There’s no “call center best practices” built in. Rather than configuration options which could be used to guide decisions, you get to wire up whatever you want however you want.
- Configuration is spread throughout the blocks, rather than in a central location. What makes it more difficult is that you have to click on and open up each block to see what’s set there. To make what should be a simple change becomes a treasure hunt.
- Error handing – a critical part of any stable call center system – is, as my university textbooks would say, “left as an exercise for the user”.
We’re now getting to the heart of one of the key reasons2 call centers continually provide poor service3. Regardless of what vendors say (and I was one), it’s not an issue of shortcomings of the technology. It’s the difficulty of mapping the technology to the business as it really runs, day in, day out. And it’s the difficulty of having the system adapt to the changes.
So, no go?
Nope. Far from it.
This post may have come out negative, but Amazon Connect’s overreach on the ease of deployment and use is shared by every call center vendor I’ve encountered. They DO address the major pain of base system setup and infrastructure maintenance, and make no mistake – it’s a MAJOR pain. The other major pain of license management is gone, and it would be refreshing to design and deploy a system where I didn’t have to provide error handling to deal with inadequate licenses.
Keep in mind that the above is limited by the facilities available in the Amazon Connect dashboard. Add in external services by taking advantage of Amazon Lambda, and let’s just say the picture is rather different. Stay tuned for the next chapter.
Oh, and when I get past this next group of posts, I’ll circle back and pass on some of the lessons I learned.
1Amazon has a history of continued enhancements, and over time, I expect that they will choose to or the prospect base will force them to address the limitations.
2The other key reason is that labor is really expensive (rough approximation – 300 agents = $10,000,000). Combine that with call center systems that measure how long an agent is on a call, without measuring whether the call actually helped the customer – well, you can see why there would be strong pressure to shorten calls to reduce labor costs.
3I have never encountered a call center that believes that they are providing poor service. They’ll acknowledge many problems, but feel that they are proving good service despite the challenges.