ai receptionist for law firms: what it should answer, what it hands off

ai receptionist for law firms: what it should answer, what it hands off

a prospective client calls your firm at 8:15 on a tuesday evening, forty minutes after a collision. she is frantic. she wants to know if she has a case. she wants someone to tell her it will be okay. whoever or whatever answers that call is about to make a decision that matters more than most people realize: whether to comfort her with facts, or comfort her with an opinion on liability that no machine and no non-lawyer should be giving.

that is the fault line. not whether an ai should answer the phone after hours. it should. the question is what it is allowed to say once it does.

the three ways law firms handle the front desk after hours

most firms pick one of three setups, and each one fails in a different place.

the first is a traditional answering service. a human reads a script, takes a message, and promises a callback. it is slow and inconsistent, because the person on the line is not a lawyer and cannot triage anything beyond name and number. but it is safe by omission. nobody on that call is capable of answering a legal question, so nobody does.

the second is an unconstrained generative voice bot. this is the pitch you have probably already heard: a conversational ai that sounds like a person, answers anything, and never puts a caller on hold. the problem is that "answers anything" is the feature and the liability. a model trained to be helpful will, if asked, speculate about fault, estimate case value, or imply a deadline is further away than it is. nothing stops it, because nothing in the architecture tells it where the firm's willingness to speak ends.

the third is a dual-engine pipeline: a language model that listens and extracts, paired with a deterministic function that decides what happens next. the model never evaluates the substance of a legal question. it reads the caller, pulls out facts, and hands those facts to code that checks them against fixed rules, before anything is scheduled, logged, or routed. the model does not get a vote on whether this caller has a case. it only gets a vote on what box the caller's words belong in.

that third option is the only one built to survive an audit, and it is worth being specific about why.

the four criteria that matter in legal intake

strip away the vendor language and there are really four things a managing partner should be scoring:

  • auditability. can you produce the exact transcript, the exact extracted fields, and the exact rule that fired, for any call, on request
  • avoidance of unauthorized practice of law. does the system have a hard boundary that prevents it from answering a legal question, or does it just have a soft instruction that a clever caller can talk around
  • speed to triage. how fast does a caller with a real, time-sensitive matter get in front of a human who can actually help
  • conflict-check integrity. does the system check the caller's name and the opposing party's name against existing files before anything is scheduled, or does that check happen later, after a consultation has already been promised

an answering service does fine on the second criterion and poorly on the third and fourth. an unconstrained voice bot does well on speed and badly on the second criterion, which is the one that gets a firm in front of a bar association. a deterministic pipeline is built to hold all four at once, because the constraint is structural, not promised.

what the model is permitted to answer

the model's job is narrow on purpose. it should be extracting, not deciding.

that means it can capture the caller's name, phone number, and the basic shape of why they are calling, in their own words. it can give directions to the office, confirm business hours, and state which practice areas the firm accepts, as a factual list, not an assessment of whether this caller's situation fits one. it can offer available consultation slots and book one. it can confirm that a message has been logged and tell the caller when to expect a callback.

none of that requires legal judgment. it requires listening accurately and writing down what was said. that is the part language models are actually good at, and it is the part that, done well, makes a firm faster without putting a lawyer's license anywhere near the conversation.

[[FIGURE:1]]

what triggers an immediate handoff to a person

the harder and more important design question is where the system is required to stop.

a caller asking "do i have a case" or "who's at fault here" is asking for a legal conclusion. the system should recognize the shape of that question, decline to answer it, and route to a person, every time, without exception carved out for an urgent-sounding caller. a caller asking about a statute of limitations deadline is asking a question where a wrong answer causes irreversible harm. that goes to a person immediately, not into a queue. a caller who is already a client describing something that sounds like an emergency, missed court date, contact from police, a settlement check that hasn't arrived, should never be handled by extraction alone. and a caller whose matter overlaps with an existing file on the opposing side needs a conflict check before anything else happens, including before a consultation slot is offered.

the test is simple: if answering requires legal judgment, the model does not answer. it recognizes the category and moves the call to a person. that boundary has to be enforced by code that the model cannot reason its way around, because a model under pressure to be helpful will try.

how the options score when the bar association audits the file

line the three approaches up against an actual records request and the gaps get obvious.

an answering service produces a message slip. there is no transcript, no timestamp trail beyond a callback log, and no way to prove what was or wasn't said, because nothing was recorded in a structured way.

an unconstrained voice bot produces a transcript, which sounds like an improvement, but the transcript is the problem. if the model answered a liability question or speculated about a deadline, that exchange is now a permanent, timestamped record of the firm having done exactly what it should not have done. more data, in this case, is more exposure, not less.

a deterministic pipeline produces a transcript plus a decision trail: what was extracted, what rule evaluated it, and why it routed where it did. a reviewer can walk the file line by line and see that the system never answered a legal question, because the architecture made that answer structurally unavailable, not just discouraged.

speed follows a similar pattern. the answering service is slow because a human has to manually triage every message the next morning. the voice bot is fast but inconsistent, because its judgment calls vary call to call. the deterministic system is fast and consistent, because the routing logic doesn't have moods.

which setup fits your practice

a high-volume contingency injury practice lives and dies on speed to the first call back, and also carries the most exposure if a caller walks away thinking the firm promised something about their case. that practice needs the deterministic model more than almost anyone, because the volume means no partner is personally reviewing every after-hours call.

a smaller litigation practice with fewer, higher-stakes matters can tolerate a slower front end, but still cannot afford an ai that improvises on conflicts or deadlines. the same boundary applies, just with lower call volume testing it.

what neither practice needs is a system sold on how human it sounds. that is a demo feature. what holds up under a bar inquiry is the separation between what the model heard and what the system decided, and whether that separation can be shown to someone who was not in the room.

if you want to see where your current intake script already crosses that line, before a caller finds it for you, the Workflow Audit maps the phone flow, flags the handoff points, and lays out a deterministic routing design built inside your own accounts. it runs two weeks, costs $2,500, and credits toward a build if you move forward.