Time to get busy. We’ll be starting with Contact Flows, but before we do, I want to make one last comment on initial setup, which I covered in this post. This post will be on the tech side, so if you’re not IT oriented or you won’t be hands on building the IVR or Queues, see you next time…
Initial Setup Redux
Since initial setup was, well, trivial, I wanted to check what was lost by removing all the flexibility. So, I cracked open the setup and configuration manuals of a few of the premise based systems to verify what was required instead of relying on memory.
My memory was correct. In the worst case, you’re given a kit, where you have to install software and define EVERYTHING. You’re responsible for network configuration, configuring the phones, configuring ports, dealing with network security, applying licenses, getting the multiple servers to talk to each other, setting up high availability, etc, etc.
None of that here. Other SaaS offerings get rid of most of this, but Amazon has taken it to the max. Configuration truly starts at defining the IVR and queues.
What do you lose? From what I can see, weeks/months of setup, and in demand professional services. I’ll take it.
IVR, Queues and Contact Flows
You couldn’t be a contact center vendor if you didn’t come up with your own spin on things accompanied by your own terminology. Amazon Connect uses “Contact Flows” to provide the customer treatment that you do with an IVR and Queues1. If your IVR and queue needs are minimal, one contact flow could do it. But, for anything practical, you’ll be splitting your functionality into many contact flows.
A contact flow looks like this:
Playing with Blocks
Building contact flows is visual, and only visual2. You have a palette of function blocks that you drag onto the page, and you connect the outputs of one block to the inputs of other blocks. Pretty standard stuff. Now, Amazon has opted to make each block do one thing, which helps make things easy to understand. The flip side is that you need to use many more blocks than you might with other builders. In my case, I like to assign variables pretty well every step of the way, so I can capture the customer intent, and so I can quickly track down errors in my flows. This is gonna take me a lot of blocks.
Most blocks have an “error” output, to deal with those rare cases where Amazon Connect messes up. Since system errors aren’t supposed to happen, I treat most system errors with the same “Ooopsie. Please call again” message. (OK, I do use a slightly more professional message than that.)
I prefer to have a default error routine and only wire up the ones that need something different. Instead, with a line from most blocks to the same error routine, it’s rats nest time.
I was going to complain about the lack of zoom on the display. But, this appears to have magically appeared since the last time I looked. The benefits of cloud.
What ISN’T there is undo. OUCH. Likewise, you can duplicate a contact flow, but you can’t duplicate a configured block in a flow.
Controlling the Clutter
A production version of the test case I described here could easily push 1000 blocks. How do you keep that manageable?
Amazon Connect encourages you to break sections into bite size contact flows. When you leave a contact flow, you can enter another.
While this is a good start, it doesn’t go far enough. One contact flow could easily jump to 10 other flows. Trying to keep it straight in my head is impossible, and for one call, I’ll have to flip between umpteen discrete contact flows.
I would prefer to build contact flows that I can INCLUDE within other contact flows – a.k.a. “macros”. I would build major function blocks (e.g. “Initial Greeting”, “Customer Selection”, “Queues”, etc.) and wire those up. Within those macro flows, I would split the next level down into macro flows, and keep doing that until I got down to the actual contact flows. This forces a clear partitioning of function.
IVRs and Queues constantly evolve and change with time to meet changing business needs. I suspect that there will be more than a few unmaintainable IVR/Queue systems created with Amazon Connect:
- Amazon Connect will be attractive to people with AWS chops but no contact center background3
- There’s a low barrier level to getting started, and an interactive development model that encourages “ready, fire, aim”.
- You need more blocks than other IVR/queue builders for the same functionality
- No macro flows. You can’t nest contact flows into another contact flow
- You have to explicitly wire up everything
- There’s no undo, encouraging the saving of many intermediate safety versions of your contact flows.
I have some thoughts of how I can effectively work within the current constraints, but I have to keep the thinking cap on for a while longer.
1Amazon does have valid reasons for their terminology. They use contact flows for functions that are defined in a different way for other systems (like agent whisper). And, if (when) they add omnichannel functionality, this model can be extended without cracking.
2You can’t break into code within Amazon Connect. There’s no support for VXML. You CAN integrate to external services that can execute code using the built in Amazon Lambda support.
3EVERYBODY new to this space severely underestimates the complexity of contact center and makes dangerous assumptions. I did.