4 Perspectives When Selecting a Conversational AI Platform
When selecting the perfect CAI platform to integrate into your business, there are many factors to consider, including limitations, room for creativity, and more.
Join the DZone community and get the full member experience.Join For Free
Businesses are quickly acknowledging the importance of Conversational AI (CAI) to increase their customer engagement and revenues. The question is no longer whether to deploy CAI, but rather which platform to use and how to leverage its capabilities.
This article will provide insight on important aspects of a conversational AI platform that buyers often overlook. For example, what does language support really mean? What is localization? How do different deployment models impact the TCO? And maybe most importantly – How can the CAI platform not only help me during the first development sprints – but across the entire bot lifecycle?
Lessons Learned to Make Bot Developers More Productive
During the last six months, I’ve had a lot of conversations with companies (clients) and system integrators (partners) who have been building conversational bots. I’ve spoken with conversational bot developers, data linguistics reps, integration engineers, conversational designers, project managers, senior stakeholders, product owners, and many more.
At the same time, I’ve talked to existing, new, prospective, and former clients. These talks included people who had ambitious plans and succeeded and others who have had plans where they have struggled to generate impact.
One of my goals for these discussions has been to find the answer to the questions: “How can we as CAI tech providers help you be more productive?”. This is a question we from Artificial Solutions will continue to ask because the feedback from the bot developer community on our products is key for us in our mission to create products that make bot developers more productive.
However, in these conversations, another topic of discussion arouse that is the focus of this post: How do companies view their choice of CAI platform today – and what aspects would they recommend other companies to consider when selecting a CAI platform for bot development?
You could argue that this is probably a question best answered by someone who is considered an independent third party – and I fully agree with that. However, this is an issue for which it is worth having an open conversation, so I thought I’d share some of the learnings I took away from those discussions and added some of the learnings we at Artificial Solutions have from our 20+ years in the industry.
If this compilation is useful to you, or think I’ve missed something – don’t hesitate to leave your comments in our forum.
I’ve grouped the insights into four main themes which I think could be useful for companies to think about when reviewing CAI tooling for bot development and will share them in this daily series. These are the “4 perspectives you shouldn’t miss when selecting a Conversational AI platform”:
- Select a tool your development team can grow with
- Language Support & Localization
- Total Cost of Ownership
- Cross Vertical Readiness
Let’s run through them one by one. Curious to see if you agree.
1. Select a Tool Your Development Team Can Grow With
See Past the Buzz-Words Like "Awareness," "Understanding," and "Self-Learning."
Conversational AI is a fascinating space and still holds a lot of potential yet to be explored. Yet most companies who have experience of CAI tooling will tell you it's all about engineering, and actually has a lot of resemblance to regular software or process flow development instead of being something ground-breaking new.
Sure, there are some terminologies both useful and specific for the space, like "intent recognition", "entities" and "context". These words are related to the Natural Language Understanding (NLU) part of a conversational bot.
Don’t get me wrong – those are complex concepts, but the conversational bot developers normally USE these functionalities they don’t develop them themselves. To the conversational bot developer, those types of functionalities are assumed to work and, in all fairness, most tooling support strong intent recognition, it’s more of a commodity functionality today. You can assume a toolkit has a good enough intent engine and move on.
However - be aware if the tooling you are selecting describes features with excessive AI-like buzzwords like “awareness”, “understanding” or “self-learning”. These aren’t wording a developer would use to describe the conversational bot they have developed (unless they are desperate for funding). So, I suggest you try to see past these buzzwords and select tooling that uses concepts and terminology that better resembles how a developer would look at the world.
Can I be more specific? Sure, I prefer if well-established concepts like local or global variables (variable scope) are referred to as local or global variables rather than “The AI understands and remembers”. Review a tooling from the aspect – is the terminology used familiar to the developers who will use it to build bots.
Find the Balance Between Pure Coding and Drag-and-Drop
Have you ever heard about low-code or no-code? In short, those concepts describe a user interface where a developer can configure or graphically design a process instead of having to write programming code. It is a great way to visualize how a program is executed and can be a quick way to build some things rapidly. Here comes the tricky part - for an effective Conversational AI solution with some ambition - you will still need to code. Your team will need to write code in some scripting language. If not, you will not be able to do the things you expect a bot to do. Do not shy away from this fact, the scripting and coding are super important to make a bot great. So, when you look at a toolset, evaluate it from the standpoint "how will the coding part work?".
On the other hand, if you ONLY write code and never use any graphical representation you will run into another set of problems. How do you collaborate with the business? How do you involve team members with important insights that are needed for a successful bot implementation, but those team members do not read code? This is one of the many aspects of why a graphical representation can be very useful.
Therefore, think about what balance between coding and graphical configuration you need. Because most companies need both for their CAI projects.
Consider What Limitations You Might Encounter Down the Road
There are a lot of CAI tooling in the market today available to developers. Your job is to make sure that you don’t select a tooling that is quick to build only the first MVP, but also is useful for every new generation of your bot. When your ambitions grow, and your insights on how you can deliver a better bot user experience starts to develop - you might realize that the tool you chose is holding you back.
For each generation of your conversational bot, there are multiple factors that you need to consider. If you build mode processes (and with that more intents) you run into one set of problems. If you want to make your flows more advanced, you run into another need for capabilities in the toolset. That’s when it might be too late to realize the tool is not up for the job.
Try instead to evaluate a toolset from a scenario where you already have a quite extensive bot deployed. With this, try to think about the different tasks you might want to perform now. How do you perform refactoring and release small improvements in parallel? How do you organize all the processes/intents and perform a version control? How do you ensure reusability? What technical features might you want to explore?
Allow for Creativity
Strive for greatness. We think great teams build great bots. Make sure you think about and choose a tool with which your engineers can be creative, and iterative with. The same way a good website is continuously updated, with new features tested, explored, expanded, or removed your conversational bot also needs continuous improvements. The freedom to explore, test, release and sometimes sunset ideas are key to unlocking your team’s creativity and ambition. A conversational bot program is no different. Think about what your expert implementors want to do and ensure that they have the capability in the tool to achieve their objective. Great teams build great bots unless the tool holds them back.
2. Language Support and Localization
What Is “Language Support?”
What does language support really mean in the conversational AI world? It is actually an important question to think about before evaluating CAI tools.
A conversational bot’s output - what the bot is saying - is almost always written by the implementor. It is like a manuscript written by your team that the bot follows. There can be variations of output generated by the bot that allows for a little more natural conversation, but most clients have a bot for a specific domain or purpose, so the degrees of freedom are fairly small. What the bot is saying to the users is largely designed by the bot development team. Therefore, the bot’s output is very controlled. So, in terms of output - language support does not mean that much - it can simply be that the specific language characters do not become garbled in the output. To help with the output, a bot development tool might have libraries available for some generic output like social talk and standard responses.
In short - conversational language support has very little to do with what the bot is “saying to” your users.
Language support is almost entirely about how the bot can support and map INPUT for a specific language. Can the bot accept Cyrillic characters without spitting out an error message? Can the bot split a sentence in Japanese to identify the verbs, nouns and adjectives? Can the bot, without training, classify words or phrases in a Spanish sentence?
What is important for a bot developer is that the language supports help them build bots for a specific language. So can the bot platform for a specific language “accept an input and annotate (add metadata)” so that the developer can make use of this to design a good conversational bot experience.
Different conversational AI platforms might claim to support German. But for one platform it can mean "the bot accept German characters" and for the other "the bot has an extensive annotation of words, phrases, concepts, entities, and pre-built knowledge in German". Always try to read behind the simple description of a products language support. And think about what languages your company needs to deploy bots in.
What Is “Localization” and How Is It Valuable?
Most companies today want to roll out successful conversational bot implementation in more than one language. This happens for different reasons. Sometimes, businesses operate in countries or regions like Switzerland with several official languages, or they want to expand their market and deploy a bot in a neighbouring country. You can even say that deploying the same bot in two different channels like phone and Facebook messenger might require two different "languages" or at least tonalities.
Now here comes the tricky part - how do you develop and maintain a bot which is MOSTLY the same but in two or more languages? Do you just copy it and try to maintain two or more parallel solutions? Anyone who has tried this knows that this is a recipe for failure or at least a very inefficient and resource-demanding way of working.
One solution to this problem is called "localization".
Localization means you can create a master solution and then localize it for each specific language/region. The localized solution is linked to the master solution so that updates and changes can be propagated (under change control) to the local solutions.
Localization is not only about languages. If the same conversational bot flow needs to support two different back-end systems for two different regions – then localization should support that feature as well. You need to be able to make variations to the local implementation, without losing the benefit of the link to the master solution.
For most companies with an international outlook, consider the benefits of requiring your conversational AI development platform to support localization. Think about what languages support and variations you need long term, and make sure the toolset you chose gives your room to grow.
3. Total Cost of Ownership
Identify the Hidden Costs of the Deployment Models
What is a deployment model? Well, most CAI platforms can be offered in different ways: SaaS, on-prem, hosted, opens source etc. Let’s assume you and your security team have done the homework and that all the deployment model options are on the table. What cost aspects an important to consider?
Does a pre-pay model cover a hidden cost? A prepay model is a commercial model often linked to the deployment model where the client needs to commit to a certain resource consumption or ambition. The dynamics of a pre-paid model is quite often "you pay for consumption X, if you consume more you need to pay more, if you consume less, you still pay X". One aspect I recommend you to consider is that Conversational AI projects typically are a bit difficult to estimate, then can go slower or faster than expected. They can hit a larger or smaller audience than targeted. A pre-paid model can easily actually in hindsight turn out to be quite expensive.
Another hidden cost is the IT management cost of running and maintaining the installation yourself. Even if you pay for a license + support for an on-prem version you still need to pay for hardware, daily management, tools for monitoring or on-call support in the middle of the night. Plus think about what your team will spend time with. If you scope a team for building, but they spend most of their time on infra issues, that’s quite expensive.
Always try to think about the hidden cost of each model, to be able to try to estimate the total cost of ownership. Think about how much it will cost after first deployment for maintenance and testing etc across the lifecycle. Do not overlook the fact that a Conversational AI platform needs to support all the phases after going live as well. This is where version control, published flags, re-factoring, regression testing, analytics, performance dashboards, improvement dashboards etc come into play. If you choose a tool that only helps you with your first build, you will end up paying a lot more from the efficiencies incurred later. Always think about the entire lifecycle of the program and what is needed in different phases. Make sure you select a tool that is up to the job.
Will Your Resources Spend the Time on the Right Thing?
Are Your Resources Efficient Across the Program Lifecycle?
Everyone wants to be productive. That is the same across all disciplines and industries and for sure is true for conversational AI developers. All conversational AI developers I know of, both love to build and to deploy. They want to be productive in their domain.
So, try to see past the fancy words and promises of quick wins in Conversational AI and ask yourself - will this tool make my team productive?
And not only productive in their first 1-2 month in the project but also two years from now when things have scaled up and become more encompassing but also more complex. Great teams build great bots - your job when selecting a Conversational AI tool is to help the team be as productive as possible across the entire program lifecycle.
4. Cross Vertical Readiness
Most companies explore multiple use cases, make sure your tools are not locked in a vertical
How many conversational bots do you have in your company? If not many, ask around in your network and you might be surprised that there are often more than one deployed across a business. Most companies explore Conversational AI in both internal (employee-facing) and external (customer and supplier facing) use cases. Therefore, it is important to think ahead when selecting a platform for conversational AI. How many areas do we want to explore? Are we sure we only try to build one type of solution?
I recommend considering if the toolset you are selecting is horizontal or verticalized – meaning is it optimized for a use case or industry (vertical) or optimized for agility across industries and use cases (horizontal).
Because internal and external use cases are actually very different, even in the same industry. This is where it is important for you to think about which models benefits outweighs their weaknesses. I would like to point out some of the strengths of a horizontal solution, and the first one is that you can use the same development platform across your different use cases. This would also enable you to get support from a larger community than if you go for industry-specific solutions that all your competitors are using. Remember, the conversational AI-space is all about building. Find the tool that gives you the most edge in your development process.
One can think about this from a different lens. What are the strengths of pre-trained solutions for a specific use case? You typically save time sourcing training data; you might have pre-built knowledge that you can reuse. This can be beneficial, but also has limitations. if you want to make changes, or you need to add specific training data that is unique for you can you do that? And does the use-case specific package help you in another use case?
There are probably exceptions, but the simple rule is likely that a Conversational AI platform either is pre-built and then a bit limited in terms of customizations OR more flexible and then you have to build more yourself. We think this is a world of builders and would recommend you to really think about the long-term benefits of choosing a horizontal solution.
It is really about building, so packages that are reusable across verticals are typically more valuable than use-case-specific ones.
It might sound like the advice I’m giving now is contradicting my previous statement but here it goes - pre-built knowledge can really save you time! There is a reason why communities end up building great things together, everyone benefits in efficiency from the contributions of others. So, no doubt, pre-built packages are great. What might be surprising though, is that in Conversational AI, the pre-built packaged need to be very small to be useful. And with small, I mean for example a collection of intents instead of a complete “pre-built bot". An integration package for salesforce can easily be re-used if it only includes the basic building blocks of the API connection to salesforce. Because then it can easily be incorporated in many different use cases - internal sales support, internal reporting, external customer support, etc. But a pre-trained "external customer support" package might even take more time to adapt to a different use case. Because you need to review and adapt every single component of the package and if you end up needing to restructure you might as well start with a white piece of paper instead. So really discuss with your vendor about pre-built packages, but make sure they are modular and fairly small. And remember to share modules you have built yourself with the community. That is typically a great way to share work and find improvements.
Your company and clients probably need a very specific tonality, make sure you can control it yourself
My last advice is probably a bit difficult to map in the top 4 I’ve mentioned - but I chose to file it under "Cross vertical readiness". This is my take: Try to build your bots to reflect your company value and chose the tonalities that help build your brand. This is likely not easy, and I am not sure you really can get much help on that from external parties. You need to have your culture and brand promoters to be involved. Why is this relevant when selecting a conversational AI platform? Because in the end, we recommend that you make sure that can collaborate with different competencies across your business and that you are in control so that you can design exactly the experience your users should have. Your customers will spend time interacting with your bot, it is one of the few bidirectional interactions your will have with your customer base – don’t waste it! Be in control, build your brand!
Opinions expressed by DZone contributors are their own.