Build anything that watches work happen in a law office — time capture, document filing, deadline extraction, a board of what’s in flight — and sooner or later you’ll be answering one question over and over:
Which matter is this?
It sounds easy. It isn’t, and the way most systems answer it goes wrong in a way that’s peculiar to our line of work. Every other kind of software teaches the same instinct: a system that usually gives you an answer beats one that sometimes shrugs. Coverage is a feature. A blank field looks like a failure.
In a law office, that’s backwards. I got it wrong first, and here’s the principle I ended up building everything around:
An unattributed entry is honest. A confidently wrong one puts a deadline on the wrong file or bills a client for someone else’s work.
(Every example in this article is invented. No client information, matter numbers, real captions, or real data appear anywhere in it.)
Mistake one: looking at a file isn’t working on it
The first time-reconstruction tool I built did something that seemed obviously right. It read through a work session and looked for any matter folder path mentioned anywhere in it. If a session touched the Anderson folder, the session was Anderson’s.
Here’s what that gets you.
Say you spend a Tuesday building an internal system. No client work at all. Somewhere in the middle you open a document in a client folder to see how a caption was formatted, because you want to copy the layout. You read one file. You close it.
Under that rule, the whole Tuesday now belongs to that client.
That’s no rounding error. In the case that taught me this, a multi-day infrastructure project landed almost entirely on one litigation matter, and that matter’s reconstructed time came out roughly twelve hours too high. If that had gone into a draft invoice and nobody caught it, a client would have gotten a bill for somebody else’s work.
The fix is one line with a lot of judgment behind it:
Only writes count.
Opening a file in a matter folder isn’t evidence you were working on that matter. Editing, creating, or saving a file there is. Looking something up isn’t labor. Once I ranked the evidence that way, and threw out every session whose only tie to a matter was a read, the inflation stopped.
Mistake two: surnames
The second version of this mistake showed up in calendar matching, and it teaches more, because the fix looked so reasonable.
The goal was to tie calendar events to matters so the board could show which upcoming hearings had work behind them. People type the event titles, so the obvious move is to match on the client’s last name.
First try. Match on surname. A hearing captioned with a common Minnesota surname matched a client with that surname — one random client out of the many who share it. Wrong matter, high confidence, and nothing to tell you anything had gone wrong.
Second try, the “improvement.” Only match surnames that belong to exactly one matter on the books. That kills the ambiguity, and it feels airtight.
Then it matched a hearing to a completely unrelated matter because the event title had the judge’s name in it.
Think about that for a second. Event titles in a litigation practice are packed with proper names, and almost none of them belong to your client. Judges. Opposing parties. Opposing counsel. Court reporters. Mediators. Venues named after people. Building names. A surname matcher, however carefully you fence it in, is a machine for mixing up the person you represent with everybody else in the room.
So surname matching came out completely. What replaced it is narrow and boring: match on the file number, and only when that number belongs to a matter that actually exists. Firm calendars here already carry the file number in the title, as most well-run practices’ calendars do, and insisting on a real, existing number keeps docket numbers, dates, dollar figures, and times from matching by accident.
So a good share of calendar events show no matter at all. That’s the system refusing to guess, which is exactly what I want it doing with a hearing date.
Why a wrong answer costs more in a law office
Software people have a good feel for precision and recall, and they’re comfortable trading one for the other. What that leaves out is that in a law office, the two kinds of mistake cost wildly different amounts.
A missed attribution costs you a few minutes. Somebody sees an unlabeled entry and labels it. Mildly annoying, completely fixable, and — this is the important part — visible. The blank field is its own alarm.
A wrong attribution is a different animal, and you can’t see it, because it looks exactly like a right one. Here’s what it can do to you:
- A bill to the wrong client. Minn. R. Prof. Conduct 1.5(a) provides that “[a] lawyer shall not make an agreement for, charge, or collect an unreasonable fee or an unreasonable amount for expenses.” A fee for work done on another client’s matter isn’t just unreasonable. It isn’t that client’s fee at all. And look who’s on the hook: the system made the entry, but you reviewed and sent the invoice.
- A deadline docketed to the wrong file. The right file now shows nothing due.
- A privileged document filed in another client’s folder, where the next person who opens that folder will find it.
- A conflicts picture with a quiet hole in it, because the work that would have shown the connection got recorded somewhere else.
Every one of those is an ethics problem before it’s a tech problem. And every one comes from a system doing exactly what it was built to do: always come up with an answer.
Four rules
1. Prefer null.
If the evidence doesn’t clear the bar, write nothing. Make the empty state a normal, expected, good-looking part of the screen, not an error. If a blank looks broken, people will fill it in with a guess, and you’re back to the same failure with an extra step.
2. Rank the evidence, and write the ranking down.
Some signals are worth more than others, and the ranking belongs somewhere the next person can see it:
- Authoritative — the matter folder the work actually happened in. If you were working inside
/Clients/Anderson, Ruth/01234-Anderson/, that’s not a guess. That’s a fact. - Inferential — files written into a matter folder during the session. Good evidence, not proof.
- Rejected — anything merely mentioned, anything matched on a personal name, anything matched on a number nobody has confirmed is a real matter.
3. Show where every guess came from.
Any attribution the system figured out instead of knew should say so on screen: from folder, from files, from event title. That’s one line of display. It turns a bare claim into a claim with a reason, and whoever reviews the invoice can see which entries need a second look.
4. Write down what you threw out, and why.
This is the one people skip, and it’s the one that saves you.
Six months from now somebody, quite possibly you, is going to look at the coverage numbers, see all those calendar events with no matter, and think: we could match a lot of these on the client’s last name. It’ll look like an obvious upgrade. It’ll sail through a quick review. And it’s the exact bug you already fixed twice.
So the code carries a comment right where the surname matcher used to be, saying it was tried, what it broke, and that the second version fell over by matching a judge. Not a note in a wiki. A comment at the scene of the temptation, where the next person reaching for it has to read it first.
Put your failures next to the code that would repeat them. Institutional memory kept anywhere else won’t survive a busy afternoon.
What it looks like day to day
In the systems running here:
- Roughly a third of calendar events show no matter. Nobody minds, because the ones that do show a matter are right.
- Reconstructed time entries show where the attribution came from, and the ones marked as inferred get a harder look before anything’s approved.
- No entry turns into a bill until a person reads it. The system’s job is to make sure nothing gets forgotten. Deciding what’s owed is a different job, and only the first one should be automated.
That last split is really the whole philosophy. Automation is great at noticing that work happened. It’s lousy at deciding whose work it was, and you shouldn’t trust it to, because it can’t tell the folder you were working in from the folder you glanced at unless you make it treat them differently on purpose.
It’s bigger than billing
I’ve come to think this reaches well past attribution, to almost every place we point automation at legal work:
A system that serves a professional obligation should be built so that its failures are visible, and its silences are truthful.
Every automated thing in this office has an obligation behind it. A deadline system serves the duty of competence. A billing system serves Rule 1.5. A conflicts system serves Rules 1.7 through 1.10. Every time, the obligation runs to a person who signs something, and the system’s only honest job is to make that person’s judgment better informed.
A system that guesses doesn’t do that. It manufactures confidence and hands it to you with your signature block already attached.
A blank field isn’t the system failing. It’s the system telling you the truth about what it knows, and that’s the only thing you can safely build a professional judgment on.
Sources
- Minn. R. Prof. Conduct 1.5(a) (“A lawyer shall not make an agreement for, charge, or collect an unreasonable fee or an unreasonable amount for expenses.”), verified against the Minnesota Rules of Professional Conduct as published by the Minnesota Revisor of Statutes.
This article describes general design practice for internal law firm systems. All examples are invented. It contains no client information and is not legal advice. Rule references are general and are not a substitute for reading the rules, which every lawyer should do for themselves.