The one thing your bot will fail without

If you don’t have this, it won’t work…

Having built several bots ourselves, there is one thing that we’ve noticed that is markedly missing that prevents bots from being particularly useful: Bot-ready data.

We’re not talking about little hacky experiments where we run fun bots stringing some open APIs together in a GUI. We’re talking enterprise level bots, expected to solve some customer problems and drive business results.

There are 5 roadblocks in getting to bot ready data:

  1. Data availability — Does it exist?
  2. Data comprehensiveness — Does it include everything?
  3. Data cleanliness —Is it readable by machines?
  4. Data compatibility — Is it useful for bot workflow tasks?
  5. Data openness — Can it actually be used?

Let’s define data in the bot sense. Data for bots is intended to lead to some sort of resolution, such as answering a question or completing a transaction. Hence, data cuts across types like dynamic updates (parcel tracking statuses for example), generally static content (FAQs), system information (inventory stock levels), and temporal data (campaign launches or limited promotions), among others.

What makes these difficult to be used in today’s context?

1. Data availability: Is the data available in the first place?

As an example, sometimes people ask why a particular staff cannot be found in a staff directory. Often, the main reason is that the person in question simply wasn’t added to the directory in the first place and hence this data was never available.

Another would be information on new products, or perhaps an offline guerilla campaign. Data on where users may find roving trucks, for example, may not be available anywhere, so it would be impossible for the bot to query it. Being able to cater to data availability issues across the organisation requires strict data input processes to be put in place, which doesn’t exist yet in many organisations.

2. Data comprehensiveness: Is data only updated for some instances and not others?

Related to availability is completeness, which is what happens when some data are kept updated while others are not.

For example, sometimes people ask why bots show websites instead of giving a short answer; the main reason is almost always that web pages are often updated, even when FAQs or blurbs are not.

3. Data cleanliness: Is the data actually machine readable and usable?

In reference to websites, which are mostly maintained so that humans can read them, there are significant technical challenges in accurate informational retrieval (IR) from sources that machines can structure and respond to queries with.

Notwithstanding these IR tasks, machine comprehension in knowing which of these chunks of answers to select as the right answer, and displaying them in a palatable or dialog-driven format, is harder than most people realise.

4. Data compatibility: Is data in a format that can be used for bot workflows?

Having data sitting around in various forms doesn’t necessary mean that they can be used for meaningful resolution. For example, having access to CRM+ERP+Support+Call Centre data can be useful for analysis, but they tend to be static or stuck in their respective systems.

Some of these data are not structured to be compatible with bots. For example, having data displayed in obscure code with lots of data tags that need to be stripped away before they can be displayed, will require significant processing before they can be manipulated and shown in natural language or structured cards to end customers, and vice versa.

5. Data openness: Can the data be used even if it exists in the right format?

Hence, the final question in our examination of internal data for chat automation is, can all of these data actually lead to a resolution of conversations? Since many of these data sources are meant for capturing information as systems of record, they require data pipelines that can enable data to flow both in and out, as connectors between the data and the workflow.

At the very least, there needs to be a send and receive API layer that can ask your systems for their data, and update the systems with new information that come in from conversations. The next step would be to set up actual actions that can be taken to resolve customer issues — “How do I change my details or plans in the system”, for example — and allow conversation states to take actions and trigger workflows.

Sometimes, this is a matter of time (things are too complicated to open up quickly); sometimes, it’s a matter of reluctance (let’s not change the status quo); other times, it could be a multitude of organisational or industry factors that prevent the open flow of data from one system to the next.

The metaphor for data & AI adoption and bots today is like, back in the day, people asking why they need a website when the real issue was why they needed to go digital. Now, it’s all about how to turn current data sources into machine-readable and -usable data.

Building a bot hence becomes less of building a bot, but rather requires a larger effort to catalog and enable the flow of data through organisations. With the view of how important techniques such as machine learning will be to organisations going forward, this becomes a necessity that needs to be discussed in parallel with conversations around bots and what they can do for customers.

Since we work extremely closely with our clients and these problems at KeyReply, we are seeing patterns around how to augment and resolve some of these issues around data and its applicability beyond bots. If you’d like to have a chat, we’re always open to talking about hard problems