Once a Call Flow, Now a Workflow
The traditional call flow concept doesn't do justice to the modern customer experience.
Whenever you go through a period of transition, it's a very definite closing of a certain chapter of your life. Those times are always going to be both very upsetting and also very exciting because things are changing and you don't know what's going to happen. -- Daniel Radcliffe
As a computer scientist who once designed and wrote software for automatic call distribution (ACD) systems, I've long been dealing with call flow -- a concept that's persisted even as ACDs evolved into call centers and call centers into contact centers. It's about time for a rethink.
A call flow begins when the customer dials into the contact center and ends when that call is released. Along the way, the caller goes through a number of intermediate steps, like listening to a recorded announcement, working through the interactive voice response prompts, speaking with an agent, and transferring to a second agent. The point is that call flow describes just that -- a voice session and all the audio-related points it touches during its relatively short lifetime.
Of course, the modern world doesn't quite work that way.
Chances are high that before we call XYZ Company, we've spent a good amount of time perusing its website. Perhaps we've already put a few items into our shopping carts and aren't sure if we are ready to enter our credit card information and click the "buy" button. And perhaps, even if we've already gotten our initial questions answered and we've received a 20% off coupon code as an incentive to complete our purchase, we may find that we require further help and so we hop back on the phone. Better yet, our second conversation might be a webchat with a completely different agent. Referring to all this as a call flow stretches the definition well beyond the point of breaking.
All of this leads me to the notion of a communications workflow. Where a call flow is bound by picking up and ultimately cradling a telephone receiver, so to speak, a workflow can extend across multiple touchpoints and span a much longer time frame. While this makes modeling and tracking a workflow significantly more complicated, it more accurately captures the true nature of a customer/business interaction. As my example above demonstrates, a workflow might begin on a webpage and not truly be complete until the last webchat.
In addition to communications methodologies with human interaction, a workflow can be started, ended, and driven by non-human, external stimuli -- think Internet of Things (IoT). For instance, an emergency management communications workflow might begin when a pressure gauge registers a value beyond a configured threshold and end with an "all clear" email.
A traffic management communications workflow might begin when a traffic light fails, and then automatically sends a text message indicating the failure to nearby repair personnel and to the local law enforcement agency so it can prepare for backups or accidents. It continues by tracking any phone calls to the parts depot. It finally ends when the traffic light goes back online and the technician registers a closure event. While one could easily divide these steps into a number of separate subtasks, a workflow allows an organization to encompass them all into a single actionable and measurable package.
Let's take this even further. More and more organizations are adopting cloud and hybrid cloud solutions for both their communications and backend processing systems. Workflows live in these spaces, too. In fact, there is nothing to say that a workflow could not seamlessly move from the cloud, to the premises, and back to the cloud. Regardless of a true cloud integration, isn't that pretty much what happens when a workflow begins on a webpage and ends with an SMS text two days later?
Want more? Think healthcare. Think supply chain management. Think financial services. Think about practically anything that involves people, products, services, etc. There are millions of potential communications workflows just waiting to be sketched out.
As I have previously written on No Jitter, I have been working extensively with Avaya's Breeze development tools (read related article, "My Life as an Avaya Breeze Boot Camp Recruit"). I began by writing Java code, but for the past week or so, I've been using Avaya Engagement Designer, a drag-and-drop user interface for Breeze. In either case, I've been pushing the boundaries and trying my best to wrap my head around creating true workflows. Yes, some of these workflows are quite simple and stick within the boundaries of telephone calls, but more and more are becoming multimodal with persistence between discreet communications events.
By supercharging my Breeze applications with Web services to cloud-based solutions, I am working toward workflows that extend far beyond telephones, touch tones, and call processing servers. In fact, I am currently designing a workflow that begins with a nasty tweet and ends with a customer satisfaction survey. Tell me that that isn't the coolest thing you've ever heard of!
This is not to say that Breeze is the only game in town. Other vendors are integrating or looking to integrate similar technology into their products.
I could go on and on with examples that you might consider fairly trivial as well as highly sophisticated workflows that could potentially exist for days, but I think you get the idea.
Call flows deal with dial tone, talk paths, and tightly bound timeframes. Workflows deal with how we really interact with businesses, how businesses interact with us, and how the world (again, think IoT) interacts with the world. Workflows mimic how we live and not the particular box a business wants to put us in.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.