Count what actually showed up at your practice yesterday.
A dozen phone calls, and maybe three of them mattered. Four web inquiries: one real potential client, and three vendors, SEO pitches, or somebody in another state. A message in the client portal. Three e-service notices from the court. Some mail. A handful of emails from opposing counsel that really were urgent, buried in a hundred that weren’t.
Now count the information in all of that. It isn’t much. Maybe eight facts you needed to know and four decisions you needed to make.
That gap is the whole problem. The volume of inbound is nothing. The volume of interruptions it throws off is enormous, and you pay for interruptions in the one currency a practice can’t buy more of.
I’ve written elsewhere in this section about the mental load of running several pieces of work at once. Inbound is the same problem coming in from outside. Except you didn’t choose it and you can’t schedule it. That makes it worse, and it makes it the better thing to fix first.
What a phone call really costs you
Get specific about the cost, because “it’s just a quick call” is how the whole day disappears.
A four-minute call doesn’t cost four minutes. It costs four minutes, plus rebuilding whatever you were holding in your head when the phone rang, plus the hangover: that low hum in the back of your mind that keeps chewing on the call for the next twenty minutes whether you want it to or not. If you were deep in a brief, you’re closer to half an hour.
And here’s the part that stings: the cost is the same whether the call mattered or not. A four-minute call from a client with a real emergency and a four-minute call from a guy selling you a search-engine package burn exactly the same attention. The second one just gives you nothing back.
So the most valuable thing an inbound system can do isn’t summarizing, or routing, or drafting replies. It’s making sure that second call never gets to you at all.
Sort it the moment it lands
Sort everything as early as you can, the second it arrives and before a human ever sees it. And sort it by what it means for you, not by how it got there.
Most practices sort by channel without ever deciding to: phone messages here, email there, portal messages somewhere else, court notices in a fourth spot. It feels organized. It’s actually the worst setup you could pick, because it groups things by the accident of how they showed up instead of what they want from you. An urgent client call and a robocall are both “phone.” A dispositive order and a newsletter are both “email.”
Sort by consequence instead, by what you have to do about it. Ours falls into four piles:
Needs a lawyer today. A client in trouble, opposing counsel on a live deadline, a court. This goes somewhere that’s allowed to interrupt you.
Needs a lawyer, not today. Real substance, no fire. This goes somewhere you read when you decide to. You read it; it doesn’t read you.
Needs somebody, not a lawyer. Scheduling, records requests, billing questions, routine intake.
Needs nobody. Solicitations, wrong numbers, hang-ups, spam. Logged, never shown to you.
That fourth pile is where the payoff is, and it’s the one most systems won’t build, because throwing things away feels reckless. It isn’t reckless if it’s logged and searchable. It’s only reckless if it’s gone.
Give every pile its own feed
This one matters more than it sounds: give each pile its own channel, and let the channel tell you how urgent it is.
Ours are separate feeds. One for calls that matter, one for anything from opposing counsel, one for new leads, one for portal notices, one for new court filings. You glance at which one lit up and you know the shape of the thing before you’ve read a word.
That isn’t about being tidy. The notification itself starts telling you something. When everything lands in one inbox, you have to read every alert to know what it is, so every alert is an interruption. When the feeds are split by consequence, you can let most alerts sit without reading them, because where they landed already told you what kind of thing they are. That’s the whole trick. You don’t get fewer messages. You get fewer messages you have to read right now just to find out whether you have to read them right now.
One catch: the urgent channel has to stay rare. The minute it starts carrying ordinary traffic, you stop trusting it. Once you stop trusting it, you’re reading everything again, and you’re right back where you started. Be stingy with it. One or two things a day, or it’s broken.
Filter, but keep the receipts
The obvious question: what if the filter’s wrong and buries something that mattered?
It will be, now and then. The answer isn’t to stop filtering. It’s to make the filtering something you can check, not something that happens in the dark.
Three rules:
Log everything, show selectively. Nothing gets deleted. A filtered call has a record with its transcript or summary, how it was sorted, and why. Searchable forever.
Make “show me what you filtered” a real command. You should be able to ask what got buried today and read the list in ten seconds. You’ll do it weekly at first, then monthly, then almost never, because the answer is boring. Boring is how you learn to trust it. And that trust is what you’re actually building.
When you’re not sure about a category, tag it and let it through. If missing a message would be expensive (an inquiry that might be a real client), flag it and show it to you anyway. Filtering is for the stuff you’re sure about. Spam that looks like a lead gets tagged as suspected spam and surfaced; the tag does the job and you don’t take the risk.
Sometimes knowing it came in is enough
This comes up all the time with practice management software, so it’s worth stepping back on.
Some systems won’t let a program read the message itself. The client portal is a common example: you can find out a message came in, from whom and when, but the API won’t hand you the text. The gut reaction is to call it a dead end and walk away from the integration.
It’s not a dead end. Knowing a message exists gets you most of the way. What you’re really trying to prevent is a client message sitting unread in a portal for four days because nobody logged in. An alert that says “a portal message arrived on this matter” kills that problem outright. Then you open the portal and read it there, which takes fifteen seconds and is what you’d have done anyway.
Same idea anywhere: when a system won’t give you the content, take the signal. A notice that something happened, sent to the right feed, fixes the “nobody noticed” problem, and “nobody noticed” is the one that actually hurts practices. Don’t let the perfect integration you can’t have cost you the useful one you can.
But check the limit before you believe it. We poked at the API before we decided the message text wasn’t available. Building an alert-only integration because you checked and building one because you didn’t bother are two very different things.
Court filings go in the same bucket
People usually think of docket monitoring as its own thing. It shouldn’t be. It’s inbound.
If your courts use electronic service, every filing in every one of your cases already shows up as a notice with the document attached. That’s a complete new-filings feed, delivered to your door, free. And in most practices it’s sitting in an email inbox looking exactly like everything else.
Pull those notices out, match each one to a matter, download the document, and show yourself the day’s filings as one list. That’s a docket alarm, built out of something you’re already getting.
Why put it in the same system instead of buying a separate tool? Because it’s the same problem: a thin stream of high-stakes stuff you can’t miss and can’t let interrupt you. It wants the same treatment. Its own feed, matched to matters, read once a day.
Where to start
If you’re starting from scratch, order matters, because the early wins are what buy you the patience to finish.
1. Filter out the junk. Before any summarizing, sorting, or routing, just kill the noise. Pulling solicitations and hang-ups out of the phone log is the biggest attention win you can get, and it’s close to trivial to build.
2. Split off the urgent channel. One feed that’s allowed to interrupt you, with a deliberately narrow definition. Everything else goes to a default feed you read when you choose.
3. Then sort the rest. Break the default feed up by consequence as patterns show up. Let the real traffic tell you what the piles are instead of designing them up front.
4. Then add the small streams. Court filings, portal notices, web inquiries. They’re easy once the routing exists, and they’re not where it hurts.
Don’t start at step four just because it’s the most fun to build. The payoff is at step one, and you can have it by the end of an afternoon.
Why any of this matters
None of this makes you a better lawyer.
What it does is protect the hours when you can be one. A practice where every inbound message costs half an hour of scattered attention turns out less work, worse work, at a higher cost. And it passes that cost on to clients, or to the people who never become clients because your rate had to cover it.
That’s the thread back to everything else in this section. How many cases a lawyer can carry well is capped by attention, not by hours in the day. Plug the leaks and the cap goes up. Raise the cap far enough and, sooner or later, the price comes down.
General commentary on practice management. Not legal advice. No client, caller, or matter is described in this article; all examples are invented.