Every intake call ends the same way. A lawyer hangs up the Zoom, opens Clio, types in a new matter, fills the client name, copies a few details from the notes, and sets a couple of reminders. It takes ten minutes and it happens on every single new client. The information already exists. It is sitting in the transcript and in the lawyer's head. The work is pure transcription from one place to another.
That is exactly the shape of work an AI agent should do. Not the legal judgment, not deciding what is relevant to the case. The mechanical part: read the consult, pull out who the parties are and what dates matter, and stage a matter shell with tasks so the lawyer reviews and approves instead of typing from scratch.
We learned the details the hard way, by building the open-source Clio MCP connector and a MyCase one, and hitting every API gotcha along the way. This recipe is what survived contact with the real APIs. It works for Clio; the same pattern adapts to MyCase or PracticePanther, which expose similar matter and contact endpoints.
The recipe at a glance
Five steps. Three of them are net-new automation, two of them are guardrails. Skip either guardrail and you have built something that quietly creates wrong matters or leaks privileged data.
2. Extract parties + deadlines with Claude (plain Messages API, ZDR)
3. Draft a matter shell + opening tasks (do not write yet)
4. Human confirms or edits the draft ← the gate
5. Write the matter, tasks, and a note back into Clio
The reason it stops at step 4 instead of writing straight through is not caution for its own sake. It is a duty. We will come back to that.
Step 1: Get the transcript out of Zoom
You need text before you can extract anything. The dependable source is the Zoom cloud-recording transcript, the VTT file, which requires cloud recording switched on (a paid tier) and transcription enabled. Confirm both before you build anything, because nothing downstream works without them.
The unlock most people miss: you do not need a public server or a webhook listener to get the recording. Polling GET /users/me/recordings works fully from a local machine. A small local agent checks every ten to fifteen minutes, finds the new recording, and pulls the VTT. That means the whole intake pipeline can run locally on a lawyer's machine with nothing exposed to the internet, which matters a lot when the data is privileged.
Two real constraints to design around:
- Latency. The VTT transcript is ready roughly two times the meeting length. A 30-minute consult means about an hour before the transcript exists. This is not a real-time workflow, and that is fine, because nobody is creating the matter mid-call anyway. Build the poller to expect the delay rather than firing the instant the meeting ends.
- The AI summary is fragile, the transcript is not. Zoom's AI Companion summary is tempting, but reading it by API is blocked in basic Server-to-Server OAuth (you need a General or Account-Managed app), and those summaries auto-delete at 30 days. Treat the AI summary as a bonus if it happens to be there. Make the VTT transcript the backbone and have Claude summarize it yourself. That way your pipeline does not break the day a Zoom app config changes.
One more residency note for Canadian firms. Zoom has a Canadian data center, but AI-content residency is not guaranteed Canada-only. The mitigation is to pull and store fast: get the transcript out of Zoom and into your own Canadian-resident systems quickly rather than leaving AI artifacts sitting on Zoom infrastructure.
Step 2: Extract parties and deadlines, on a surface you can defend
This is the step where you hand text to a language model and get back structure. Send Claude the transcript with a tight prompt that asks for a fixed schema: client name and contact details, opposing parties, the matter type, any dates mentioned, and any deadlines that follow from them. Ask for JSON so the next step is mechanical, not a second round of parsing prose.
The architecture decision that actually matters here is which Claude surface you use, because this is privileged client data. Three things are true and worth stating plainly:
- Zero data retention is not available on Claude Team chat. If a lawyer is pasting transcripts into the Team web app expecting ZDR, they are using the wrong product. That is a product limitation, not a small-firm rejection, and waiting for it to appear there is waiting forever.
- ZDR is available on the Anthropic API, granted at the organization level, and a small firm can obtain it. Route the extraction through the plain Messages API under a ZDR arrangement with
inference_geopinned to US. The API does not train on your data by default, and under ZDR nothing persists at rest after the response. - Anthropic has no Canadian region. Inference happens in the US. For a Canadian firm you do not pretend otherwise; you document the cross-border step for your confidentiality obligations and pin inference to the US so at least the location is known and fixed.
Keep the pipeline on ZDR-eligible surfaces only. That means the plain Messages API. It does not mean the Files API, Batch, code execution, or the hosted MCP-connector product, none of which carry the same ZDR guarantee. If you want the compliance posture, you keep the workflow narrow.
And do not buy Enterprise to get there. Enterprise has a roughly 20-seat self-serve minimum (50 sales-assisted) and a six-figure commitment. A four-person firm chasing ZDR through Enterprise is over-buying by an order of magnitude. The API org-level ZDR is the right-sized answer.
Step 3: Draft the matter shell and tasks (in memory, not in Clio)
Now you have structured data. Turn it into a proposed matter: a matter name, the client contact, the matter type, and a short set of opening tasks and calendar entries derived from the deadlines. Critically, hold all of this in memory. Do not write to Clio yet. The draft is a proposal for a human, not a command to the API.
What the Clio Manage API actually supports here is generous. Creating matters, creating and reading contacts, creating tasks with full CRUD, creating notes, and creating calendar entries are all real operations. Our connector exposes these today, so the write side of this recipe is not the hard part.
The hard part is custom fields, and it is worth a warning because it is the single most common way these integrations break.
The value-id trap. To write a custom field you PATCH the matter with a nested custom_field_values array. The id inside that array is the value-instance id, not the field-definition id you see elsewhere as custom_field:{id}. Pass the definition id and your write silently goes wrong. This is the number-one trap in Clio custom-field integrations, and it is invisible until you read the response carefully.
Field types add a second layer of rules. Free-text fields take normalized strings cleanly. Picklist fields only accept predefined options, capped at 55 characters. Currency fields reject decimals. Date fields need valid dates. So if your extraction step pulled "approximately mid-March" out of a transcript, you cannot shove that into a date field. Inventory your fields by type first, and only auto-populate the ones whose type tolerates what the model produces. For a clean intake recipe, we recommend leaving custom fields to the human-confirm step and auto-filling only the obvious ones (client name, address) where the data is unambiguous.
Step 4: The human-confirm gate (this is the whole point)
Here is where the recipe earns its keep, and where most "AI automates intake" demos quietly cheat by skipping it.
You do not let the agent create the matter unattended. The lawyer sees the proposed matter, the extracted parties, the deadlines, and the draft tasks, and either approves it as-is or edits it first. Only then does step 5 write anything to Clio.
This is not optional polish. The Law Society of Ontario's April 2024 guidance and ABA Formal Opinion 512 both land in the same place: a lawyer must verify AI outputs, maintain competence and supervision over the tool, and protect confidentiality. You also cannot bill AI processing time as lawyer hours. A workflow that writes a matter and sets deadlines with no lawyer in the loop is not just risky engineering, it is misaligned with the duty the lawyer owes. The confirm gate is how you keep automation on the right side of that line.
There is a practical payoff too. The model will sometimes get the matter type wrong, or read a date as a deadline that was just a passing reference. The confirm step catches that with a glance, which is far cheaper than discovering a wrong limitation date three weeks later. The lawyer reviews a filled-in draft in seconds instead of typing a blank form in minutes. That is the actual time saved, and it is real.
Step 5: Write it back, and close the loop
Once the lawyer approves, the agent writes the matter, creates the tasks and calendar entries, and adds a note that captures the consult summary. If you generated a consult memo document, you can upload it straight into the matter so the lawyer never has to drag a file across apps.
Two things to get right on the write side:
- Document upload is a two-step presigned-S3 flow. You do not POST the bytes directly. You POST to
/documentsto create the record, PUT the file bytes to the returnedput_url, then PATCHfully_uploadedto finalize. Miss the final PATCH and Clio treats the document as incomplete. Our connector'supload_documenttool handles this multipart dance, so the loop closes: transcript in, finished document in the matter out. - Respect the rate limit. Throttle to about 3 requests per second per app (Clio also cites a 50-per-minute legacy figure), honor the
X-RateLimit-*headers, back off on 429, and paginate at 200 per page. A single intake is light traffic, but if you ever batch-create matters or backfill, build a resumable, rate-limit-aware runner or it will stall partway through.
One thing the Clio API will not do for you: there is no document webhook, so you cannot get notified the instant a document is generated. Detect new documents by polling or by watching the matter updated webhook (a stage change is usually the cause of generation, so trigger on that). Clio's webhooks also auto-expire (3 days default, 31 max), so whatever you build has to renew them on a schedule or it goes silent without warning.
Build it yourself or buy the pattern
None of these steps are exotic. A capable engineer who reads the Clio and Zoom docs can build this. The reason people still come to us is not the capability, it is the gotchas, the reliability, and the replication.
The gotchas are the value-id trap, the missing document webhook, the expiring webhooks, the ZDR-only-on-API rule, the Zoom summary that works in a demo and fails in production, and the transcript latency. Each one costs a day or two to discover the first time. We discovered them building the connectors, which is why a recipe like this reads cleanly instead of as a list of dead ends.
The reliability is the difference between a script that worked once on your machine and something a lawyer trusts on every new client. The replication is getting the identical workflow onto every lawyer's setup without each of them doing technical configuration, because lawyers do not do technical configuration.
If you want to build it yourself, the open-source Clio MCP connector is on npm as @oktopeak/clio-mcp, with the MyCase one alongside it, and the connector comparison covers what each open-source option (LegalContext, lawquarter, LegalMCP, ours) actually exposes. Tools like n8n can orchestrate the polling and the steps between Zoom, Claude, and Clio if you prefer a low-code wiring layer. Agencies that build legal software, ourselves and others like Arkenea or Topflight, can do the custom version. The recipe above is vendor-neutral on purpose: the steps hold whether you wire them with n8n, a Python script, or a packaged connector.
Frequently asked questions
Can AI automatically create a matter in Clio from a consult call?
Partly. The Clio Manage API supports creating matters, contacts, tasks, notes, and calendar entries programmatically, so an AI agent can draft a matter shell from a consult transcript. But you should never let it create the matter unattended. ABA Opinion 512 and LSO guidance both require a lawyer to verify AI outputs before they take effect. The correct pattern is draft-then-confirm: the agent extracts parties and deadlines, proposes a matter plus tasks, and a human approves before anything is written to Clio.
How do you get a transcript from a Zoom consult into an AI workflow?
Turn on cloud recording with transcription (a paid Zoom feature) and poll GET /users/me/recordings, which works fully from a local machine with no public endpoint. The reliable backbone is the cloud-recording VTT transcript, available roughly two times the meeting length, so about an hour after a 30-minute consult. The Zoom AI Companion summary is available by API only on a General or Account-Managed app, not in basic Server-to-Server OAuth, and those summaries auto-delete at 30 days. Treat the AI summary as best-effort and the VTT transcript as the source you can depend on.
Is it safe to send privileged client data to Claude for intake automation?
It can be, with the right surface. Zero data retention is not available on Claude Team chat, but it is available on the Anthropic API at the organization level, which even a small firm can obtain. Run the workflow through the plain Messages API under a ZDR arrangement with US-pinned inference, and the API does not train on your data by default. Anthropic has no Canadian data region, so for Canadian firms you document the cross-border step for your confidentiality obligations. Keep the pipeline off non-ZDR surfaces such as the Files API, Batch, code execution, and the MCP-connector product.
What is the rate limit on the Clio API for a batch intake workflow?
Throttle conservatively to about 3 requests per second per app (Clio's documentation also cites a 50-per-minute legacy figure). Honor the X-RateLimit-* headers, back off on 429 responses, and paginate at 200 records per page. Intake of a single matter is light, but a backfill across many matters needs a resumable, rate-limit-aware batch runner or it will stall.
Why does writing a custom field in Clio fail with the wrong ID?
The most common Clio integration bug: when you PATCH a matter with a nested custom_field_values array, the id you pass must be the value-instance id, not the field-definition id you see as custom_field:{id}. Mixing them up is the number-one trap. Also remember field-type rules: picklist values must match predefined options under 55 characters, currency rejects decimals, and date fields need valid dates. Inventory your fields by type before promising blanket population.
Next step
If you run a Clio-based practice and you are doing the type-it-in-from-the-consult dance on every new client, this recipe is the thing worth automating first. It is mechanical, it repeats, and the human-confirm gate keeps it compliant. The hard parts are the API gotchas and the privacy surface, not the idea.
We build this workflow for legal practices, local-first when the data is privileged, and we keep the open-source connectors that power it public so you can inspect exactly what touches your data. If you want a second set of eyes on your intake automation, or you want it built and deployed across your team, book a free 30-minute architecture review. No pitch deck, just an honest technical conversation about what is feasible on your stack.
Book a free architecture review →
Or read more from our legal AI practice:
