AI to classify emails: how we organized a law firm's inbox

The AI doesn't reply to the emails: it classifies them, summarizes them and sorts them so a person can decide. And the first step isn't the AI — it's defining what matters in that business and who the sender is, because the sender carries more weight than the content when it comes to knowing what's urgent.

A few months ago we sat down with a law firm that had a problem anyone would recognize: the inbox had stopped being a tool and had turned into a source of anxiety. Unread emails piling up, important messages buried among automated notifications, and the constant feeling that something was slipping through the cracks.

The first reaction, almost always, is to ask for "the AI to answer the emails". It's the wrong reaction, and in this article we want to explain why, and what we did instead.

The problem wasn't the volume

When we sat down to look at the actual inbox, something came up that changed the whole approach: the problem wasn't that a lot of emails were coming in. It was that nobody knew what was in there without opening them one by one.

Those are two different problems, and they're solved differently. If the problem is volume, the solution is to reply faster. If the problem is visibility, replying faster doesn't help at all: you still don't know what to reply to first.

That distinction shapes everything that follows. We didn't build a system that answers emails. We built one that tells you what's in the inbox without you having to read it.

The first step wasn't the AI: it was deciding what matters

The step that took the longest had nothing technical about it. It was sitting down to define the categories: what types of email this firm receives and what needs to be done with each one.

Existing client. New inquiry. Opposing party. Court. Vendor. Automated notification. Internal.

It looks obvious written like that. It isn't when you have to decide it on real emails and you find that half the cases don't fit cleanly into any box. That conversation is about the business, not about software, and it can't be skipped: a classifier without a clear definition of the categories produces a new mess, harder to audit than the old one.

If you're thinking about automating your inbox, this is the work you'll have to do yourself. Nobody can do it for your business.

Who it's from matters more than what it says

Here's the most useful lesson of the whole project, and the most counterintuitive one.

A language model classifies by reading the text. It works surprisingly well… for email that doesn't have an obvious rule. But a large share of any company's correspondence classifies itself with a much cheaper and much more reliable piece of data: where it comes from.

If it comes from your own domain, it's internal. No text should be able to change that. If it comes from a known vendor's billing address, it's from that vendor. If it comes from an email address that's already in your client database, it's an existing client.

So the system doesn't ask the model first. First it looks at the sender. Rules by address and by domain win over text-based classification when the operator sets it up that way. The model comes in where it really adds value: on genuinely ambiguous email.

This has an additional, underrated benefit: sender rules are explainable. When someone asks "why did this email end up here?", the answer is a rule you can read, not a statistical decision.

The summary only helps if it gets there before you do

The second piece was an automatic summary of every incoming email: two or three lines that tell you what it's about.

The implementation detail that decides whether this is useful or just decorative: the summary is generated the moment the email comes in, not in an overnight process. If you open the inbox at nine in the morning and the summary of the email that arrived at eight thirty isn't there yet, the summary doesn't exist. You're back to opening the email to find out what it said, which was exactly the original problem.

It sounds like a minor detail. It's the difference between a feature that gets used and one that gets ignored within a week.

The AI writes the draft. The person signs it.

When we got to the replying part, we made a deliberate decision that's worth explaining, because it goes against what usually gets sold: the system doesn't send emails on its own.

The AI puts together a draft —with the intent and tone you tell it— and leaves it ready. A person reads it, adjusts it if needed, and sends it.

In legal correspondence this isn't a limitation we couldn't overcome: it's the right design. A wrong draft that someone fixes before sending costs thirty seconds. A wrong email that went out on its own can cost a client, or quite a bit more than that.

The general rule we took away: automate the preparation, not the decision. Almost all the time you save is in the preparation anyway.

Automatic replies need a brake

For some categories an automatic acknowledgment does make sense. "We received your inquiry, we'll get back to you in X." There, it is worth having it go out on its own.

But an automatic reply with no limits is a well-known way to hurt yourself:

• If two automated systems reply to each other, you get a loop that fills two inboxes in minutes.
• If the same sender writes five times in one day, they get five identical acknowledgments, and the effect is worse than not having replied at all.

That's why the automatic acknowledgment has a per-sender limit within a time window, and it deliberately ignores emails flagged as machine-generated. Those are two small defenses nobody asks for in the kickoff meeting, and they prevent an expensive problem.

What doesn't get answered is information too

The last piece was alerts. An email that went unanswered, a deadline that's coming up, a pending item tied to a client or a case file.

This is what turns the inbox into something you can query. The question "what do I have pending?" stops requiring someone to go through the inbox from memory and gets an answer on screen.

It's also the part that has the least to do with artificial intelligence and the one that changes day-to-day work the most. It's worth saying clearly: in most of the projects we do, AI is one piece, not the project.

Where the AI lives when the content is confidential

For a law firm this question isn't an architecture detail, it's an entry requirement, and we want to be explicit because almost nobody spells it out.

The processing runs on the client's own account, with their credentials and their billing. The correspondence doesn't go through a shared account of ours or anyone else's. The credential can be revoked from the dashboard, and every use is logged.

If you're evaluating putting AI on top of your company's sensitive information, these are the three questions worth asking, in this order: What account does it run on? Can it be revoked? Is every use logged? If any answer is unclear, you're not ready to connect anything yet.

What a business that isn't a law firm can take from this

Almost everything, really. The industry changes the categories; it doesn't change the method:

• The problem is rarely the volume. It's usually that you don't know what's in there without looking at all of it.
• Defining the categories is your job, and it's the part that determines whether the rest works.
• Simple rules beat the model where they exist. Use AI for what's ambiguous, not for what's obvious.
• Automate the preparation, not the decision.
• Everything automatic needs a brake planned ahead of time.

Does your inbox look like this?

If you're reading this with the feeling that we just described your inbox, we can look at it together. The diagnosis is free and comes out of a short conversation: what comes in, what slips past you and what can be organized first.

We'll be in touch soon.