DRB Customs is a tiling and flooring company in Maine. Made of a small team of contractors, they had several issues that they were facing:
Tyler helps DRB Customs mainly by:
The DRB chatbot project began as a side-project when the owner of DRB Customs, Denny, asked me to clean up the native chat automation on Facebook messenger. I added responses to frequently asked questions, but I realized that the potential for automation could be far greater than a simple FAQ script.
This project is personal to me because it was my first conversation design project. I started with a basic corpus and constantly updated my flows as I learned more about the field and better understood best-practices for crafting a smooth and compelling user experience.
I refocused the conversation and identified several key user intents after user-testing and running back-to-back sample dialogue sessions in person (short conversations between two humans emulating what it would be like for a typical user to talk to the chatbot). These key flows were:
I also added in a small-talk section as an additional flow, for users who just wanted to say "Hi" to the chatbot.
A vast majority of users who talk to Tyler are clients who live in Maine, so I shaped his persona to be familiar to those from Maine. He has a professional but friendly way of speaking, and will often use Maine slang (such as wicked as a positive adjective). The goal was to emulate contractors who speak to their clients: professional, but somewhat casual and approachable. You can see more details on the bot persona worksheet above (original sheet from the Conversation Design Institute).
After sample dialogue testing and identifying my key intents/bot persona, I created a quick high-level flowchart on Miro and then rapidly deployed a prototype on Voiceflow.
Using Voiceflow was convenient for prototyping because it is a quick and easy no-code tool for building chatbots and has a test function that you can send to potential testers. This was invaluable in getting feedback and tweaking Tyler's happy flows (the best case scenario paths).
I then used Miro to create a more in-depth flowchart, implementing lessons learned from my prototype. Finally, I used Google Dialogflow to implement my conversation. Although Dialogflow isn't as simple as no-code tools like Voiceflow or Manychat, I appreciate the control it offers over context management and back-end integrations.
Tyler's key functionality involves sending the user a checklist of crucial information to know before starting a job. Tyler also emails a human agent at the company with relevant data scraped throughout the conversation through Dialogflow parameters filling (email, name, project details).
I accomplished this using the Google cloud functions inline editor for Dialogflow fulfillment. Using node.js, I integrated Dialogflow with the Sendgrid Web API and mapped email sending functions to the intents where I needed Tyler to send an email.
When a relevant intent is triggered, Tyler will now trigger the Sendgrid API and send an email to the user. The email is automatically populated with the relevant parameters (email, name).
A curious design consideration was that I had to have Tyler's emails sent a mailfence email account; many mail domains have started using DMARC (Domain-based Message Authentication, Reporting & Conformance). Simply put, emails sent via a third party from an email service using DMARC to another (eg. gmail to gmail) would fail to deliver. This was uncovered in user testing. Although DMARC has been successful in increasing email security, this meant that I had to create a different email account to send my Tyler emails with.
A critical part of Conversation Design is ensuring a smooth user experience, especially when users stray from a happy path.
I implemented a 3-stage error handling process for every single intent in my corpus. This was critical because some of my flows are narrow and deep, meaning that they are specific, long, multi-step processes, as opposed to an FAQ-style flow (especially the estimate flow, which requires many confirmation back-and-forth interactions).
Narrow and deep flows need a robust error handling system because it creates a very negative user experience if a user makes an error and veers 'off the track.' A generic fallback intent will not work because the bot needs to remember exactly where the user was in the conversation: otherwise, a user would have to re-do an entire flow if a single mistake is made.
To solve this, I created three custom fallback intents for each intent. Each intent 'remembers' the input and output contexts of the original intent, so the user never veers 'off track.' The first fallback intent is a simple rapid reprompt. If another error occurs, escalating detail is provided with more information and instructions on how to proceed. Finally, should a third error occur Tyler will redirect the user to speak to a real person.
Additionally, I rounded out the conversation with floating intents: questions the user may ask that aren't part of any flow (for instance, 'do you do plumbing work?' or 'how long have you been in the business?')
Throughout the conversation I also added three general types of duplicate intents:
Tyler was a challenging long-term project, especially for a one-man team, but I really liked how he turned out. I feel like my design improved over time, and I do think that there is a lot of value in iterative design in this field. It is important to test, re-test, and update. Through employing Conversation Design best-practices I know that the overall experience for the end-user is one that is natural and helpful.
With professional experience spanning three countries, I have confidence in my ability to adapt to any situation. As a life-long learner, I always strive to equip myself with new skills and knowledge to tackle whatever challenge may come.
