A Clio automation consultant builds automation directly inside Clio, so the repetitive work around your matters gets handled without a person driving each step, and does it without pulling your team off the case management software they already know.
Plenty of automation pitches quietly mean "move everything onto our platform." We don't. We build on top of the Clio you already run.
This is also where we have done the most work. At Brad Thomas Disability we run five separate production integrations against one Clio account, sharing a single connection that refreshes on a schedule so nothing silently drops in the middle of a matter. That firm doubled its revenue in about seven months on the same core team while we took the operations off their plate. Most of what follows is what that build taught us, including the parts that went wrong first.
What is worth automating in Clio
Four things, in the order they usually pay off.
Intake. A new lead becomes a contact and a matter with the right fields filled and the right people assigned, before anyone touches a keyboard. This is the one with revenue attached, because the gap between a lead arriving and someone responding is where signed cases get lost.
Mail and documents. Incoming mail and scanned documents get read, matched to the client they belong to, and filed to the right matter, instead of piling up for someone to sort. In a disability or PI practice this is usually the single biggest pile of manual hours in the building.
Client communication. Clients hear from the firm at each case milestone, automatically, in the firm's own voice. Most "why haven't I heard anything" calls are really about silence, and they cost you twice: once in the client's confidence and once in the time spent answering.
Reporting. The numbers partners actually check, pulled from Clio and delivered on a schedule instead of assembled by hand the night before a partner meeting.
All four run in production today. The two that pay for themselves fastest are intake into Clio matters and mail read and filed to the matter, in that order.
What Clio's API will and will not do
This is the part no one tells you before the project starts, and it is where most Clio automation projects lose their schedule. Clio's API is genuinely good, better than most legal software, and it still has edges that will surprise you.
The task template trap
Clio's interface has a button that applies a task template list to a matter. It is one of the most requested things to automate, because a new matter usually means the same fifteen tasks every time.
There is no endpoint on the task template resource for it, which is where everyone looks first and where we lost time. Applying a list is done from the other side: task_template_list_instances is a nested attribute on the matter, so you assign a list by creating or updating the matter and passing the list id, the assignee and a due date. Nothing on the task template endpoints will do it for you.
That is worth knowing before you scope the work, because the obvious reading of the API is that the feature is missing, and the expensive mistake is concluding you have to build each task by hand with dates you compute yourself. The full version, including what due_at anchors and why the copy endpoint is not what it sounds like, is in how to apply a Clio task template to a matter.
The refresh token chain
This one is worth knowing before it happens to you, because it can take out every automation you have at once.
First thing to establish: Clio runs two separate OAuth systems and they behave differently. The newer Platform API rotates the refresh token on every use, issuing a new one and revoking the old, so you have to store the new token out of every response. The older Manage API documents refresh tokens that do not expire at all. Which one you are on changes how you write the token handling, and plenty of guidance on the internet does not say which it is describing.
Either way, the fragile pattern is the same: several scheduled jobs sharing one stored connection. Two of them come due at the same moment, both read the same token, and both go to exchange it. On a rotating system the second is presenting a token that no longer works. We lost a chain to a token problem before we hardened this, and the tell afterwards was that every integration failed on the same timestamp, which is worth knowing if you are ever debugging it after the fact.
What we run now is one connection refreshed proactively on a schedule so nothing is ever near expiry, plus a guard in every process that re-reads the stored token first and stands down if a sibling has already refreshed. The documented differences between the two systems, the four regions whose tokens do not interoperate, and the revocation asymmetry that explains most dead chains are in why your Clio token stopped working. If you are hiring someone to build against Clio, ask them which OAuth system they are on and how they handle refreshes across multiple jobs. The answer tells you quickly whether they have run anything in production.
Custom fields are firm-specific
Your custom field IDs are yours alone. Anything built against them has to be mapped per firm, which means automation demoed at another firm does not simply drop into yours. It also means a consultant who reorganises your custom fields can break automations built on top of them, so those two jobs need to talk to each other.
Clio's own automations, Zapier, or custom code
Most firms end up with some of all three, and the honest answer is that they solve different problems. Use the cheapest one that actually holds.
| What you need | Clio's built-in workflows | Zapier or Make | Custom code on the API |
|---|---|---|---|
| Task lists and matter stages | Yes, this is what they are for | Overkill | Overkill |
| Document templates | Yes, use Clio Draft | No | No |
| Move data to a tool Clio already integrates with | Sometimes | Yes, this is the sweet spot | Unnecessary |
| Read a scanned letter and file it to the right matter | No | No | Yes |
| Pull from a government portal with no API | No | No | Yes |
| Decide between two similar contacts | No | No | Yes, with a person on the ambiguous ones |
| Apply a task template list automatically | In the UI only | No endpoint to call | Yes, built task by task |
| Survive a failure loudly | Limited | Fails silently | Yes, if built that way |
| Cost shape | Included in your licence | Per task, grows with volume | Project or outcome based |
If Clio can already do it, use Clio. Most firms are paying for workflow features they never turned on, and no consultant should be selling you code to replace a checkbox.
What this costs
The number you came for first. Automation agencies advertise somewhere around $75 to $200 an hour, and $5,000 to $15,000 for a single production workflow. Configuration work (migration, custom fields, permissions, training) is usually billed hourly or as a fixed project inside that same band. Treat all of those as advertised rates rather than facts, because this corner of the market publishes almost nothing and there is no credible survey behind the figures that circulate.
Underneath that sits the licence floor, which is the same whoever you hire. Clio Manage publishes four tiers on annual billing: EasyStart $49, Essentials $89, Advanced $119 and Expand $149 per user per month. Clio Grow, the intake and CRM side, is $59 per user per month on top of Essentials or Advanced, and is included in Expand. Those are the rates on Clio's own pricing page as of July 2026. The top tier is now called Expand, so anything quoting a "Complete" plan is out of date. Advanced plus Grow is $178 per user per month, so the licence line alone moves by about $2,100 a year with every person you hire.
We price against the result instead, and the part worth pinning down is how that is measured, because "priced on the outcome" is easy to say and easy to weasel out of. Three things go into the agreement before anything is built: the number, the baseline it is measured against, and where the measurement comes from. The baseline is pulled from your own data over the weeks before we start rather than from our estimate of it, and the measurement comes out of logs and reports you can open yourself. If the system does not hit the number, there is no bill and you keep what was built.
Apply that test to anyone, us included. A guarantee measured on the vendor's own dashboard, against a baseline the vendor supplied, is not a guarantee. What legal intake automation costs works through that arithmetic with real wage data if you want to run your own number before you talk to anyone.
How the work runs
The audit comes first, and it is free. Half an hour through your actual workflow, where the hours go and what winning them back is worth. You keep the write-up whether we build anything or not.
If it makes sense to build, design lands in about a week and the first system is usually live within a few weeks of starting. Anything that touches a deadline runs in dry-run mode alongside your manual process first, doing the work in the background and logging what it would have done, and only takes over once the logs prove it right. Nothing deadline sensitive gets switched on because it demoed well.
After that it is maintenance, which is the part firms underbuy. Software rots. Clio ships changes, portals move, a form gets a new field. Every automation we run logs each run and alerts loudly on failure, so a break surfaces the same day rather than three weeks later when a client asks why nobody called.
Who gets the alert, and what you are left holding
This is the question worth asking every vendor on this list, including us. The usual answer is "we monitor it," which means you find out when a client does.
The alerts go to you as well as to us, by email and text, to whoever at your firm should know. Not a dashboard somebody has to remember to open. If only the vendor sees the failure, you are trusting the vendor to tell you they failed.
On our side it reaches two people: Drew Patterson, who builds most of it, and Phil Cohen, who spent twenty years engineering at Amazon and CBS. Both of us are on the about page, with faces and histories, which is worth checking on any vendor asking for API access to your case management system. One-person shops are fine right up to the week that person is on a plane.
You hear from one of us the same business day, and sooner than that when the thing that broke touches a deadline.
Everything runs in your accounts, not ours. Your Clio, your hosting, your database, your Google or Microsoft tenancy, billed to you. Ask to see the billing before you sign, because that is checkable and a promise is not.
Worth asking every vendor the follow-up too, since this is where the answer usually frays: is there any account of yours anywhere in the chain? Monitoring, error tracking, whichever AI model reads the scanned mail. If one key in the middle belongs to the vendor, "nothing switches off" is true right until their card expires. Ours sit in your accounts for that reason, and where a service cannot be put in your name we say so up front rather than at the handover.
And it is written down. Every system has a runbook covering what it does, what it touches, how it fails and how to restart it, kept with the code, so a competent developer who has never met us can pick it up. Get that handover written into the agreement with whoever you hire, ours included, because a bad breakup is exactly when goodwill runs out and a good intention is worth nothing at that point. Ask any vendor for a sample runbook before you sign. The ones who have never written one will tell you the code is self-documenting.
When you do not need any of this
Worth saying plainly, because it disqualifies a fair number of firms.
If your intake volume is low enough that one person handles it comfortably alongside other work, automation will not pay for itself and you should spend the money on marketing instead. If your process changes every month because you are still working out how you want to run, automate later, once it has settled: encoding a process you are about to change is how firms end up with automation nobody trusts. And if what you actually need is Clio set up properly, custom fields, permissions, templates, migration, then you want a Clio certified consultant for implementation work.
The rough line, in our experience, is whether the same task happens enough times a week that a person could describe it as "the thing I do all morning." Below that, the maths rarely works.
We build in Clio, we do not replace it
Your case management system is where your team lives. Ripping it out to install ours would cost you weeks of retraining to solve a problem that does not need it. We work through Clio's API, your Clio stays exactly as it is, and if we ever parted ways you would keep your data and the custom work. If you already know you want this built, hiring a Clio automation consultant is the page that lays out exactly what we run inside Clio, what it costs and how the engagement works.
Want a straight read on which parts of your firm are worth building? Book a free operations audit. Thirty minutes through your workflow, and you leave with the write-up even if we never work together.
Common questions
What does a Clio automation consultant do?
They build automation directly inside Clio so the repetitive work around your matters gets handled without a person driving each step: intake, filing incoming mail and documents to the right matter, client updates at case milestones, and the reports partners actually check. The point is to make Clio carry more of the work your team does by hand.
What can you automate in Clio?
The parts that eat your team's day. New leads becoming contacts and matters with the right fields and people assigned, incoming mail and documents read and filed to the correct matter, texts and emails to clients at each milestone, and reporting pulled and delivered on a schedule. If it happens the same way every time in Clio, it can usually be automated.
Can Clio's built-in automations do this already?
For some of it, yes, and you should use them where they fit. Clio's native workflows handle task lists, document templates and matter stages well. They run inside Clio only, so the moment a job involves reading scanned mail, pulling from a government portal, or deciding which of two similar contacts a document belongs to, you are past what the built-in tools reach.
Is a Clio certified consultant the same thing?
Not quite. Clio's certified consultant program is largely about configuring and implementing Clio itself: setup, migration, custom fields, training, workflows. Automation consulting overlaps but goes further, into code that runs against the API on a schedule and handles work Clio has no screen for. A firm often wants both, and sometimes from different people.
What does Clio automation cost?
The Clio licences themselves are published per user per month, from $49 for EasyStart to $149 for Expand, with Clio Grow at $59 on top of the middle tiers. A consultant sits above that. Configuration work is usually billed hourly or as a fixed project. Custom automation built against the API is priced either as a project or, the way we do it, against a measurable result written into the agreement, so if the system misses the number there is no bill.
Do I have to switch off Clio to automate it?
No. We build on top of the Clio you already run, through its API, and your Clio stays exactly as it is. Your team keeps working the way they know, and nothing moves to a system they would have to relearn.
How long does it take?
Our first system is usually live within a few weeks: roughly a week to audit and map the work, a week to design it, then build and deploy. Anything touching a deadline runs in dry-run mode next to your manual process first and only takes over once the logs prove it right.
What if the automation misses something?
We agree the result up front and write it into the agreement, so if the system misses it, you don't pay for it. Everything runs in your own Clio and accounts either way, and every automation logs its runs and alerts both of us when something fails.