How to Find Your First AI Build in Staff Interviews

A paralegal had a little over two thousand scanned images to turn into PDFs. She did it in batches, by hand. It took about two and a half hours.

Nothing about those two and a half hours needed a law degree. It needed patience and a tolerance for repetition, from someone whose time is worth far more than that.

She was one of nineteen interviews we ran at a multi-office law firm earlier this year, over seven weeks, across eight departments. In another office a paralegal described working through disclosures that can run to tens of thousands of pages, one page at a time. On another team, a few hundred files from a single client production took several hours just to rename and index.

Different offices, different people, different cases. The same job: naming, dating, sorting and indexing documents so they can be found and produced. Ten of the nineteen interviews named it as a major drain on the week.

The count is the finding

One interview is an anecdote. A good interviewer can make any anecdote sound urgent, and a frustrated person can make any irritation sound like the biggest problem in the building. If discovery is nineteen well-told stories, the most vivid story wins, and the most vivid story is rarely the most expensive one.

So we count. Every finding in our report carries the number of interviews that raised it, written as a fraction. Document indexing: ten of nineteen. Pulling deadlines out of court orders and entering them into two or three calendars by hand: seven. Coordinating dates with outside parties: six. Rebuilding routine documents from scratch because there is no shared template system: six.

The fractions do two jobs. They stop me from promoting the problem I personally found most interesting. And they let the client check the work. A leader who reads "ten of nineteen" can ask which ten, and we can show them.

Ten of nineteen is not a preference. When half the people you spoke to, in separate conversations and separate offices, describe the same task, that task is costing more than anyone has added up, because nobody sees more than their own share of it.

Why the count picks the first build

The first build has a narrow job. It has to be seen working by a lot of people. It has to work without anything else being fixed first. And a person has to be able to check its output quickly, because trust in the second build is earned by the first.

The count answers the first test on its own. A build that helps ten teams is seen by ten teams.

The other two you check by hand. Indexing is self-contained: a batch of files goes in, and named, dated, categorised files come out with a master index. It does not need the case management system cleaned up before it can run. And a draft index is quick to review. The worst case is an index that needs a few corrections, which is still faster than building one from nothing.

So the report put it first. An agent that reads a batch of case documents, titles each one from its content, pulls the date, sorts it into the firm's standard categories, applies the numbering, and produces the index for a paralegal to check before anything is used. Scoped at about three weeks, with one team first and the rest of the firm after.

What the count does not decide

Counting sequences the work. It does not overrule the people who run the firm.

Leadership's top priority going in was intake, and intake matters a great deal to any firm's growth. It came up in five interviews, which is a real signal. It also depends on data work in two systems that has to happen first, so the roadmap placed it after that work rather than at the front. The priority did not change. The order did.

A count also measures how many people feel something, not how many hours it costs. So every high-count item gets sized as well, and some findings are judgments rather than counts. Our read of what six teams described is that most of the firm's routine legal documents could be templated. That is our conclusion from the interviews, not a figure the firm measured, and I would want it tested on real documents before anyone relied on it.

And the highest count in the whole report was not a build at all. Every one of the nineteen interviews surfaced some piece of work that only one person knows how to do. No agent fixes that. The first step there is writing down what those people know, and the report said so in plain terms.

Doing this yourself

You do not need a consultant to count. You need discipline about recording before you rank.

Run the conversations one at a time, with the people who do the work, and ask each of them to show you a real example on their own screen. Write every problem on its own line with who raised it. Do not merge or rank anything until the last conversation is done.

Then count. Anything raised by a third or more of the people you spoke to gets sized in hours a week and people affected. Take the top of that list and ask two questions. Can it run without fixing something else first? Can a person check its output in a minute? If both answers are yes, you have your first build, and you have the fraction to show anyone who asks why.