In my previous post I discussed some components of the automation platform specifically for a self-service use case. These are:
A flexible UI for inputs to reduce errors (in our case a conversational UI);
A suite of algorithms able to match what the user is describing with existing automations that you have already built;
The automation engine itself, which executes the tasks.
This time we’re going to take a closer look at the self-service model and explore scenarios where an approval is needed in order for the automation to start to run.
Keeping approvals simple
Because our platform is designed to be used by enterprises, we assume most of them already have Active Directory. We’ve set out to address the most common types of approval requests that should be needed for most use cases. For this reason we’re building two types of approvals: ‘Group’ approvals and ‘Line Manager’ approvals.
Group approvals are very simple. We send the approval request to everyone in the group and the first member to take action closes the approval. At this point our app just syncs any mail-enabled groups from AD; there is no need to create new groups or to manage them inside our app.
We opted for this solution because we didn’t want to add a new layer of group management or to run the risk of someone forgetting to update another database when roles inside the company change or people leave/join companies.
Line Manager approvals are also dependent on the AD structure, using the ‘manager’ field. If you use that field in your deployment we can always calculate who is the appropriate line manager for the user making the request.
Something we’re looking into is quorum approvals (say, 3 out of 5), or veto rights. These have the potential to be somewhat useful, especially with requests that deal with procurement or when multiple people need to approve something. We don’t recommend building this kind of workflow though as standard, because you’ll lose most of the advantages of the automation and break most of the self-service magic.
How to prevent approvals holding up the automation process
People are great at making complex decisions but not super-reliable when they have to deal with an overwhelming amount of tasks. Every time you have a ‘approval’ person involved in an otherwise automated workflow you’ll risk losing most of the automation speed while waiting for someone to approve or confirm an action.
This is another reason we’re going with Group approvals first and we encourage our users to adopt this as a policy wherever possible.
Here’s what else we can do:
Set reminders for pending approval requests. Basically this means sending an email to remind someone they need to approve a request.
Make the approval process dead simple. Once in Nibo, the ‘approver’ is greeted with pending approvals, and they already have an Approve/Reject button. Literally all you have to do is one click per approval request.
Go where the user is. So mail might become too spammy or easily ignored, so why not also go into MS Teams* with an approval card.
Even better, why not send the ‘approver’ a notification to a mobile device*. Something simple with action button on it, so they can literary vote with just one tap.
All these mechanisms are workarounds for a root problem. So why not develop some insights about who causes most delays with approvals, and respond to address that bottleneck. The point is not to shame anyone; we simply want to get the benefits out of an automation platform.
*I’ll go into details about Nibo mobile app and Nibo MS Teams integration in another post.
The future is now
In closing I want to tease you a bit about the future direction we’re experimenting with: concepts like ‘pre-approvals’, or ‘vote only to deny’. This requires smarter automation and some machine learning magic, but it gives the best trade-off between approvals and automation.
As I mentioned previously, the goal with Nibo is to empower people not to replace them. Even if the algorithm becomes super-accurate and fast, a person still has to validate or correct those decisions.