Dialogflow’s Phone Gateway integration provides a telephone interface for a Dialogflow agent. I had built many chatbots with Dialogflow but was unaware of its integration limits. I was aware that Dialogflow was not a robust call center solution like CallJoy, and there would be some functions Dialogflow could not do.
As a starting point I knew there would be at least 10 flows to explore. I would also explore multiple integrations with Dialogflow to create an IVR with the ability to text customers.
Before diving into the Dialogflow, I reviewed the existing 10 intent pathways for clarity, concision, and relevance to the customer’s goals. I mapped the utterances to visualize the experience and created a system to communicate dialogue revisions to the client as we advanced. I observed the following areas to explore further:
- Implicit vs. explicit confirmations
- Editing particularly long responses
- Dialogflow phone gateway’s capabilities compared to CallJoy’s
I also used existing dialogue as a base and kept the end-user profiles in mind as I enhanced the chatbot persona.
The bot persona helped with the voice and tone of the agent. Above is a summarized representation.
Miro boards were created to communicate with the product owner, visualize flows, make edits and encourage collaboration.
The agent’s original utterances tended to be casually verbose or ask multiple questions in one turn. The longest original prompt took 59 seconds for the text-to-speech to utter. These prompts then led customers to receive an SMS text that may not solve their issue or contact the business by email.
I tested the dialogue by sitting back-to-back with a participant reading the flows, and recording the interaction to detect and review problem areas.
The current flows did not take advantage of turn-taking, infrequently asked for confirmations that allow end-users to make mistakes or change course. Unlike a live agent, this virtual agent wasn’t able to manage any interruptions whatsoever. Making it even more important to have pointed prompts.
How I attempted to alleviate these pain points:
- Eliminated words that did not move the conversation forward
- Added smaller digestible chunks
- Reserved verbose phrases for follow ups or misrecognition
- Gave example phrases to guide users to phrases the bot can understand
- Broke up any prompts that grouped more than one question at a time
Interaction exchange gives the customer acknowledgment of their problem and perceived control to the correct solution. In a human conversation, this acknowledgment and contextual escalation create the momentum needed to arrive at a solution.
The original prompt did not chunk the content. As a result, the user was asked three questions in one turn and was forced to remember a lot of information, significantly increasing the chances of a drop-off.
Brevity, manner, and failure to pass the one-breath test were challenges in the original dialogue. The customer's emotional state, the time needed to write down an email, and feel valued must all be considered in the dialogue above.
Because DialogFlow and CallJoy are products with unique audiences, it was inevitable there would be feature tradeoffs. Texting customers was one of CallJoy’s main features. After exploring SMS APIs such as Twillio, I knew adding a code-heavy service exceeded the project scope. I focused on what I could do in Dialogflow. This approach required that SMS texts were changed into handoffs to specific routing numbers for particular intents.
Highlighted above, DialogFlow without significant API integrations was not a substitute for CallJoy.
Without visual cues such as nods, facial expressions, and eye contact, words hold even more weight. I was given a thorough list of training phrases, but the NLU wouldn’t always get it right when testing. I had to add multiple training phrases so that the NLU would understand. A swap of a pager and trade were not the same. One was an exchange, and the other meant to buy a new one.
