5 Questions to Ask Before Automating High-Stakes Business Workflows

Many automation projects fail for the same reason - when people think of automating a task, rather than approaching the process with fresh eyes, they ask: "What happens when this breaks?" The two most common failure modes for RPA projects and beyond are: you waste resources building out a faulty process, or you fail to notice the errors until it's too late.

To help avoid those pitfalls, consider these questions:

Is the task rule-based or judgment-based work?

There are two categories of work that determine the viability of automation as a tool and its expected value: rule-based work versus judgment-based work. Rule-based work follows a consistent set of instructions for processing data. Judgment-based work requires analysis of context or information that cannot be distilled into a consistent recipe.

Legal professionals have a mountain of rule-based work that has traditionally been handled manually simply because it has not had the necessary attention to process detail. Legal contract review against a standard playbook, document classification, calculating deadlines based on a docket, or tracking the status of a docket are all pattern recognition exercises that fall under the category of rule-based processing. This is what ai workflow automation for legal teams often finds itself trying to automate first, because the inputs tend to be reasonably structured, and the outputs, although occasionally nuanced, generally have a limited impact on the overall matter if a mistake takes place. Settlement strategy, privilege analyses or risk opinions tend to remain in the domain of the attorney. Not because it is impossible to attempt with automation, but because the ramifications of a mistake cut both ways and judgment calls tend to require a named responsible professional.

Are your inputs and outputs consistently stable?

Automation cannot fix a disorganized process - it will simply execute the errors faster and with less insight into what went wrong than humans might manage on their own.

If there are significantly more variations of your contract intake process than there are standard ones, or your template changes significantly every few months depending on who prepared it, you likely have a process-mapping issue before you have an automation issue.

Document your current process as-is as a baseline for improvement before you make any upgrades to your tech stack. Identify how often an exception occurs within your processes. Exceptions should be the minority if you hope to achieve true automation gains, and if they present the majority, consider revising the upstream procedure before you attempt to revise the downstream procedure.

What is the cost of failure, and where do you have human checkpoints?

Ask yourself first how much it would cost if the model failed and no one noticed for two weeks. For anything that touches on a regulatory filing, client data or a contract, the answer to this question is almost certainly, "too much," which means that your audit trail matters twice - once to detect a latent failure before it does significant damage, once to demonstrate that failures were not deliberate in the eyes of a regulator. In criminal law, as in SEC investigations, the defense often looks to whether violations were done knowingly or with reckless disregard for the law - the ability to demonstrate that your AI was built in good faith helps tremendously.

In legal matters, attorney-client privilege is often at the heart of privilege analyses and the determination of whether documents fall under the protections of FRCP 502 or not. One false routing of a privileged email into the wrong distribution list could be enough to destroy a privilege entirely. Wherever the model ends up sending data or documents, the escalation procedures need to be clearly defined for when human judgement is needed to intervene.

Does the toolchain support your compliance obligations?

A workflow tool that is appropriate for the marketing team might not be appropriate for legal, for reasons specific to your industry. Take cloud-only tools as an example - many of the leading workflow tools today are cloud-only, when most legal data is not allowed to leave a controlled environment. Before testing that free trial on some sample data, ask yourself important compliance questions first. Can we test this tool in our environment? Do they even have an on-prem option?

How will you know it worked?

Choose one metric to focus on exclusively, rather than being pulled in several different directions at once.

Decide what you want to improve before the process improvement even starts, and certainly at least six months before whoever is selling you their "legal tech solution" asks you what you need. If you can settle on a metric while you're still at the start, you're far more likely to actually hit it when the time comes to measure.

Choose the lowest risk, most impactful version of a workflow you can find and run it as a pilot for six months. If the metric you settled on has not changed for the better by the end of the pilot, consider stopping the process.

Once you've improved that one metric, look to expand that same process to similar procedures so you can scale both the gains and the changes you're making to other team members, to your overall training and change management processes, and to the quality assurance procedures for that process family. At this point, rather than investing the budget gains from your improvements into the next shiny thing that sales wants to sell you, take a breath and decide on the next metric you'll want to work on. You can form a continuous feedback loop.

Finally, accept that you are not as unique as you feel - and that, actually, most in-house legal professionals do not operate in nearly as unique an environment as they currently feel they do.

No one is arguing that every legal professional's job is the same, or that there aren't certain functions that a law firm or corporate legal department might do better than anyone else.

There's value in doing the right five percent of your job really well, and less value in trying to automate everything, badly