Two First-Time Chatbot Builds. Two Developer Tales.
Behind every chatbot deployment is a developer with a tale to tell. No matter how slick the finished product, it’s unlikely that the journey to get it there was quite so smooth.
So, with that in mind, I spoke to two of our developers at Parker Software to get the scoop on their first-time bot builds.
Meet Jamie Mascall and Paul Johnson. Both are great developers, both were tasked with different projects, and both have different bot experiences and outlooks on the future. Here are their stories.
Q: What were your goals from the outset?
Jamie Mascall:
“Our sales team needed a customer-facing chatbot prototype that could simulate standard conversations between operator and visitor. For this project, the goal was fairly straightforward.
I wasn’t tasked with creating an AI driven conversationalist chatbot, but rather an efficient triaging system that could handle routine tasks and queries. The chatbot was based on the standard queries we get through our company website, and intended to demonstrate to any new potential customers the utility of introducing bot technology in a service context.
So, the purpose of the chatbot was to alleviate human agents, make the sales process easier, and to automate repetitive chats. Since it was a prototype only, it didn’t need to be as finely-tuned as a live chatbot deployment, and could be narrow in scope.”
Paul Johnson:
“A customer wanted a Facebook bot that could pick up missed web chats via their company Messenger account, and answer those formerly lost questions through our API. They were losing opportunities outside of office hours, and wanted to re-route enquiries to another channel with real-time responses.
So, I was tasked with building an API to connect web chats with Messenger, and a company Messenger bot that could answer FAQ. The goal was simply to avoid missing chats, and to extend the company’s availability outside of office hours through bot interaction.”
Q: What process did you use to build the chatbot?
Jamie Mascall:
“Even though this was my first chatbot build, my experience of working on enterprise live chat software — especially on call centre features such as automated canned responses — meant I had a good understanding of the processes I’d need to use.
I knew I wouldn’t need to incorporate any machine learning or sentiment elements, and could focus on more standard criterion such as identifying keywords, mapping out conversational flows and adding context to content.
I built the chatbot in Node.js, and used Microsoft’s Bot Framework to avoid reinventing the wheel. The trickiest part was building a connector for the framework to the WhosOn server (our existing live chat solution.)
In all, the chatbot took 3 days to complete, and isn’t as difficult a process as many people assume — particularly with the resources available online.”
Paul Johnson:
“I first identified customer requirements and the areas they’d like to cover. I then spent a couple of days creating a proof of concept to demo to the customer.
I built the bot from scratch in Node.js. I prefer DIY when it comes to coding. I find that learning by doing is best, particularly when I’m building something I’ve never built before.
Even though I’d not programmed chatbot technology before, I’ve been working as a live chat software developer for several years. This made adapting to bots quite a natural course. I could use similar processes to a standard chat deployment in terms of monitoring keywords, creating triggers and returning the correct response — but with a Messenger bot it was more instant and intuitive.”
Q: What would you change now that you have more experience?
Jamie Mascall:
“This was the first bot that I’ve built, so much of the process was trial and error. As a prototype project, it meant that the chatbot was more of a research piece to allow me to implement better tech in future builds.
Moving forward, I’d like to build more sophisticated dialogs and add conversational intelligence, and I can’t wait to start playing around with IBM Watson.”
Paul Johnson:
“In terms of the process, I’d go back and begin right with API regulations. That’s because we were never able to use the chatbot in a live deployment — restrictions around Facebook’s API ultimately blocked the project.
From the tests we performed internally, we know that the chatbot was 98% accurate in its responses, and we received excellent feedback from the client. It was disappointing to create a solid product that we were unable to release, but a good bot building experience nonetheless.
In terms of the product itself, I wouldn’t necessarily make any changes to that particular bot, but I’d like to build more advanced ones driven by AI. For example, our existing live chat solution has a sentiment analysis function that can score customer happiness. I’d love to link that to AI so that urgent chats receive instant attention — I think the possibilities are huge.”
Q: How did you map out the conversational flow and user journey?
Jamie Mascall:
“For the prototype, I only built a sample of common dialogs. These were based on the most frequent queries we get through our website, and mainly centred around pricing or support.
I looked at our existing chat data to see samples of typical questions and answers, and used these as the basis for bot interactions. I also pooled further resource from our library of canned responses, so the conversational mapping process turned out to be relatively simple.
In total, there were around 50 conversational inputs that the bot could deal with. If the input was something outside of the sample dialogs, the chatbot simply stated that it couldn’t help with that query, and directed users to alternate contact options.
With that in mind, the user journey was simple: it was either an FAQ that the bot could manage, or a query beyond its range that triggered an alternate channel suggestion.
To test that each journey worked, I asked the service team to use the bot prototype and fire questions at it. Happily, no bugs were uncovered and I was able to present a working prototype at the end of the process.”
Paul Johnson:
“I started by researching common chat inputs in the customer’s industry. I also looked at the company’s FAQ and online self-service area to get a feel for their customers’ needs.
The customer didn’t want a bot posing as a human agent — they wanted the user to be clear that they were engaging with a chatbot. So, the bot didn’t need to be ‘conversational’ so much as helpful. It also meant that chat sessions had to begin by informing the user upfront that they were talking to a chatbot, and not to an agent.
By telling users that they were dealing with a chatbot, it allowed me, in effect, to remove the ‘chat’ element from the user journey. Instead, I could focus on keywords, combinations, and delivering the most helpful responses to those inputs.
The chatbot was programmed to analyse key trigger words in context with declarative statements such as, “I am” or “I would like to”. From there, it made decisions on how content input was formed to respond accurately.
For example, a customer typing in “I am hungry”, would get a response returning restaurants in their area. For any input that wasn’t within the chatbot’s dataset, the bot would not attempt to reply, and would state that it didn’t understand along with a ‘leave a message’ option.”
Q: Do you have any best practice tips for building a bot?
Jamie Mascall:
“Open-source frameworks are fantastic. I’d advise anyone starting out on a chatbot build to use them rather than trying to program from scratch.
It’s always tempting to create your own software for the pride value, but realistically, that’s going to be a time-consuming process. You might as well leverage existing code to fill out the bot framework quickly. You can add your own unique adaptations afterwards.
Plus, when you’re working with code from a company like Microsoft, you know it’s going to be secure and functionally sound.”
Paul Johnson:
“After my experience, I’d recommend checking API regulations before you start building. Perhaps less obviously, my biggest tip would be to make sure you consider spelling.
In the first round of testing, typos were having a negative impact on the accuracy of the chatbot, as I hadn’t taken common misspellings into account. This rendered input that should have been within the chatbot’s dataset unrecognisable, and impaired the experience.
I’d also recommend using Node for any chatbot builds — it’s one of the best frameworks available and makes for a quicker, easier build.”
Q: Are there any existing chatbot deployments that inspire / excite you?
Jamie Mascall:
“Watson is the obvious answer here — there are no chatbots that can compare to it in terms of natural language processing.
Outside of the obvious, I’ve been seeing some clever ecommerce chatbots recently. As well as answering product questions, some of the better examples can suggest alternatives for out of stock items and recommend products based on your cart. It’s like having a checkout assistant that you don’t have to make small talk with — really slick stuff.”
Paul Johnson:
“The first chatbot that really won me over was ProjectMurphy. That was the Messenger bot that could answer “What if…” type questions, and return with pictures that represent the answer. It kept the office entertained for hours, and I thought it was a unique, amusing use of a bot.
I think there is definitely an untapped market out there for amusing bots like ProjectMurphy, and there has been since the days of MSN and SmarterChild. It’s novel having a conversation with something you know to be a machine — especially if that machine can tickle your humour.
Outside of that, I have to refer back to Watson. Watson is essentially the chatbot holy grail, and it’s getting smarter month on month.”
Q: In your opinion, what is the future for chatbots?
Jamie Mascall:
“I think we’ll definitely see more and more chatbots in an ecommerce context, and they’ll get increasingly clever. But I don’t think chatbots will be the big customer service displacer that everyone imagines.
At the moment bots are still new, and people enjoy seeing what they can do as a novelty. For anything more urgent, though, humans still want to speak to other humans. That’s why I don’t think chatbots will ever completely replace service teams, and why I think the predictions of the end of apps, websites and jobs is premature.”
Paul Johnson:
“Chatbot usage will grow — I don’t see how it couldn’t. Considering the time it takes to build one, deploying a chatbot can save companies a ton of money and extend their availability.
We all love playing with cool new technology, and chatbots are no exception. Plus, they’re getting increasingly useful. You only have to look at all the clever banking assistants or health chatbot tools that are out there doing great work already.
I don’t think the pace of this innovation will slow any time soon. Having said that, I don’t think chatbots usher in unemployment. No matter how cool and innovative bots may be, humans still demand a human touch from the companies they do business with.”
Have a similar story to share? Tell it in a comment below!
