missed call text back for a law firm: what to send, never promise

within three minutes of a missed call, an automated text should land in the caller's phone. it should acknowledge them, record consent to keep texting, and hand the thread to a human. that's the whole job.

what it must never do is evaluate the claim, name an attorney, or promise representation. that line sounds obvious until you're the one writing the copy under deadline, and the easiest way to get it wrong is to make the text sound helpful. helpful is where the liability lives.

this is a how-to, but the steps are shorter than you'd expect, because the hard part isn't the texting. it's deciding, in advance, what the system is not allowed to say, and building something that can't drift past that line even when nobody's watching it that day.

what a missed call text back is actually allowed to do

state bar rules on attorney advertising and solicitation vary, and nothing here is legal advice about what your bar permits. but the general shape of the risk is consistent across jurisdictions: an automated message that implies legal evaluation, guarantees a case will be taken, or reads like advice creates exposure. unauthorized practice of law doesn't require a human to type the message. a script that tells a caller "you have a strong case" is not a disclaimer away from being a problem.

so the text back has one job: confirm the firm received the call, and ask permission to keep the conversation going by text. it is a receipt, not a reply. the moment it answers a legal question, even a simple one like "do i have a case," it has stopped being intake and started being something else.

that boundary has to be enforced somewhere that isn't a person's judgment on a tuesday afternoon. it has to be in the code.

the prerequisites: consent, dedicated numbers, and deterministic gates

before any outbound text goes out, three things need to exist.

first, a documented basis for texting the caller. TCPA treats automated texts to a phone number differently depending on consent, and the record of that consent, when it was captured and under what language, needs to live somewhere durable, not in a notes field someone might edit later.

second, a dedicated number per practice area or intake line, so the system always knows which script and which disclaimers apply to which inbound call. a firm running both plaintiff and defense work cannot run one blended script across both.

third, and this is the part that actually matters: a deterministic gate between anything a language model touches and anything that gets sent to a caller. the model can read a transcript or a caller's reply and pull out facts. it should never be the thing deciding what the firm's reply says. that decision runs through a fixed script with fixed branches, the kind you can print out and hand to a bar investigator if you ever had to.

step 1: trigger the webhook immediately, not after a delay

the telephony provider fires an event the moment a call goes unanswered or hits voicemail. that event, not a batch job that runs every hour, is what should start the clock. a batch job means some callers wait four minutes and some wait fifty-four, and the one at fifty-four is the one who already called the firm down the street.

log the call event with the number, the time, and the line it came in on, before anything else happens. this is the row everything else attaches to. if this part breaks, nothing downstream should run, because a text that references a call that wasn't logged is a text you can't account for later.

step 2: send the neutral acknowledgment text

the first message should identify the firm, confirm the miss, and ask for consent to continue by text. nothing more.

an example that holds the line: "this is [firm name]. sorry we missed your call. reply YES if it's okay to text you about your situation, and someone from our team will follow up shortly. msg rates may apply, reply STOP to opt out."

notice what isn't in there. no mention of case value, no "we can help," no attorney's name, no promise of a callback time stronger than "shortly." it reads flat on purpose. flat is defensible. warm is where firms start improvising.

step 3: collect the three facts that determine routing

once the caller opts in, the system asks a short set of questions, and this is where a model earns its place: reading the caller's free-text reply and extracting structured facts, not deciding what to do with them.

the three facts that matter for routing are practice area, county or jurisdiction, and urgency, meaning is there a deadline, an upcoming court date, or a statute of limitations concern already mentioned. the model's job stops at pulling those three fields out of whatever the caller typed. a deterministic script takes it from there.

[[FIGURE:1]]

step 4: route to intake or gracefully decline out-of-scope needs

with those three fields in hand, a fixed script checks them against the firm's actual practice: does the firm handle this matter type, does the firm handle this jurisdiction, is there a known conflict flag on the name. none of that check is run by a model, because a model that's occasionally wrong about a conflict check is a model you can't put in front of a caller.

if the match is clean, the thread posts to the intake desk with the extracted facts attached, and a staffer takes it from there. if it isn't a fit, the reply says so plainly, something like "we're not able to assist with this type of matter, but we'd recommend contacting your state bar's lawyer referral service." it declines without guessing at advice, and it does so in a script, not in a model's improvisation.

step 5: fall back to a human queue when anything is ambiguous

this is the part most missed-call-text-back vendors skip, and it's the part that actually earns trust. if the extraction is uncertain, if the caller's reply doesn't parse cleanly into the three fields, or if the model itself is unavailable, the system doesn't guess and it doesn't go silent. it drops the thread into a human queue with a flag explaining why.

a system that fails open to a person is a system that never drops a caller. a system that fails open to a best guess is a liability engine with good branding. the difference between those two is the entire reason this gate exists.

three mistakes that bring regulatory scrutiny to automated texts

the first is implying a relationship exists before a human has engaged. phrases like "we're reviewing your case" or "your consultation is confirmed" suggest representation before an attorney has spoken to anyone. the text can confirm receipt. it cannot confirm engagement.

the second is promising a review timeline the firm can't guarantee, especially after hours. "an attorney will call you within the hour" sent at 11pm on a saturday is a promise the firm has no mechanism to keep, and a broken promise in writing is worse than no promise at all.

the third is letting the system reject a caller without a human ever seeing it. an automated "we can't help you" that was generated by a model reading a transcript, with no staffer reviewing the decline, is the kind of thing that looks fine until one declined caller turns out to have had a real, time-sensitive matter the script misread. every decline should leave a trail a person can check, even if nobody checks most of them.

the fix for all three is the same: the model extracts, the script decides, and every decision is logged somewhere the firm can read line by line, in the firm's own systems, not locked inside a vendor's dashboard.

if you're building this and want a second pair of eyes before any of it goes live against real callers, the Workflow Audit is a two-week review of the telephony and intake automation you already have or are about to turn on, for $2,500, credited toward the build if you move forward. better to find the gap in the script than in a caller's reply.