Most firms that build automation build it around the intake process they have today. Then a new referral source appears, a practice area expands, or a partner decides the consultation should happen before the conflicts check rather than after, and half the automation stops firing or fires at the wrong time. The build was fine. The assumption that intake is stable was not.
This is the quiet failure mode of legal workflow automation, and it explains why a lot of firms are on their second or third attempt. The problem is rarely the tooling. It is that the workflow was encoded as a fixed sequence of steps when what the firm actually needed was a set of rules that survive the sequence changing.
What you are actually trying to solve
When a managing partner searches for legal workflow automation, the underlying complaint is usually one of a small number of things. Leads sit for two days before anyone calls them. The same client information gets typed four times, into the intake form, the matter record, the engagement letter, and the calendar. Nobody can tell you how many consultations converted last month without someone building a spreadsheet by hand. Deadlines get calendared from a paralegal's memory of what a similar matter needed.
Those are operational problems, not legal ones. That distinction matters more than it sounds. The work that can be automated safely is the movement, copying, routing, and reminding. The work that cannot is the judgement about whether to take the matter, what the deadline actually is under the applicable rule, and what to advise. Any vendor blurring that line should be treated with suspicion, and under the California Rules of Professional Conduct the supervisory obligation sits with the attorney regardless of what the software did.
So the honest framing is this. You are trying to remove the clerical layer around intake and matter opening so that attorney and paralegal attention goes to the parts that require a licensed human. That is a narrower goal than most marketing suggests, and it is achievable.
Why intake changes break automation
Intake is the least stable process in a law firm. It is the point where the outside world touches the firm, and the outside world keeps changing. A personal injury firm adds a Spanish-language intake line. An employment firm starts taking a volume of cases from one referral partner who sends structured data instead of phone calls. A family law practice decides that a paid consultation now precedes the conflicts check because too many free consultations were going nowhere.
Each of those is a reasonable business decision. Each of them breaks automation that was built as a chain: form submitted, then task assigned, then email sent, then matter created, then calendar populated. Chains break at the first link that moves.
The alternative is to build around states and conditions rather than sequence. Instead of "when the web form is submitted, send the intake packet," you build "when a lead reaches the stage where conflicts has cleared and the matter type is known, send the packet appropriate to that matter type, regardless of how it got there." The first rule assumes one entry point. The second tolerates five. It is more work to design and it is the difference between automation that lasts two years and automation that lasts four months.
What works, in practice
The things that hold up well across intake changes tend to share a characteristic: they are triggered by data conditions rather than by a specific human action in a specific order.
- Deduplication and conflicts prompting. Matching an incoming name against existing clients and adverse parties and flagging matches for a human to review. The software should surface possible conflicts. The attorney clears them.
- Document assembly from structured fields. Engagement letters, fee agreements, and standard correspondence generated from data already captured, so the client's name is typed once. Practice management platforms such as Clio, MyCase, and Filevine handle this natively to varying degrees, and Lawmatics is built specifically around the intake and marketing end of it.
- Routing and escalation by rule. If a lead in a given practice area has had no contact within a defined window, it escalates. This survives intake changes because it depends on elapsed time and contact status, not on how the lead arrived.
- Data sync between systems. Pushing a converted lead into the practice management system, the accounting system, and the document management system without rekeying. This is unglamorous and it is where most of the recovered hours actually come from.
- Structured capture at the point of first contact, including when that contact is a phone call, so the information exists in fields rather than in a note.
A worked example
Take a mid-size employment firm handling wage and hour matters. Intake previously came almost entirely through the website form. Then the firm signed a referral arrangement with a workers' compensation practice that sends roughly a dozen matters a month by email, and separately started running a phone line that produces calls at all hours.
The original automation was a chain tied to the web form. It broke immediately for the other two channels.
The rebuilt version works like this. Every inbound contact, whatever the channel, lands in a single lead record with a required set of fields: name, contact details, employer, rough date range of employment, and the nature of the complaint. Phone calls get transcribed and the fields populated from the transcript, with a paralegal reviewing before the record moves forward. The record then sits at a conflicts stage until someone clears it, and that clearance is a human action that the system records but does not perform.
Once cleared, and only once cleared, the system does four things: creates the matter in the practice management system, generates the engagement letter with the client and employer names already populated, assigns a follow-up task to the responsible attorney, and calendars a review date. The date on that review is a prompt to think about the statute of limitations, not a computed deadline. The system does not calculate limitations periods and is not asked to.
When the firm later adds a fourth intake channel, nothing about that downstream flow needs rebuilding. The new channel just has to produce the same set of fields.
Where it does not work, plainly
Automated deadline calculation is the clearest one. California court deadlines involve service method, court holidays, local rules, and provisions that do not reduce cleanly to arithmetic. Rules-based calendaring software exists and is useful as a check, but the calculation is an attorney's responsibility and treating the output as authoritative is an unacceptable risk.
Automated intake screening that decides whether to take a matter is a second one. A system can score and sort leads by criteria you define. It cannot evaluate a claim, and presenting it as though it does creates both a competence problem and a supervision problem.
Anything touching confidential client information needs to be assessed properly rather than assumed. Where a vendor processes client personal information you are looking at CCPA obligations alongside your professional duty of confidentiality, and the relevant questions are where data is stored, who at the vendor can see it, what happens on termination, and whether subprocessors are disclosed. Firms routinely sign these agreements without reading them.
And generative AI drafting deserves scepticism in client-facing output. It is adequate for internal summaries and first drafts of routine correspondence that a human will rewrite. It is not adequate for anything sent out without review, and the review has to be real.
How to judge the options honestly
Ask three questions of any proposal. First, what happens when intake changes, and can you see the answer rather than be told it? Ask the vendor or the builder to walk through adding a new referral channel. If the answer involves rebuilding existing flows, that is a design problem. Second, who owns the logic? If the automation lives in a configuration only the vendor can edit, your firm has a dependency, not an asset. Third, what does it do when data is missing or ambiguous? Good systems stop and ask. Weak ones guess.
Be wary of demos built on clean data. Your data is not clean. The useful test is whether the system handles a lead with a misspelled name, no email address, and a matter type nobody selected.
What to do first
Before evaluating any platform, spend an hour documenting the last twenty matters your firm opened and how each one arrived. Not how intake is supposed to work, how it actually worked. Most firms find three or four distinct paths where they assumed one. That document is the specification. Build to it, and build so that a fifth path can be added without touching the first four.
If the internal capacity to do that design work is not there, it is the kind of thing Alphovia builds. Either way, the sequence is the same: map the real intake paths first, then decide what to automate.