One thing that tends to trip up users in Amazon Connect, and directly cause issues with user experience, is having Lambda Functions that take either
- A time longer than 8 seconds to complete (leading to error path)
- Too many chained functions degrading the experience
With considerations during the design phase a lot of these can be caught and accounted for, but sometimes factors are outside of your control, such as variable time for an API to return.
Rather than leaving a variable experience that can alter based on external factors, one way of working around this is to wrap the calling functionality into an async manner so we can control the behavior, messages being played, and overall ensure that customers calling in during the worst periods and the best periods remain relatively opaque.
This is provided as a Git repo for quick reference.
Rather than replacing or requiring reworking of something that may be functional already, this seeks to place the logic for processing behind a State Machine. At its most simplistic all this does is have the State Machine run the invocation. The version as provided is essentially a drop-in replacement for a situation where, for example, you have gone through the software lifecycle, you’ve developed, you’ve tested, perhaps you’ve integration tested, but then once you hit production things aren’t as fast as expected. The Contact Flow then shows how this can be modified.
Alternately, it would be entirely possible to orchestrate more advanced logic here. For example, say you have multiple API endpoints you need to call to deliver an answer. You can do the exact same thing, creating a State Machine that progress in the background where the data is processing as required.
This is also not a toy example! This has been implemented and is running in production with some clients I have worked with. In one example, we take a customer input and then immediately start the processing, whilst Connect continues and gathers further confirmations. Another, alternate one, uses a DynamoDB as a cache table, so the State Machine populates the data, then a retrieval function can then go and get the relevant information, also meaning further information comes from the cache rather than having to be recalled repeatedly.
All the while, the customer can be interacting with an IVR, listening to music, or something else that makes the experience better than just listening to dead air, unsure if the connection is dead or not, and, ultimately, that’s what we want to deliver, a better customer experience.
