Automation has been at the core of our concerns in Hub Collab since the very start. Within our structure, we have automated hundreds of processes across many business verticals. BPA (Business Process Automation) includes all forms of “fast” business process automation. This branch generally completes the offer linked to BPM (Business Process Management) platforms: the processes supported in BPM platforms often turn out to be quite heavy, with the level of criticality largely justifying the cost of these platforms and the investment induced by their implementation. On the other hand, for more operational and less critical processes, it is more reasonable to use lighter platforms, LowCode/NoCode, commonly known as BPA.

Where is the RPA (Robotic Process Automation) in all this?

It mainly allows you to automate manual tasks via scripts/bots that simulate the human hand. It differs from its two big brothers (or big sisters, as you wish!) by the fact that it is directly linked to the graphical user interface of the tools, whereas BPA and BPM platforms usually connect at the API level. That being said, the interaction of these 3 platforms can automate any type of process!

And if we were to complete the picture, we would classify all this in the category of DPA (Digital Process Automation). Are you still with me?

Business processes typology


And what is the NPA?

When you automate a process via a BPA or BPM platform, in the majority of cases you have either a form as input, a document to submit, or a database entry of some form of data. This input triggers a workflow to perform some automated or manual tasks.

Well, NPA is all about automating your processes, using natural language where possible. You will not, of course, be entering forms that require you to respect complex input formalities, validation rules (etc etc,…), but you will simply express your request via natural language (written or spoken), to a chatbot, which is available within your daily tools.

After processing your initial request, the bot will ask you follow up questions to complete it (in case if there is information missing) in order to execute the complete scenario.

So to make it simple: NPA + NLU = NPA

The majority of today’s BPA tools work on no code basis, using dragNdrop editors. The No-Code strategy of these platforms has made their success. It seems obvious that a NPA platform will also have to respect the same rules: easy handling, simple integration and painless improvement process.

Towards a new type of automation

In order to succeed in automating processes in natural language, beyond the comprehension of user requests, it is necessary to be able to develop a dialogue between the bot and the user via natural mechanisms of human language, for example open and closed questions and some elements of logic in order to design decision trees.

In the discussion that you are going to conduct with a human interlocutor, the latter will ask you a set of questions until he has in the possession all the information that will enable him to deal effectively with your request. For the bot it should be the same, he just needs to be able to retrieve each and every piece of information, whether in a structured or unstructured discussion. Once this problem is solved, you should be able to interconnect your bot with the various tools of your IS.

NPA is not a substitute for BPA, it is its extension!

The leave request comeback

The famous one! In my past life as an evangelist at Nintex, I must have demoed it hundreds of times! It’s very simple, it’s often represented by a data entry form that will send an approval to the manager and then populate the HRIS of your choice with the data collected.

In reality, you will need to know the address of your form, submit your request via a form, which is connected to a workflow that will carry out its validations.

Wouldn’t it be easier to just make your leave request via a simple bot in natural language? Whether on your usual IS site or from your mobile phone via a centralised app, or even from your Alexa/Siri/Cortana…?

The complexity for this kind of system is to understand the subtlety of the language. You should be able to turn your request (and be understood by the bot) in many different ways :

– I want to take leave from the 4th to the 6th of January

– I want to take my holidays on Christmas week

– I want to take leave from next Monday for 4 days

– Taking leave on the first week of March

I’ve been testing a lot of bots, and I like to look for these kinds of scenarios (including date ranges), as this directly shows the intelligence of the bot: In the case of ” I want to take my holidays on Christmas week”, what could be more frustrating than being told, “I see you want to take your Christmas week off, from what date?”? Many bots operate with approximate scores and more or less good results to identify the intention of the demand, but often with poor management of the entities (i.e. parameters). From the moment the intention is identified, the scenario unfolds and can lead to inconsistent behaviors (if the wrong intention has been found) because the engine of these chatbots would not allow to manage these different cases.

IronMan had Jarvis, what about you…?

Hard not to use some Marvel references here: Jarvis is Tony Stark’s virtual assistant who can do almost anything his creator asks of him… Everyone’s dream, isn’t it?

Imagine how much time you could save if instead of opening your CRM to search for the order number to enter it in your ERP to view its status, you could simply ask Jarvis…..

In my daily life, I switch between 5 to 6 tools, but since last the one i’ve been using more often than others is Microsoft Teams. It is always on. Naturally, it is in Teams that I would like to be able to make the requests to my bot, and I would even go a little further… depending on which teams channel I am in, I would like to be able to make different types of requests. I would like to be able to make my holiday requests in my personal HR channel in Teams. I would like to be able to ask for a customer’s sales status (interactions with Dynamics365 or SalesForce) in the Sales Teams, and I would like to ask my basic questions about GDPR (on which I don’t want to share my interactions) in a 1-To-1 conversation with my bot buddy!

And obviously, because a bot that just automates things only would take us halfway there, it should also be able to access knowledge bases thus combining information retrieval with the automation scenarios in natural language…

What about Hubi?

Hubi.ai was created to meet the following needs:

  1. Automation in Natural Language on a native NLU engine
  2. Unlimited number of knowledge bases
  3. Unlimited number of scenarios
  4. Scripting tool / automation in Drag N Drop mode
  5. Multilingual off-the-shelf knowledge bases (thousands of questions on dozens of areas of expertise provided OutOfTheBox)
  6. Multi-channel (Teams, SharePointOnline, Web)
  7. Contextualisation of bots (choice of knowledge sources and scenario by communication channel)
  8. Securing connections per service account and/or per current user hosted on Azure
  9. NO ADDITIONAL COSTS FOR AZURE CONSUMPTION (0, Nothing, Nada, Nichts, Rien!)

We have created Hubi to be as simple as possible, as cost-effective as possible and above all to avoid any surprises in terms of extra consumption costs.

Alexandre had led several development teams, before joining Nintex, a world leader in process automation, as an evangelist for Western Europe. He then created Hub Collab, a company specialized in process automation and Microsoft Cloud platform. He is also the founder and CEO of Hubi.ai.