For several years, chatbots have become an integral part of the IT landscape. Whether they are targeted at B2B, B2C or B2B2BC, they are part of the new habits. Although they are not really “intelligent”, they can nevertheless respond very well to particular needs. This lack of intelligence is neither more nor less than an implementation limitation: a chatbot is a human-business interface, connected to a knowledge base in which questions and their corresponding answers are configured. A processing mode applied to the user’s input (NLP, NLU, or “home-made” engine) allows the appropriate response to be returned.
In fact, some organizations have parallelized chatbots to meet different business needs (searching for information in a particular area, level 1 support, taking leave or entering expense reports, etc.).
Understanding the stack of chatbots is a response to different needs (siloed by business or by user group) is important. Given the specificity of each need, it is common for these different chatbots to be based on different technologies or event from different providers. Many companies have built chatbots that meet a particular business need in an expert way, sometimes for as long as ten years. The needs being potentially infinite, the number of chatbots is consequently enormous.
The prospect of parallelizing chatbots to meet very different needs is attractive (the very positive influence of these tools is no longer to be proven). Nevertheless, an issue emerges with each large-scale adoption of a new usage: the governance of the associated tools.
Gouvernance issue #1 : if all chatbots deployed in an organization can address specific groups of employees, they are nevertheless integrated into the IS. And therefore managed, in fine, by IT.
Governance issue #2 : if a user of the organization must be able to perform tasks addressed by several chatbots, he will have to juggle between different interfaces. The ergonomic interest is therefore lost.
The most logical solution would be to be able to connect all these chatbots in order to keep a single interface. However, since all these chatbots are specific, it is difficult to find a way to interoperate. Moreover, the analysis and processing of user requests is very complex (routing to the right answer, weighting of answers according to a context, etc.).
This type of technology is called a “metabot”. A metabot interconnects different chatbots, redirecting user requests to the most appropriate one to provide the answer. This can be done in different ways: querying all the chatbots until the answer is found; using language processing technologies to analyze the request and target the right chatbot to get the answer; aggregating the “knowledge” of all the chatbots to do a preprocessing.
Finally, a lot of technical possibilities that come up against the need to technically translate the user’s request into the format used by each of the chatbots connected to the metabot. With the added bonus of the extreme complexity of providing the right answer when it is found in several chatbots…
What about Hubi?
Rather than trying to orchestrate a set of non-interoperable chatbots, whose governance is difficult, and whose response quality is uncertain, Hubi.ai was architected from the start as a metabot.
Simply put, Hubi.ai is a chatbot to which business modules (knowledge bases, business applications, mixed processing such as helpdesk, HR, etc.) are connected. Each of these modules can communicate with back-end solutions, such as CRM, EDM, or others. Each user request, whatever it is, is analyzed, redirected to the right module, and the answer is returned in a very seamless way.
This design provides benefits in several areas:
- The user experience is significantly improved and benefits from a single access point, easily adapted to future uses (voice input, mobile, connection of IoT devices to automated scenarios…)
- Simplification of governance: being centralized, it becomes very simple to maintain a single solution
- Rationalization of license / maintenance costs
- Extremely simple extensibility of the solution: No-Code platform and module store to add new knowledge bases and business scenarios
Finally, if you already have a chatbot solution with an API (Microsoft Live Agent, IBM Watson…), Hubi can even address it in the background with its universal connector.
If you want to learn more, request your Hubi demo today!