The list is longer than the year is
By the time a managing partner or a COO sits down to actually pick, the list has usually written itself over several months. Billing review, because write offs keep sliding past deadline. Proposal drafting, because the same three people rewrite the same boilerplate every week. Contract intake, because nobody can say how long a matter has been sitting in the queue. Research support, because the associates spend Tuesday afternoons doing something a machine could plausibly do in ten minutes.
Every one of these is a real candidate. Every one has a champion somewhere in the building who is certain it should go first. And every one of these conversations tends to collapse into the same unhelpful question: which workflow is most exciting to automate. That is the wrong question. The right one is which workflow is safest to get wrong while you learn how to do this, and which one pays for the mistake if it happens.
This is a prioritisation decision, not a model decision. Firms that get this stage wrong do not usually fail because the AI was weak. They fail because they picked a workflow where a bad output looks like a bad decision to a client or a regulator, on their first attempt, before anyone in the firm has built the muscle to catch it.
Score the candidates on what a mistake costs, not on how much time it saves
Time saved is the number every proposal leads with, and it is close to irrelevant to the sequencing decision. A workflow that saves forty hours a month and fails visibly in front of a client is worse to start with than one that saves ten hours a month and fails quietly, gets caught, and gets fixed before anyone outside the team notices.
Score each candidate on three things, using the four examples above as the working set.
- What a wrong output looks like, and who sees it first. Billing review: a wrong write off recommendation gets caught by the biller before it reaches a client invoice, if the review step is real. Proposal drafting: a wrong claim about the firm's experience goes out under a partner's name to a prospective client. Contract intake: a misread clause sits in a queue where a human eventually reads the contract anyway. Research support: a fabricated citation, if unchecked, goes into a memo a lawyer signs.
- How far the output travels before a human sees it. Some of these workflows have a built in stopping point. A drafted proposal cannot leave the building without partner sign off, because that is already the rule today. A billing exception flagged for review sits in a queue a supervisor already checks. Contrast that with a workflow where the AI output goes straight to a client or a filing, because the human step that used to be there gets skipped once the tool feels reliable. That skipping is the actual risk, not the tool.
- How reversible the damage is. A write off error is a number that gets corrected on the next statement. A proposal that overstates the firm's track record to a prospective client is out there, read, and remembered. Reversibility is not about how bad the mistake feels in the room. It is about whether it can be quietly and completely undone.
Run this scoring honestly and the four examples rank themselves differently than most firms expect. Contract intake and internal research support tend to score as lower stakes: both sit behind an existing human step (a lawyer reads the contract, a lawyer signs the memo) that catches most errors before they matter. Billing review sits in the middle, because a review step exists but sign off pressure at month end tends to erode it. Proposal drafting, done wrong, is the highest stakes of the four, because the output goes to a client under a partner's name and the firm's credibility is the thing at risk, not a number on a ledger.
What the workflow needs before it is a candidate at all
A workflow does not qualify for a first build just because it scores well on risk. It also has to have the raw material a system needs to work.
Concretely, before any workflow is a real candidate, check three things.
Is the source material actually written down somewhere, and is it current. Contract intake works because contracts exist as files. Proposal drafting works because past proposals, templates, and pricing precedent exist as files. Research support only works if the firm's own precedent memos and prior work product are findable, not scattered across individual laptops. If the honest answer is that half of this knowledge lives in one partner's head, that is not an AI project yet. It is a documentation project that has to happen first, and it usually takes longer than the firm expects.
Is there already a review step in the process, or does one have to be invented from scratch. Every one of the four workflows above should keep a human checking the output before it counts, at least at first. The question is whether that person already exists in the process today, doing something close to this job, or whether the firm has to create a new role and a new habit. Adding review is possible. It is just an extra cost to the first project, and it should be counted as one rather than assumed away.
Can the firm tell, in plain terms, when the system is wrong. This sounds obvious and it is the thing most pilots skip. For billing review, wrong means a write off recommendation a biller would not have made. For proposal drafting, wrong means a claim about the firm's work that is not true or not current. If nobody can state in one sentence what a wrong answer looks like for a given workflow, the firm cannot build an evaluation for it, which means it cannot tell if the system is working after the demo stage. That is the gap between a pilot that impresses a partner in a meeting and a system that keeps running six months later. A separate post on this blog, why your AI pilot demoed well and never shipped, goes into what closes that gap once a workflow is chosen.
Sequencing, not selection
The framing that actually helps a firm move is to stop asking which one workflow to automate and start asking what order to work through the list in. Most firms have three or four legitimate candidates, not one. The decision is which one goes first, which goes second once the team has learned something, and which one waits until there is a review process mature enough to hold it.
A reasonable order for a firm with the four candidates above: start with whichever of contract intake or research support has the better documented source material, because both sit behind an existing human check and a wrong answer there is caught before it travels. Use that first build to learn what evaluation, review and exception handling actually take in this firm specifically, not in general. Bring billing review in second, once the firm has a working review habit to lean on. Leave proposal drafting for later, once the firm has direct evidence, from its own first two builds, of how the system fails and how reliably its review step catches it. By the time proposal drafting is on the table, the firm is not guessing about whether review works. It has watched it work twice.
This order will not be right for every firm. A firm whose billing exceptions already get caught reliably by a strong month end review might reasonably run that one first, because the safety net is already proven. The point is not the specific sequence. It is that the sequence should be set by where a mistake is cheap and caught, not by which workflow has the most enthusiastic sponsor in the room.
Where we come in
The decision a managing partner or a COO owns here is not which system to buy. It is which workflow to trust with a first build, in what order, and what has to be true about review and documentation before that workflow qualifies. Alppoint AI works through this scoring with firms directly, then builds the chosen system end to end, as a defined workstream, or alongside an existing AI or engineering team, so the system lands in the firm's own environment as something they own and run.
