Most firms buy phone coverage to solve a simple problem: calls were going to voicemail and prospective clients were calling the next firm on the list. The coverage works, the calls get answered, and then a different problem appears about six months later. The firm is now paying per minute for people who type notes into an email, and someone at the firm still has to read every one of those emails, decide what matters, open the case management system, and type it all again.
That second problem is the one nobody buys for. A firm searching for an answering service with legal intake is usually not looking for a receptionist. It is looking for the thing that happens after the call: the conflict check, the matter record, the follow-up, the calendar entry, the decision about whether this is a case worth taking. The phone part is the easy part. The part that breaks is everything downstream.
What the firm is actually trying to fix
Ask a managing partner what they want and the first answer is usually "we need calls answered after hours". Keep asking and the real list comes out. They want to stop losing personal injury and employment calls to firms that call back in eleven minutes. They want intake notes that are complete enough that an attorney can make a decline decision without a second call. They want the statute of limitations flagged before the file sits for three weeks. They want the data to land in Clio or Filevine or MyCase without a paralegal retyping it.
Those are five different problems and only one of them is answering the phone. A standard answering service with legal intake solves that one well and touches the others lightly. The agent follows a script, collects the fields on the script, and sends a summary. The summary quality depends entirely on how well the script was written and how much legal context the agent has, which is usually not much. That is not a criticism of the service. It is a description of what the product is.
Where the generic script falls apart
The failure mode is predictable. A caller describes a slip and fall at a grocery store, mentions in passing that it happened "a while back, maybe two years ago", and the agent records the incident date as unknown because the script has a date field and the caller did not give a date. The summary arrives at 11pm. Nobody reads it until Tuesday. By then the two year personal injury limitations period under California Code of Civil Procedure section 335.1 may have already run, and the firm has spent attorney time on an intake that was never viable.
A well-designed intake would have caught the phrase "two years ago" and escalated immediately. A script cannot do that because scripts collect, they do not interpret. This is the honest limitation and it is worth stating directly: no intake system, human or automated, should be making a limitations determination. What a good system can do is flag the risk loudly enough that an attorney looks at it within hours rather than days. The judgment stays with the lawyer. The routing and the urgency flag are operational work, and that work is automatable.
The second common failure is conflicts. Most answering services do not run conflict checks, and they should not, because they cannot see your matter database. So the firm ends up with a two-stage intake: the service collects contact details, then someone internally runs the conflict check and either proceeds or kills the file. That gap is where the delay lives. If the conflict check happens three days later, the prospective client has already retained elsewhere, and the firm has also been sitting on information about a potential adverse party for three days, which is an uncomfortable position under the duties in the California Rules of Professional Conduct around confidentiality and conflicts.
What a connected intake workflow actually looks like
Here is a specific version of what the same call looks like when the pieces are wired together. A plaintiff-side employment firm in Sacramento takes calls through a service that handles overflow and after-hours.
A call comes in at 7:40pm. The agent collects name, phone, employer, and a short description. The caller says she was terminated after requesting medical leave and that her last day was in March.
The intake record posts directly into Lawmatics as a new lead rather than arriving as an email. On creation, an automation runs a name search against existing matters and contacts in the firm's system and against a maintained list of adverse parties. The employer name matches a current defendant. The lead is tagged as a potential conflict and routed to the conflicts partner instead of the intake queue, with no outreach sent.
Had there been no match, a different path runs. The lead gets an immediate text confirming the firm received the call and giving a window for callback. A FEHA matter template populates with the fields collected, the termination date is parsed and a provisional deadline reminder is created against the one year window for filing a Civil Rights Department complaint, flagged as provisional and requiring attorney confirmation. A morning digest lands in the intake attorney's inbox ranked by urgency rather than by time received.
Nothing in that workflow involves software exercising legal judgment. The conflict check surfaces a match, a human decides what it means. The deadline reminder is a calendar entry with a label saying "unverified, confirm with attorney", not an answer. The ranking is based on explicit rules the firm wrote. All of it is clerical work that was previously happening by hand, late, or not at all.
Judging the options without the sales pitch
When you evaluate vendors, most of the differentiation claimed in the pitch does not survive contact with your actual workflow. A few things genuinely separate good from mediocre.
- Does it write into your system of record, or does it send an email? Real integration with Clio, Filevine, MyCase, or Lawmatics means a record is created with mapped fields. An email with a transcript is not integration, regardless of what the comparison chart says.
- Who writes the intake logic, and can you change it? If adding a question or changing a routing rule requires a support ticket and a two week turnaround, the system will drift out of date with your practice within a quarter.
- What happens when the caller goes off script? Ask for recordings of calls that did not fit the standard path. That is where you learn whether you are buying intake or buying transcription.
- How is client data handled? If you are collecting personal information from California residents, CCPA obligations attach to your firm, and you need to know where recordings and transcripts are stored, how long they are retained, and whether a subprocessor has access. Get this in the contract, not in an email from a sales rep.
- What is the escalation path at 2am? Not the stated response time. The actual named path for a call that sounds like a custody emergency or an imminent filing deadline.
Be sceptical of anything described as AI intake without a clear statement of what the model does and does not decide. Automated transcription and summarisation are reliable enough for operational use. Automated case evaluation is not, and a firm that relies on it is outsourcing judgment it cannot outsource.
What to do first
Pull the last fifty intake records and measure two things: the gap between first contact and first substantive attorney response, and how many records were incomplete enough to need a second call. Those two numbers tell you whether your problem is phone coverage or workflow, and they will usually point at workflow.
If the gap is the problem, do not start by replacing the answering service. Start by connecting what you already have to your case management system, so intake data lands as a record with a conflict check and a routing rule attached. An answering service with legal intake is a reasonable front door. It is not a substitute for the plumbing behind it, and most firms get more value from building the plumbing than from switching vendors. Alphovia builds that layer for firms that have outgrown the email summary and want intake data moving into their systems without anyone retyping it.