help desk software
+(800) 286-4232

There was a time not long ago when the back office was a cacophony of keys tapping, mice clicking, and workers groaning. But alas, those days are gone for RPA has left the din and drudgery of manual data entry to the ash heap of history. Today, sleek bots hum along with precision, transacting business at a pace unheard of just a few years back. And they transact their business flawlessly.


Hardly. Reality check. Sure, RPA is rapidly changing the face of systems integration and automation for the better. However, no matter how much we plan, train, and test our bots, the unbridled entropy awaiting them in production guarantees there will always be automation failures. Our goal as Process Designers and Automation Architects should be to minimize these failures where possible, or at least minimize failure resolution times.

Beyond an inaccurate project specification, automation failures are usually caused by one of the following factors:

1.      Data Failure – the format or structure of data coming into, or going out of, the automation has changed, thus breaking the automation.

2.      Environmental Failure – something significantly has changed in the bot’s execution workspace such as: an integrated application change, desktop hardware or operating software change, introduction of conflicting software, etc. 

3.      Connectivity Failure – Inconsistent or spotty network throughput generates erratic results or frequent timeouts.  

4.      Business Rule Failure – a transaction contains a data condition that violates a defined business rule (e.g. an invoice‘s total amount does not match the amount stated on the authorizing purchase order).

With regard to the first three failure types, usually the best an Automation Architect can do within the automation is: clearly identify the problem, back out of it as gracefully as possible, and accurately document the issue in a transaction log so it can be quickly rectified and the automation rerun.

On the other hand, business rule failures are a bit different. When an automation rejects a job because of a business rule failure, the job is usually sent to a rejection queue where it will eventually be manually reviewed by, dare I say, a human. Well, if the automation is executed during “on hours”, why delay the process when you have all those human reviewers available to help? This is where incorporating user prompts into your automation can be quite valuable.

At RatchetSoft, our Process Designers and Automation Architects follow a well-honed methodology when building out an automation. One of the methods contained within when defining the project specification document is to make sure they “spec the negative”. When users describe a process, they usually describe a process where all things work as expected. However, “not as expected” happens frequently. For example, how often have you seen this issue; “Go to the vendor drop down and select the vendor from the list”. Well, what do we do if the vendor is not already in the list? Do we have a method to add new vendors? Should that method be automated, or should the job be rejected so a knowledge worker can add the vendor manually and rerun the automation? Do we create a new vendor stub entry so the automation can continue and backfill with the rest of the vendor data later? In all these cases, if a human reviewer must get involved, why not involve them at the point of need via a user prompt. A user prompt is a real-time help request generated by a bot to a human reviewer for assistance with a transaction. User prompts usually follows this pattern:

1.      Bot encounters a negative condition that it has not been coded to handle.

2.      Bot generates a message (prompt), to a human who possesses the knowledge to handle the condition. The person or group to which the message is sent is determined based on a defined “user skill”.

3.      Human accepts the prompt and remotely takes control of the bot’s desktop to gather more information regarding the transaction’s context.

4.      Human addresses the prompt in whatever fashion deemed appropriate.

5.      Bot is given the option to “learn” what the human did to clear the negative condition so it can be used as a supplemental rule to process future transactions.  

To see a video example of a user prompt, click here.

As you can see, user prompts can be quite valuable when handling negative conditions because it allows the reviewer to address the condition from within the context of the running automation. This helps moves things along better than just outright rejecting the transaction thus forcing the reviewer to research the problem later. However, if you decide to employ user prompts into your automation, you must remember to consider the following:

1.      Always define a reasonable timeout period for a user prompt. You don’t want to tie up a bot waiting for help that is not coming on a timely basis.

2.      Make sure you understand the skills required to address each prompt. You don’t want to spam people who can’t help.

3.      Be careful about the supplemental rules you allow a bot to learn. Not all fixes should be learned and institutionalized.

4.      Learned rules should be periodically reviewed to determine if they should be: migrated as a coded rule, kept as a supplemental rule, or deleted.