The Bot Chronicles S01E02: R&D definition

Well hello again and welcome to another installment of The Bot chronicles series, our foray into the fascinating world of bot development. In case you're not up to speed on this series, I suggest you revisit the previous episodes.

This article is part of a series. Be sure to check out all episodes here:

S01E01  S01E02  S01E03  S01E04  S01E05  S01E06  S01E07  

Already read these? Super. Let's dive right in then.

Intro into the R&D mindset

The original purpose of The Bot Chronicles series was to involve you in our R&D project for bot development. In this episode we'll cover the scope of our R&D. What do we want to research and why?

Within The Reference we have a thorough R&D submission flow. It's all fine and dandy to start mucking about with new technology (and often one learns a great deal this way) but in the end we're still a business that needs to make money. This means that every R&D request needs to be backed up with a vision on how the learnings from the R&D will help us in the long run. This does not mean they need to "make money". There are plenty of R&D project that in and of themselves don't generate money, but in the long run they need to provide a benefit of some sorts. This can be saving time by introducing new development techniques, learning new skills so we can expand our offer portfolio towards customers, or prepare for the future.

This R&D project is about preparing for the future. Let's be honest here, how many of you, readers, are bulk purchasing Amazon Echo's to stack 'em up at home? And how many of you are interacting daily with their banks, online stores and utility companies through Facebook messenger? My bet? Not a lot.

However, the writing is on the wall, and when implemented properly, we'll see a shift in the use of conversational interactions between customers and companies. When that happens, we want to be in pole position.

So what does our R&D proposition look like?

Initially all is triggered by inspiration and personal interest in chatbots from within the company. Our Solutions team was informed and we started the quest to define our R&D case.

We had some informal meetings where we shared our knowledge and intentions, we checked out presentations and we did some preliminary research to find an answer to these questions:

What exactly do we want to learn in this R&D project?
Turns out, quite a lot:

  • Which bot constructing platforms are out there, and how do we choose the right one?
  • Do we have the necessary profiles for bot development?
  • Which UX and functional methodologies are we missing in order to provide a proper discovery and FA project for bot creation?
  • What will be the contents of our Proof of Concept (POC). Which type of prototype will teach us the most in a short time period.
  • How do you bring a bot to the market?

Question 1: Which development platforms are out there and how do we choose the platform(s) we'll be working on?

To answer this question is that we will be creating a Platform decision grid. The grid will consist of all kinds of features (which we call a metric entity). For each metric we'll need to decide what the possible values are, how important we find the metric, and how it scores.

Take languages for example. A Multilingual bot is quite important not only here in Belgium. So we defined multiple metrics on this topic:

  • Can the bot converse in multiple languages?
  • How robust are the NLP (Natural Language Processing) features of the platform in multiple languages?
  • Localization: how easy is it to build the bot in multiple languages?
  • ...

Each of these metrics will have values, an importance weight (helps us to define how important we value this feature overall) and a score column. We'll cover this diagram later in this series. For now it suffices to say we're looking at roughly 35 different metrics going from languages over to AI and NLP to platform complexity, supported development languages, pricing and much more.

Question 2: What makes up a Chatbot devteam? Can we tackle this with the existing profiles within the company?

This question might seem a bit weird. We are a development powerhouse who tackles all kinds of implementations from international multi-site Sitecore platforms to mobile applications to API stacks. If we need a profile, we will have it right?

Turns out, we don't really know what the required profiles are. We can read up on this, but we'll need to learn. Developers, sure. But bots are highly conversational. We'll probably need copywriters. Heck, some go with actual script writers. And what about the bot personality? Who will define that?

Question 3: Which UX and functional methodologies are we missing in order to provide a proper discovery and FA project for bot creation?

If we're going to start building bots for our clients, we better know how to tackle this process. We have a trunk load of methodologies we use during the discovery phase of our projects. We implement a batch load of other ones during our agile development phase. But here too we're confronted with some unknowns.

We'll need to know what methodologies and tools we can re-use or which ones we need to re-invent in order to provide answers to these questions (again with the questions, I know, fun isn't it?)

  • For whom are we building a bot?
  • Who is our bot?
  • How do we define what our bot does?
  • How do we test and evaluate our bot?

We already know a lot of the answers here, but there are also some unproven assumptions. We will discuss more about this in another episode.

Question 4: What will be the contents of our POC? Which prototype will teach us the most in the shortest time possible?

In development, it's always a good idea to work with some kind of real project. It's the best way to discover stuff. You bump into all kinds of unexpected challenges, and they need to be fixed.
On the other hand, you don't want this project to become so complex it takes you months to actually have some sort of working prototype. An agile approach helps, but still, it's a good idea to know which direction we're going with the prototype.

To make it as good as it gets, we're reaching out to a company that is willing to work together with us on this R&D project. This will give us the most realistic environment to perform this POC. A real business with real goals and challenges, with real customers who have real aspirations and expectations and most importantly, real feedback.

We'll start off with a very limited scope. We call this our Minimum Viable Product (MVP). A product with just enough features to gather validated learning about the product. This allows us to get something out there as fast as possible, so we can start learning about it, and adapt our functionality accordingly. This can be a very basic straightforward botflow, without too much AI and NLP requirements.

In quick iterations we'll learn more about this MVP and with the newly gathered insights we'll continue to build out new features. A very known approach in prototyping.
I see you're bouncing with excitement to get to know the prototype we chose to work on... Well, tough luck. You'll soon get to know it, but allow me to keep the lid on this one for a short while longer.

Question 5: How do you bring a bot to market?

Since we're creating this POC with a real company, we'll need to discover how to market the end result to the customers. We'll bring in our own marketing department and see what the best practices and pitfalls are when bringing a bot to market.

Now what?

Pfew. Quite a lot to take in isn't it? But now what?
Well, we're currently locking in our partner in crime for the POC. As soon as that is done, we'll get this thing firing on all cylinders. So don't be a stranger and drop in from time to time.
If we peaked your interest in bots for your own company, be sure to let us know.
Missed out on the Bot Chronicles previous article? Read it here.

Don't miss out

The Reference has its office in the heart of Manhattan.
“I want to wake up in that city that never sleeps, and find I'm king of the hill, top of the list, head of the heap” – Frank Sinatra