Which legal work should you automate first?

Hi there, I'm Paul. I build AI agents for in-house legal teams at Flank.

A legal ops leader asked me last week which use case to automate first. Not whether. Which.

That one question carries more strategic weight than almost anyone gives it credit for. This is how I answer it, and why my default answer has a second half most people skip.

The first use case is a strategic bet

I was on a call last week with one of our founders and a legal ops leader at a major global industrial company. It was the latest in a run of conversations circling the same question without quite landing it: what should the first use case be? Not whether to deploy agents. They were past that. The harder question was where to point the first one.

I came away thinking about how much judgment sits inside that decision, and how little of it is obvious. There is no out-of-the-box answer. The candidates were spread wide. At one end, work that needs deep legal skill, the kind of thing that shades towards bespoke advisory. At the other, NDA drafting and review, lower complexity, lower blast radius if something goes wrong. And a spread of contracting work in between. Picking from that list felt less like a scoping exercise and more like a strategic bet. I think it is one.

⚖️ It is not one spectrum, it is three

The obvious axis is complexity. Simple work is easier to hand to an agent, so the instinct is to start simple. That instinct is right as far as it goes, but complexity is only one of the things you are trading off.

The second axis is how established the existing process is. On that industrial call, the NDA flow was almost chaotic. No real structure, low visibility for legal over what was being signed and what risk was carried, people improvising their way through it. Simple work, messy process. And the mess is the opportunity, because there is a lot of room to improve something nobody has ever properly organised. Compare that to the more established contracting flows. Easier to automate, in one sense, because the logic was legible. But the improvement you deliver on top of a process that already works is smaller. You can automate the well-run thing flawlessly and find you saved less than you hoped, because the pain was never really there.

The third axis is the one I find matters most, and teams reach for it last. Which broken thing hurts the business the most? Not which one costs the most lawyer hours, though that matters. Which one slows the business down, holds up a deal, makes the commercial team wait. Legal time saved is the metric the legal team feels. Business time saved is the metric everyone else feels, and everyone else includes the people the CFO listens to. When the commercial side starts shouting about how much faster things move, that carries weight a legal efficiency number never will, because commercial drives revenue and legal is too often filed under cost centre. Pick a first use case that makes the revenue side visibly better off, and you have changed who is making the argument for you.

So the real question is not “what is simple.” It is “what is simple enough to do well, painful enough to matter, and visible enough that the right people notice.” Those three rarely point at the same use case, which is why the decision is hard.

⚡ The two camps

In practice teams cluster at two ends, and both have a coherent logic.

The start-simple camp picks NDAs, or first-pass contract review, own paper or third-party. The reasoning is about proving value quickly. Someone above them has handed down a mandate to bring in AI, and they need to show they have done it. A clean, fast win on a low-risk workflow does exactly that. They get something into production, they get a number, they get to report up the chain that it works.

Where it bites them is after the win. You can deliver an NDA agent flawlessly and still have someone say, well, it is only NDAs, who cares, not impactful. I have watched it happen. The work was real, the result was real, and the value still got waved away because the use case sounded small. That is the risk of starting simple: you can win the battle and lose the argument.

The start-hard camp does the opposite. One of our largest customers, a global hospitality company, began with their core commercial contract. Long, intricate, many interlocking parts, decades of practice that lived in people’s heads rather than in any document. Standing it up followed the pattern we usually see: a couple of weeks to a working version, then a few weeks of iteration to get it to the standard that contract demanded. The dialling-in is where the real work sits, extracting knowledge nobody had written down and feeding it back. Even at the hard end this is a matter of weeks, not the multi-month implementation legacy legal tech trained people to brace for. But it is long enough, and visible enough, to test whether a sponsor can hold their nerve.

But when it landed, it landed hard. People were genuinely stunned. And then the demand for more use cases started generating itself. Once people had seen the hardest thing work, they came looking for the next thing, and the next. The roadmap stopped being something we had to sell and became something we had to manage. The sponsor ended up having to slow people down, because the excitement tipped into a belief that the agents could solve everything, which they cannot. The point stands though. Starting hard meant an upfront hit on time and trust, repaid with a roadmap that built itself.

What actually decides it

If both camps work, what tips the choice? I keep coming back to the sponsor.

Not the appetite of the organisation in the abstract. The specific strength of the person championing this, and how much real buy-in they have lined up before they start. Are they working in isolation, carrying the whole thing on their own credibility? Or have they already brought senior leadership with them, above and around them, including the people on the ground who will live with the implementation?

The hospitality company could start hard because the sponsor was exceptional at this. They had buy-in from leadership above and from the senior people involved day-to-day, and they had brought them into the vision early. That is what made the dialling-in period survivable. When the work took time, the sponsor could manage expectations and the organisation could hold the line, because the people who mattered had already agreed it was worth it. Without that, the same build collapses a few weeks in, when the excitement of the demo has worn off and the system is not quite dialled in yet.

So the hard start is not available to everyone. It is available to teams whose sponsor can hold the line. I think that is the single most useful thing to assess honestly before choosing. It is a strategic judgment, customer by customer, and no rule survives contact with the infinite variety of organisations and people you actually meet.

My default, and why

When a GC asks me for a straight answer, I lean towards starting simple.

The thing that kills these deployments is not technical failure. It is trust erosion. If you go big and it takes time, and you have not banked enough goodwill to absorb that time, trust drains faster than you can rebuild it. A simple first use case gets a result on the board early, while the organisation’s patience is still intact.

But starting simple without doing anything else is how you end up on the receiving end of the “it is only NDAs” critique. So the rule has two parts, and the second is the one people skip. Start simple, and clearly articulate the roadmap of what comes next. The roadmap is what defends the simple start. It tells everyone watching that the NDA agent is the first move, not the whole game, and it lets them see the value coming before anyone can dismiss the value that has arrived. The roadmap is not just the thing that follows the first use case. It is the thing that makes the first use case make sense.

🏗️ Why the roadmap compounds

The reason starting somewhere sensible matters so much is that the second use case is far cheaper than the first. This surprises people.

The compounding runs two ways. On the build side, the first agent accumulates the playbooks, the templates, the encoded knowledge, and the organisational context that the next agent inherits. With the hospitality company, once the core contract was handled, a whole layer of peripheral documentation sat around it as a natural follow-on. We were integrating with their CRM, so the data those documents needed was already flowing in.

The part that genuinely surprises customers is the speed of the second and third builds. The hardest part of the first build is not the configuration. It is what you only discover once the agent is live: the gaps that are not written down anywhere, the judgments that exist solely in a senior lawyer’s head, the exceptions nobody mentions because they are obvious to the people who handle them daily. The iteration cycle surfaces and captures that. After a while the agent reaches a critical mass of organisational context, and that context is shared across use cases rather than rebuilt each time.

On the demand side, the compounding is simpler. People see it work, and they want more.

The mistake that survives all of this

The most common mistake I see has nothing to do with simple versus hard. It is choosing a use case that does not actually carry value, because the team never investigated where the value was.

They will not dig into where the highest volumes sit, where the worst bottlenecks are, where the business is actually blocked. They reach for something that sounds useful in the abstract. I have seen a team settle on third-party NDA review because it seemed obviously worthwhile, then look at their own data and find they almost always work off their own paper and receive very few counterparty NDAs. The use case barely existed in their workflow.

Usually it traces back to being led by a demo. Someone sees a capability, thinks it looks impressive, and works backwards from the feature to a use case, rather than starting from their own problems and working towards the feature. It is the same error you see in product design, which is the world I come from. You start with the problem. Always.

This is also why I keep pulling the conversation back to commercial impact. Lawyer time saved is essential, and you have to measure it. But the legal function exists to serve the business, so whatever you improve has to show up as something the business feels too. The use cases that earn the loudest internal support are the ones with commercial weight, because the buy-in from the wider business is enormous when they are the ones who get faster.

There is a test for this I love. Some customers, reviewing an agent that has been running a while, go to the business and ask: what if we took this away? When the answers come back close to hostile, do not you dare, the team knows it picked correctly. That reaction is the clearest signal there is that you gave the business exactly what it needed, rather than something that looked good in a demo.

Where this leaves the industrial call

We have not decided yet. There is another call booked to weigh the options with a couple more senior leaders, which is the right instinct, because the people who need to hold the line on whatever we choose should be in the room when we choose it.

The question we are actually answering is not “simple or hard.” It is two quieter ones underneath. Have we earned enough trust to hold the line if the first thing takes longer than anyone wants. And have we looked hard enough at where this business actually bleeds to know the use case is worth the trust we are about to spend. Get those two right and the spectrum mostly takes care of itself. What I am still working out, call by call, is how you tell in advance whether a sponsor can truly hold the line, because almost everyone believes they can until the build runs long.

✳️