A chatbot that plugs directly into your data on your systems

In the 80’s and 90’s Sony ruled the world of portable music. Everyone remembers the game changing Walkman series of products that revolutionized the portable music landscape and enriched our lives. Then digital music came along in the form of mp3’s. And now all the music online was in this format, with the only problem being that Sony only supported their proprietary ATRAC format on all their meticulously manufactured hardware. This was not a recipe for success for Sony, and culminated in the dead-on-arrival Sony Network Walkman. In 1999 it was the smallest digital music player on the market. Beautifully crafted, like all Sony products were back then (though it kind of looks like a bicycle lock now), it defiantly only played ATRAC files.

Figure 1: Beautifully crafted obsolescence

The death knell tolled for the Sony digital music division in October 2001 when Apple announced, in all its mock-turtlenecked glory, the iPod combined with iTunes. It was the ultimate mp3 player. It took Sony a further four years to fully realize what had happened to them (ironically right before the iPhone was announced), but the rest of the world got it immediately.

Today we are seeing a similar parallel. Chatbot vendors that are delivering solutions that require you to load all your data into their proprietary AI systems, with their proprietary formats.

These are AI systems that you have no control over, and, often, systems that are highly insecure. Why would any vendor require that when we have such a thing as API’s? Shouldn’t AI technology be smart enough to use API’s to look at your data in real-time and figure stuff out? The answer is simple: yes, it should.

In 2018, API’s are to AI, what mp3 was to digital music in 2001.

Let’s go with the most basic of examples to illustrate this. All chatbot vendors provide what’s called an FAQ feature (though the better solutions do a LOT more). Meaning that you ask the chatbot a question and it gives you an answer. But what the “bad” vendors do is that they require you to load all the answers into their proprietary AI solution, in their proprietary format. Why is this bad? Let us count the ways:

1. Those answers already exist in some knowledge base in your current systems. Now you have to maintain the answers not just in your current systems, you also have to maintain the same answers in the chatbot AI too. This is called dual maintenance, and it’s bad. The chances of your web systems’ content being out of sync with your chatbot content just went through the roof.
2. The tight control you have in your current content management systems (CMS), and all the sophisticated features they come with, almost certainly don’t exist within the chatbot vendors solution (which was never built to be a true CMS). So, you now have to deal with a knowledge base that is very loosely controlled, and one which would never pass muster as a CMS if you were actually in the market to purchase a new one. Which was never your intention in the first place (and nor should it be).
3. From having your content tightly controlled on your systems (cloud or on-premise), you’ll now have your content stored on someone else’s server in an environment you have no control over.
4. If you did decide to store all your Q&A’s within the chatbot vendors solution, then you now have what’s called vendor lock-in. The vendor will like that, but that doesn’t help you in any way at all.

The lesson to be learned is that you should not be so dazzled by the thought of AI that you thrust yourself into a world of disorder. As always in life, be aware of the Cynefin framework:

In simplest terms, the Cynefin framework exists to help us realize that all situations are not created equal and to help us understand that different situations require different responses to successfully navigate them.

So now we know how things shouldn’t work, let’s look at how it should work.

1. 1. Any true AI chatbot FAQ feature needs to be able to consume answers already stored in your, potentially, many knowledge base repositories. These include:
      • Oracle Content & Experience Cloud
      • Salesforce
      • PeopleSoft Interaction Hub
      • Oracle Service Cloud
      • PeopleSoft HR Help desk
      • ServiceNow
      • Drupal
      • SharePoint
      • WordPress
      • Etc.
   2. Also, the answer for each question could be contained in any of those systems, and your chatbot should know exactly which one.
   3. It needs to be role/group aware. Such that it knows key demographic data about who is asking the question and is therefore able to deliver the correct answer for that person.
      Ex: If a French employee wants to know what the time off policy is, don’t reply with the USA policy.
   4. It needs to be able to understand questions asked in potentially more than 100 languages.
   5. It needs to be able to utilize AI to summarize long answers down to a digestible length.

Doesn’t this sound better? It does to us too. And that’s why we built our chatbot this way. A chatbot that adapts to your content and your data on day one.

To summarize: an AI solution that requires a massive data and content dump of all your Enterprise systems is not a valid proposition that anyone should be considering. Other than the obvious data privacy issues, it’s also not a technically tenable solution. Yet in the rush to market by hundreds of vendors peddling chatbots, there is a general hope by them that all these giant red flags will be ignored.

Our advice is that organizations should be diligent, and only accept solutions that accommodate the scalability and security requirements of large Enterprise systems.

And as we have said in previous blogs, in the world of technology, all that glitters is not necessarily gold.

We hope that this blog has laid out a better way for your organization to take advantage of the next industrial revolution: Automation via AI.

To find out more, please contact us below…