I wanted to build a shopping Chatbot for the British Heart Foundation.
Charity shops run on three engines; stock donations, volunteer helpers, and customers to buy things. So I wanted the bot to be able to offer something for all three aspects
The ‘Find a shop’ flow is about helping the user find a shop nearby to donate unwanted items to.
The bot asks for the users location and then queries the Google Places API for places that match the preset search term of “British Heart Foundation”. The results are displayed to the user as a set of three cards showing the nearest three BHF shops.
It relies on the information in Google Places being correct, which it isn’t always, and interestingly, the Google Places API only returns results of places that are open, which may work well if you’re looking for a place to eat right now but if you search for charity shops on a Saturday evening you get no results. If I was doing it again I’d want to host the shops location and opening times somewhere like a Google Sheet so that the bot can provide more useful info about which shops are nearby, their opening times and what kinds of things they want to be donated.
Another useful feature might be using Google Maps to show the route from the user to the shop they select.
The ‘Search our eBay store’ is about allowing the user to find out if the BHF eBay store has any of what they are looking for, and it was the most complicated and fun to build.
As it is a simple search it relies on the user knowing what they are looking for (which I think most people using eBay do). It doesn’t provide any kind of recommendations.
The eBay API’s are very comprehensive and there are multiple API’s available to accomplish different things. I used the ‘’ API as I could specify that only results for the British Heart Foundation store are returned.
The first part of the flow is about finding out what the user wants to search for and calling the API to return matching items.
The data that comes back includes a count of how many results there are. We can use this later but for now it’s useful to tell the user how many items we’ve got matching the search term to set their expectations about how helpful the next few steps will be in them finding what they are looking for.
Sometimes there are no matches to the search term and so the count is 0. This gives us something specific to filter on and means we can ask the user if they want to search again. If they say no then the flow ends there.
If there five or fewer results then the item name, image, and url on eBay are displayed in a set of cards. I chose to limit the number of cards to five to reduce the amount of sideways scrolling the user has to do. If there are more than five results (and we know this because of the count we used earlier) then the bot asks if the user would like to see more results. If they say yes then another set of five cards is displayed. This is repeated again meaning the maximum number is items that the user sees in the flow is fifteen, but there is no reason it couldn’t be expanded to continue to show as many items as there are in the search results.
Unfortunately the API specifies that only 140px thumbnail images are available, which means they don’t look great when displayed at a larger size (like when using messenger.com on a laptop).
I haven’t looked at the other ebay API’s but maybe the next step is to look at allowing the user to login to their eBay account and bid on an item.
The ‘Talk to a person’ flow is essentially a simple ‘Contact Us’ form (but I couldn’t call it ‘contact us’ as from the user’s point of view they have already contacted us by engaging with the bot.
It asks the user what their query is about, what they’d like to say, and their email address. Using the Freshdesk API, these details are used to create a ticket in Freshdesk.
Asking what the query is about is a way to automate the triaging of the ticket in Freshdesk. It’s a little annoying having to collect the email address when you already have a means of communicating with the user but it’s required for creating a ticket in Freshdesk and gives a way for the customer service agent to reply to the user. I might look into the Freshdesk API a bit more and see if it’s possible to pull the replies into the chat.
As a first iteration it works ok, and it was a good distraction on a Saturday night.
Roadmapping your test strategy with twelve month long themes and three month long objectives. Having a roadmap helps with more strategic discussions about what to focus on and what not to focus on and helps to avoid working reactively. But you always have to allow time for firefighting.
Test and learn shouldn’t just happen on the website, it should be part of how the organisation does things, but this is difficult in a risk averse culture that is protective of its reputation and hates the idea of making something public that appears unfinished.
Communication up front to the teams to let them know that they might benefit from the insights is important, and that communication should include letting them know that the results may have suggestions of things they can do in real life to improve their service.
Customer service complaints are great feedback to inform testing and support conclusions. Complaints are what customers tell you they want you to improve, test results are what they don’t tell you they want you to improve.
Deciding on a method for distributing customer service queries depends on an analysis of the tickets to understand how much variation there is the complexity of the queries and analysis of the agents to understand the variation in their ability.
This analysis isn’t to understand how complex the queries are, but to understand how different the queries are. If some of the queries are simple and some very complex, this is a high variation in complexity, and if all the queries are simple or all complex then this is low variation in the complexity. If the analysis of the difference in agents ability shows that some agents have lots of knowledge and ability whilst others have very low level of knowledge and ability then that is a high variation, but if all the agents are equally knowledgeable then the variation is low.
If there is a high degree of variation in the complexity of the queries, meaning some can be resolved easily in a few seconds whilst others take days or even weeks to reach resolution, and if the variation in the ability of the agents is high, due to some agents having lots of experience and others having a lower level of knowledge, then distributing tickets across the team using a load balancing method is best. This means that agents with more ability can be assigned and resolve more tickets than agents with lower ability who will be slower.
If the queries the team receive have a high variation of complexity but there is a low variation in the abilities of the agents as they all have similar levels of knowledge and experience, then manually triaging tickets can often be the most efficient method of assignment. The second most efficient method would be load balancing as complex tickets will take longer to be resolved by a one low ability agent as much as any other low ability agent.
If the majority of the queries are of a similar complexity (high complexity or low complexity) and there is a high variation in the abilities of the agents, because some are new to the role whilst others have more experience for example, then using a Skills based approach to assign tickets is an effective option. Agents with particular knowledge will be assigned tickets that require their expertise whilst agents with less experience will be assigned the tickets that only require more general skills.
If the type of queries the team receive are mostly of a similar complexity, e.g. all about similar topics and the abilities of the agents are all approximately the same, which means they all resolve tickets at a similar rate, then using round robin to distribute tickets equally across the team is the most efficient method.
I have a dashboard that tracks my time spent on the various pieces of work.
It allows me to ‘inspect and adapt’, to question whether I’m spending my time on the things that return the most value, to think about how to fit future work in, and look for areas of work to not do.
I’d really like to find a way to pull the data from my Outlook calendar rather than having to manually enter it into a spreadsheet every week, but for the time being the dashboard is useful enough to commit the time to updating it.
Using location in a chatbot can be really useful in providing information and services, but getting the coordinates into the chatbot isn’t as smooth and easy as perhaps we’d like.
Getting the user’s location starts with gaining permission for the device to send its longitude and latitude coordinates to the chatbot.
But if location is switched off, Messenger needs to ask for location to be switched on.
Clicking the button in Messenger triggers the device to seek permission to allow Messenger to access location.
But that doesn’t always work.
Once location is switched on Messenger can get the long/lat coordinates.
And then Messenger can pass the coordinates to the chatbot.
Once all those steps have been taken the chatbot can finally use the precise location to provide whatever information or services to the user.
Given how complicated getting that location is for the user we should question whether getting the precise longitude and latitude coordinates is the best option for obtaining the user’s location. If the chatbot only needs to know the region the user is in then simply asking the user could be a better option.
I drive a sports car. You drive a bus. I can get myself there quickly. You can get lots of people there slowly. You can’t make a bus handle like a sports car but you can tell people to get off the bus and find other means of transportation.