Chatbot taxonomy 2.0

Intro

Two years ago, I wrote my first draft of a chatbot taxonomy. My goal was to establish a common framework that could be used to identify different kinds of chatbots, shedding light onto what was then a brand-new technology.

Years later, the market has matured — as has our understanding of it. The scene is no longer one in which newly-founded vendors play “buzzword bingo” with inexperienced customers. In a market where chatbots are commonplace, customers no longer care whether vendors are selling them an NLP-AI-ML-Big-Data package. What they care about are results. And the way we talk about chatbots — the chatbot taxonomy of 2020 — must reflect that.

New taxonomy

If results are the single most important factor for a customer looking to implement a chatbot, then it stands to reason that the first question in the taxonomy is

(1) What is the general purpose of the bot?

Like any other piece of enterprise software, chatbots must be implemented with a defined purpose in mind. Broadly speaking, I see the following three use-cases dominate the chatbot sphere:

I’ll go into a bit more detail on each, starting from “High ROI focus” and moving to “Minimal ROI focus” use cases:

Customer-Facing

The most common chatbot goal is to be “Customer Facing”. Every website with a widget in the bottom-right corner could include some kind of customer-facing chatbot. These chatbots can obviously specialise in different domains; they usually end up being either more sales focused, more marketing focused, or more customer-service focused, but it is not uncommon for chatbots to do a combination of the three (incidentally, see this article for why I don’t think bots are always the best interface to make sales).

Of the three categories, these projects have the highest pressure to make a return on their investment. Every support ticket avoided, lead captured, or sale made through this kind of project will be tallied up versus the cost of the chatbot. The project lives or dies based on the result of the ROI calculation.

Internal Support

If the project is relied on by employees to navigate administrative tasks such as booking travel, checking time off balances, requesting new IT equipment, or similar, then the project was probably launched with the intent of streamlining internal processes.

In this case, although ROI won’t be as central of a focus as in the case of Customer-Facing projects, a qualitative feel of “value for money” will generally still be present. Employees need to actually use the bot and give feedback that it is helpful for the project to be deemed a success.

Lighthouse Projects

If a company’s main goal is not the return on their tech investment, their chatbot is probably a “Lighthouse Project.” This is a very broad category, as it can include everything from small companies who invest in a support chatbot despite seeing very low ticket volumes to big companies with budgets to try out new tech to data science behemoths like Google who are looking to launch the next big thing in the chatbot space. What draws all these use cases together is a focus on progress, excitement, and technological innovation rather than profit or direct business results.

To those ends, “ROI” may as well be a foreign language when it comes to Lighthouse Projects. As an anonymous acquaintance of mine who had been in charge of such a project once told me, “I have been given a budget of millions. I presented the results on stage alongside the CEO of our company in a football stadium filled with employees to drive innovation inside the company.”

(2) What kind of company is using the bot?

Different companies have different requirements and resource constraints. This means that the kind of company that uses the bot needs to be layered on top of the general purpose of the bot.

I have generally found company size to be the best proxy in this regard. To be specific, I categorize companies into “T-shirt” sizes by the criteria below:

small: The kind of company where the managing director knows everyone and information flows quickly and easily between teams; probably fewer than 50 employees, and you probably haven’t heard of them (yet)
medium: A massive range of companies — really anywhere between 50 or 1000 employees — where defined teams have formed and you feel the company has some weight to it, but the company is also not the behemoth leader in their field. They might be highly specialized, target a specific geography, or still be an “up and coming” scale-up. Think local insurance firms such as WGV Versicherungen or an outdoor gear retailer like Globetrotter.
large: I call these the “Tier 1”s — these are companies with over a thousand employees. They are the “big names” in their respective fields who have defined their own language, so to speak. Think everything from Slack for office communication to Zalando for online retail to Allianz for insurance.

(3) Which types of vendors offer these bots?

Finally, different combinations of chatbot purpose and company type will work best with a certain type of vendor. There are four main categories here:

lightweight SaaS: Lightweight software-as-a-service vendors are either free or cheap and provide an easy-to-use, no-code/low-code option to get a chatbot off the ground fast. With the low price tag, of course, come some limitations — sometimes in terms of functionality (e.g., Landbot includes only rule-based bots rather than NLP), sometimes in terms of flexibility or key account management (e.g., the free tier of Snatchbot does not allow whitelabelling the bot, and limits support to asking questions in community forums). Using lightweight SaaS of course has a very low cost of ownership, but the flexibility of the tools is also relatively low.

specialized SaaS: Specialized SaaS vendors offer standard packages, priced based on features and/or platform usage. Like their lightweight SaaS counterparts, they allow customers to create chatbots on a no-code/low-code platform and to get off the ground fast. The key differentiator is that the higher price tag brings extra care and attention to detail. This can include training programs, key account management, attentive support, specialized use cases, among others. Such companies include Solvemate, Ada, Aivo, and Boost.ai.

custom chatbot: Platforms like IBM Watson and Rasa Enterprise offer enterprise solutions to develop a chatbot project. Unlike SaaS offerings, they do not have standard packages; instead you pay a software fee to get access to a platform, which an internal team (comprised of developers as well as subject experts) can then use to develop the chatbot. Alternatively, a consultancy can help get the project off the ground. This approach is highly flexible, but also takes a long time to set up, has a high setup cost, and incurs a high cost of ownership.

own development: Companies can take a conversational AI framework like Rasa Open Source and either use it to bootstrap their own development or else inspire their own AI framework. This is the most from-scratch of the ‘from-scratch’ options. The “type of vendor” is “no vendor at all” in this case. And naturally, “own development” will end up with the highest ongoing cost (in terms of time and effort), as well as the very highest level of control and flexibility.

Putting it all together: purpose, company, and vendor

Based on the purpose of the chatbot project and the type of company launching the project, a certain vendor becomes the best fit. So, if we put those three questions together into a matrix, we get:

And that is an up-to-date taxonomy to bring us into 2020!