Having a somewhat pseudo-intelligent, Q&A-like interaction with a software application is something we have been doing for quite a while now. Think of virtual agents you encounter on several e-commerce platforms, more advanced bots on collaboration platforms, like Slackbot, and even more sophisticated ones helping you to make real transactions, are getting more and more popular.
In a way, all bots share the same DNA (the building blocks of what generally makes a conversational bot):
As you can see, the main purpose of the bot is "having the conversation". The key components of the "conversational continuum" are commonly built around Interaction, Interpretation and Distribution. This design enables the fundamental communication mechanisms for us human beings to talk with bots. The element of interpretation - that point in the conversional flow where the bot does the real "sense-making" - is currently a very hot topic, as this is one of the key artificial intelligence (AI) and machine learning playing fields.
It is very interesting to explore how a conversational bot could help us with our day to day work and do the tedious, non-value adding work for us. We all hate searching and retrieving documents on that immense company intranet, booking our expenses or requesting leave on the HR self-service portal, or adding a new customer to the time-absorbing CRM system. Imagine the following scenario:
We might not need sophisticated AI or machine learning to realise this, as it could be achieved with the fundamental building blocks we already have available. In other words, immediate business value is ready to be reaped.
Let’s have a look of how most bots now find more or less senseful answers to your questions:
* Human:
- ‘Hi Bot, may I ask how many hours I have worked this week on project X?’
* Bot:
- Message contains: ask, hours, worked, project.
- Best matching response: retrieve amount of hours worked in project X in user’s agenda.
- Return result.
- Ask responding Do question.
So, in fact, a bot sits on a huge index (mapping) of possible actions to sets (arrays) of questions (note: this is quite different from NLP-powered chatbots, as these kind of agents can have more human-like discussions).
Instead of providing the person with the URL for the self-service portal (the scripted answer to my "question") where he or she can register hours, to build executional conversations, the bot could actually ask me "How many hours would you like to book?" (or even automatically check my agenda, like in our example) and then book the hours. The technical complexity to realise this might not be so challenging.
Think of the following mapping:
That's quite straight forward. So what real new capability do we need to add to the bot’s architecture to make this work? Basically, we need to enable the bot to talk to a piece of middleware, in the event a business flow execution needs to performed. This middleware, like a general service bus with a service catalog, is keeping a list of process endpoints that trigger business flows. We link the related endpoints with the conversational logic, as show in the table above.
This concept assumes that ideally there is a process automation capability in place, that picks up the task of the actual process execution while being responsive to the requesting party (the middleware that is acting on the bot’s behalf). This capability can be implemented by a BPMS platform.
What is of key importance in the realisation of the concept above, is the principle that needs to be governed not to build the process execution on the bot level or by means of adding bespoke technology somewhere to the bot-solution architecture (following the important guardrails of "Separation of concerns").
Let’s recap using our basic model:
One could imagine that once the executional not-concept gets track with its users, the demand for more executional scenarios will follow quickly as it solves a key problem with a strong business case:
Amount of time spent on booking hours per person per week: 25 minutes
Number of persons booking hours: 250
Estimated saving per week (250 x 25): 6.250 minutes / 104 hours per week
Per year (of 40 weeks): 4.167 hours at average cost of 25 EUR = 104.166 EUR.
When this happens, you need to ensure that you have an agile capability in place (for instance BPMS, optionally enhanced by RPA systems to overcome the legacy-integration challenge, see this article) in order to be able to follow demand and deliver more functionality quickly. The added value would be impressive, as it would liberate a lot of people from the repetitive, non-core and irrelevant jobs that they have to do day by day, freeing them up for core activities.