Making Sense of the Chatbot and Conversational AI Platform Market

Overview

Introduction

The CAIPs market constitutes an estimated 2000 vendors worldwide. It’s a highly diverse market with vendors of varying capabilities, language support and strategies. Application leaders that are responsible for development and maintenance of chatbots, virtual agents and virtual assistants (VAs) in the marketplace struggle with not only vendor selection, but monitoring and understanding how the marketplace will help with making the right choices at the right time.

Due to the wide variety of use cases, levels of sophistication, language and geographical support (and strategies of vendors) vendor selection is all about best fit. However, it is not currently possible to narrow down the market to a few vendors that will be a good choice for the majority of enterprises.By looking at your enterprise needs, and mapping those needs to capabilities and categories of vendors, you will be able to find the best possible shortlist of vendors.

Analysis

To understand which vendors are relevant to your enterprise requires understanding of the level of sophistication needed to get ROI on use cases. More sophisticated is not necessarily better, as it significantly increases cost, effort and competence requirements. Different CAIPs have different sweet spots for what level of sophistication they are suited for. Missing the sweet spot could lead to either having a platform not able to deliver, or a platform that’s much more expensive than needed — not only in terms of cost, but competence and time investments.

It’s very hard, sometimes impossible, to organically grow the level of sophistication. Going from simple questions and answers to more goal-driven intents requires new training data and dialogue design, which overlaps and supersedes the simple implementation. A common problem is that end users learn very little from proofs of concepts (POCs), since the POC is done at a lower level of sophistication than the target, production-level implementation (see ).

Sophistication of solutions varies significantly. Key factors that add complexity include:

• The number and complexity of integrations to back-end or external systems, such as authentication services, customer relationship management (CRM) systems and support ticketing systems can contribute to the complexity of a project.

• The sophistication of the underlying customer and domain model will influence the overall complexity of the project. While this is related to the integrations, it may add complexity itself.

• The number and types of channels, modalities to support, for instance developing a text only chatbot is often less complex than developing a chatbot that includes images or that must also support voice interactions.

• The need for orchestration of multiple chatbots or VAs for different use cases, or multiple contributing and collaborating on the same use case can greatly increase architectural complexity.

• The number of utterances or intents to support and the related tasks of generating, tuning and managing the training data also adds to complexity.

• The number of languages and language variant requirements can influence the sophistication of the solution required.

Tools assist in mitigating the complexity of designing, developing and maintaining solutions. As solution requirements become more demanding, the importance of strong tools increases (see Figure 1).

CAIPs enable implementations of varying degrees of sophistication. Movement toward higher sophistication is hard, thus finding the right level is essential.

In a market as diverse as the conversational AI market, with an estimated 2000 vendors, segmenting vendors according to your enterprise needs allows you to scope the vendor landscape down to only the vendors that will be a good fit. This categorization model creates seven different ways to categorize vendors. For larger vendors, with multiple products or platforms in this space, categorizing on product will yield better results, see Table 1.

The first way to categorize vendors is to look at who will do the building and the maintenance of the implementation. The market has three broad categories that most vendors fall into:

Application development — If the CAIP requires application development competence in order to set up and maintain either the NLP/natural language understanding (NLU) or the dialogue management, and makes available APIs and/or SDKS so developers can do this. For larger implementations that need constant monitoring, tweaking and evolution — having application developers do most of the work can be prohibitive for scaling and maintenance.

Line of business (LOB) — If the CAIP provides low-code/no-code tools for training and maintaining intents and dialogue design — allowing LOB personnel to do the build and maintain. With increased sophistication, the capabilities of the tooling needs to be equally sophisticated. For sophisticated implementations, training or even hiring specialists is needed even though the tooling is targeted at non-developers and non-data scientists.

Managed by vendor — If the CAIP vendor builds and maintains the implementation for the client, regardless of what tools the vendor uses to do so, that becomes irrelevant to the client that has an SLA to govern the managed relationship with the vendor.

In the case where application development has to be involved in certain aspects, but LOB can do some tasks —the overlap would be appropriate positioning. Same goes for managed vendors that deliver large implementations to be maintained by application development or LOBs.

The second category involves the purpose for which the CAIP should be used for. There are largely three underlying purposes that exist in the market. They can be easily determined by the proposed business cases of the vendor. If the focus is primarily on cost-cutting by reducing workforce, replacing humans is the purpose, regardless of how it’s done.

• Replacing humans —Primarily the purpose of the implementations is to replace humans that are already doing the work. This results in less employees, and a cost cutting in salary costs, regardless of method.

• Empowering humans — The purpose of the implementations is to empower, this does not necessarily cut cost, but rather, the primary concern is the improvement of quality. Supporting better decisions, democratizing access, ensuring compliance, it’s all ways to empower.

• Growth and innovation — The purpose of the implementation is to either facilitate growth or be able to hold conversations where it wasn’t possible before. Typically seen in the adoption of new channels like WeChat or WhatsApp, where there is no staffing to take on the requests from the channel and a bot is required to be able to support the channel.

The intended audience of the implementation. The most common use case is customer service, which naturally contains the customer audience. In addition, if the solution should target multiple audiences, that may bring their own set of requirements.

• Customers — Like we find in customer service, but also in B2B scenarios. Often, but not always, this audience can have a larger variance in language, use more short hand and phonetic spelling, and use a different vocabulary to describe products or services than what an internal user would. In addition, for some enterprises, the brand experience is more important with the customer audience than other audiences.

• Employees —Business partners or other professional users often require more advanced tasks done using a conversational solution. However, the language might in most instances be more specialized, professional and uniform, with correct use of internal abbreviations. Employee-facing conversational solutions are more likely to be transactional and multi-modal than with other audiences.

• Consumers — Are for many enterprises synonymous with customers, but for some like the media industry where add buyers are customers and readers or viewers are consumers, consumers are a very important and separate audience. For vendors focusing on consumers, there are typically integrations with consumer products, like web/mobile applications, speakers and automotive systems.

How the solution deployed ties into the enterprises’ overall vendor selection strategy, current strategic choices of platforms and vendors, and internal capabilities.

• Stand-alone solutions are sold as capable best-of-breed. It’s focused on solving core capabilities and using integration to third-party solutions. Vendors primarily are interested in the selling and retention of their core product.

• Part of cognitive platform solutions are part of an ecosystem of many cognitive services. There should be easy integration with a lot of synergetic services. It’s a good choice if your enterprise is already invested in the cognitive and/or cloud platform or are planning to. The vendor will have an interest in growing their offering into including more services.

• Part of an enterprise solution is part of another solution, or strongly tied to it. Even if sold as a stand-alone, the vendor presumes use with their core product. Roadmap will involve tighter and more synergetic integration. It’s very seldom a good choice unless the enterprise is also invested in the core solution from the vendor.

Solutions are packaged in different ways. While a packaging strategy is hard to bring down to three broad categories without losing a lot of nuance, from a high level perspective these categories matter the most to the buying enterprise.

• Platform is positioned as a foundation to build on. Use cases often need additional work, either with your own application developers, professional services or through low-code/no-code tools by your business units to be able to cover your use case. A platform can still have accelerators and pre-build implementation on top of the platform.

• Product is positioned as a solution for a particular use case. It often highlights ease of use and time to market — although this is not always delivered. Compared to a platform, a product is more ready for a particular industry or domain use case or even highly specific tasks, while less ready for alternate use cases that are not supported.

• Project can be built on top of either a platform or a product, but a selection of vendors make it hard to distinguish between what the platform/product is and what’s delivered as a project using professional services. The project approach can however give you a “finished” solution, although care needs to be taken in ensuring handover either to your own maintainers or the managing organization.

It’s important to determine what kind of scope of solution will fit your use case. Getting just components when the expectation is full-stack can lead to excessive professional services costs trying to deliver on requirements. Alternatively, going full-stack when components would suffice can lead to unnecessary licensing costs.

• Components — Vendors focus on making best-of-breed components. Commonly seen with vendors specializing on the NLP engine itself, there are also vendors specializing in other components. Bigger vendors might offer several components that together can be seen as partly full-stack, but can lack the user interfaces and integrations to be labelled as such.

• Middleware — Vendors typically rely on third-party components to deliver a full-stack solution. Most common is to rely on cloud based NLP engines, but many variants of middleware exist (see ). The focus on middleware is often the tooling and orchestration of conversational AI.

• Full stack — Vendors deliver the whole stack of capabilities from low level components like the NLP engine, to tooling and orchestration on top. Some will be flexible to act as a middleware as well, yet others claim synergies between their low level components and middleware that cannot be realized without a tight coupling.

The last important consideration is the level of Specialization of vendors. Choosing a horizontal vendor to solve a use case where a specialized vendor would have solved it quicker and faster needs to be a conscious decision. This needs to be viewed against flexibility and suitability for multiple use cases as well.

• Horizontal solutions maximize flexibility. They do not target a specific use case, but seek to be useful as a foundation to any use case. Sometimes horizontal solution providers will have vertical or domain specialized solutions they can put on top of a horizontal one — trying to leverage the best of two worlds. A horizontal solution provides maximum flexibility and the most control, which has to be compared to the time to market advantage that a more specialized solution can give.

• Vertical/domain specialized comes to market with a set of accelerators or libraries that makes it a better fit for a particular industry, domain or use case. There can be significant savings in cost and effort if the specialization is a good fit — but it can also be a path to multiple vendors in “chatbot soup.”

• Task specialized is a vendor that specializes in one particular and highly specialized task. This can be things like booking meetings or rescheduling tickets. If the vendor can bring enough sophistication and automation on a common task, there might be no way an enterprise can replicate it using a horizontal or even vertical/domain specialized solution. Although, a task specific bot will lack flexibility to do new tasks at the same level of sophistication.

The last important consideration is language support. Language support is not a checkbox, but more of a sliding scale of quality. Depending on audience you may see:

• Phonetic spelling

• Loan words from other languages

• Different grammatical structures from geographical or socioeconomic groups

• Shorthand

• Slang

Taken together, this shows that even inside of a single language there can be many, many language variants. It is important to determine if the vendor will be able to support the necessary language variants.

Vendors will, in some instances, inflate their language support by supporting only parts of the NLP pipeline for a particular language. While doing a specific part, like intent categorization, can still be useful, more sophisticated implementations will need a full set of capabilities (see Figure 2).

While machine translation has greatly improved (see ), using it for conversational use cases is usually discouraged. Each step will naturally have a lower performance, coupled with two sources of uncertainty — from translation and from intent categorization.

The market for CAIPs is not only diverse, but houses an estimated 2000 vendors. Since no vendor can be said to be a leader or appropriate for the majority of use cases, we need to make sense of the market to create an appropriate shortlist of vendors.

By determining sophistication and preferences within the seven categorizations of vendors — together with determining needed language support — the shortlist will not only be more manageable, but a better fit.

Gartner Recommended Reading