Where a small practice's hours actually go, and which of them automate

Every article about automating a practice opens with a number of hours saved per week. The number is always round, never sourced to a study you can check, and describes a firm whose client mix, software and staffing you know nothing about. It is a headline, not a finding.

Your own number is knowable and it takes two weeks to establish. Doing that first changes what you build, because most firms discover their largest cost is not the task they were about to automate. This is how to measure it, which tasks pass the test afterwards, and what the arithmetic looks like once you include the cost of building and keeping the thing.

What we'll cover

• Why the published figures are not yours
• Running a time audit that works
• The categories worth separating
• The test a task has to pass
• Building it with CodeWords
• The arithmetic, done honestly
• What the recovered hours become
• Where the savings get eaten
• The ceiling
• Making it survive
• Limits worth knowing about
• What to measure first
• Frequently asked questions

Why the published figures are not yours

Two practices with the same headcount can differ by a factor of three on admin load, and the variables are all local.

Client mix. Forty limited companies on a clean ledger system is a different business from a hundred sole traders sending photographs.

Software. A practice whose ledger, practice management and document store already talk to each other has automated most of the connective work without calling it automation.

Who does what. A firm where a qualified accountant answers the phone loses expensive hours; one with an administrator does not.

The fee model. Fixed-fee practices feel admin as margin. Hourly practices sometimes bill it, which changes the calculation entirely.

So a figure quoted from somebody else's firm tells you a category of problem exists. It does not tell you the size of yours, and building against somebody else's number is how firms end up with an automation that saves forty minutes a month.

Running a time audit that works

Two weeks, everybody, tagged at the point of doing rather than reconstructed on Friday. Reconstruction is where audits go wrong, because people remember the annoying tasks and forget the frequent ones.

Keep it to eight categories. More than that and people stop tagging accurately. Fewer and the result is too coarse to act on.

Record interruptions separately from tasks. A two-minute query costing ten minutes of lost thread should show as ten, and if you only log the two the audit will badly understate the cost of being interrupted.

Pick ordinary weeks. Not January, not the week of a year end, not a holiday week.

Include the partners. Senior time is the most expensive and the least examined, and it is frequently where the surprise is.

Count frequency as well as duration. A task taking four minutes and happening sixty times a week matters more than one taking two hours and happening monthly, and automation is usually easier on the first.

Two weeks of this produces something no article can give you: a ranked list of what your practice actually spends time on, with numbers you trust because you collected them.

The categories worth separating

Most practices find their hours fall into these, and the distinctions matter because they automate very differently.

Chasing clients for things. Requests, reminders, checking what arrived.

Answering the same question. Status, deadlines, what is needed, how to pay.

Moving data between systems. Rekeying, exporting, reformatting, uploading.

Reviewing and correcting. Checking machine output or junior work.

Scheduling and coordination. Arranging calls, confirming meetings, rearranging.

Internal reporting. Building the same view of the same numbers every week.

Genuine client work. The thing you are paid for.

Genuine advisory conversation. The thing you are paid best for.

The first six are candidates. The last two are the point of the business. If the audit shows the last two below half the week, the firm has a structural problem that no automation will fix on its own.

The test a task has to pass

Not everything in the first six categories is worth automating. A task has to clear four bars.

It has a definite trigger. A date, a status change, an arrival. "When it feels like time" is not a trigger, and tasks without one are the commonest cause of half-built automations.

The steps are the same every time. If the process branches on judgement, automation can prepare the work but should not complete it.

The cost of getting it wrong is bounded. Sending a duplicate reminder is recoverable. Filing something incorrectly is not.

It happens often enough to matter. Four minutes times sixty a week is worth building. Two hours once a quarter almost never is, whatever the annual figure looks like.

Tasks that fail the second bar are often still worth half-automating. Preparing a draft, assembling the information and presenting it for a decision removes most of the time while leaving the judgement where it belongs.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the trigger, the steps as they happen today, what reaches a person, and what stops the whole thing.
3. Authorize the connections to your ledger, practice management and document systems, and whatever channel clients use.
4. Describe the exceptions, which is the part that determines whether it survives contact with a real week.
5. Run it in parallel with the manual process for a full cycle and compare, rather than switching and hoping.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The arithmetic, done honestly

Take one task from your audit. Say it takes twelve minutes and happens forty times a week: eight hours.

Automation does not take that to zero. It takes it to whatever review and exception handling costs, which for a well-built process is commonly a quarter to a third of the original. Call the recovered time five hours.

Against that, count the cost properly.

Building it. Days rather than hours for anything that touches more than one system, including the time spent working out what the process actually is.

Keeping it working. Software changes, a supplier changes a format, a rule changes. Budget for this rather than being surprised by it.

The failures. Every automated process fails occasionally, and somebody has to notice and fix it.

The tail. Clients who will not use it, cases the rules do not cover, the exceptions that stay manual forever.

Five recovered hours against a two-day build and an hour a month of upkeep is a straightforward yes. The same five hours against a three-week integration project is not, and that comparison can only be made with your own numbers.

What the recovered hours become

This is where the case is usually overstated. Recovered hours do not turn into billable work by themselves.

They turn into billable work if there is demand waiting, or into capacity for more clients if you are acquiring, or into earlier finishes if that is the actual goal. Several of those are legitimate and only one shows up in revenue. Deciding which you are aiming for before you build changes what you build.

The honest version for many small firms is that the first tranche of recovered time goes into work that was already being done badly because there was no time: the review that was rushed, the planning conversation that never happened, the client who should have been called in November. That is real value and it does not appear as a line in the accounts for a year or two.

Where the savings get eaten

Reviewing the automation more than the task took. If output needs checking line by line, the automation is not finished.

Maintaining something nobody owns. A process with no owner degrades and then gets worked around manually while still appearing to run.

Handling exceptions badly. A rule that covers the common cases while the remainder arrives as unstructured chaos can cost more than the original process.

Building for the client mix you wish you had. Automations designed for the tidy clients still leave the messy ones entirely manual, and the messy ones were the expensive part.

The ceiling

There is an upper bound on all of this and it is worth knowing before you start.

Roughly, the first six categories from the audit are where automation lives. In most small practices they are perhaps a third to a half of the week, and automation removes a large fraction of that rather than all of it. The remaining work is client work and advisory conversation, which is the part you are selling.

A practice that has automated well is not one with no admin. It is one where the admin that remains is the part that genuinely required a person, and where nobody is spending Thursday evening rekeying a spreadsheet.

Making it survive

Re-run the audit annually. The ranked list changes as the client base and the software change.

Give every automation an owner and a date to review it.

Measure the same thing after. If you did not record the before, you have no way to know whether it worked, and everyone will have an opinion.

Keep the manual route documented, because you will need it during an outage and nobody will remember it.

Count the exceptions. A rising exception rate is the first sign a process no longer matches reality.

Limits worth knowing about

Published time-saving figures describe other firms. They are useful for identifying categories and useless as targets.

Automation does not create demand. Recovered capacity only becomes revenue if there is work waiting for it.

Judgement does not automate, though the preparation around it usually does.

A messy client stays messy. Automating your side of a broken process does not tidy theirs.

Some of the worst hours are structural. Wrong software, wrong staffing mix, wrong fee model. Automation will not repair any of those and can disguise them for a while.

What to measure first

Two weeks of tagged time, eight categories, everybody including the partners, interruptions counted at their real cost. Nothing else. Do not build anything during those two weeks.

Two habits make the difference. Rank by frequency rather than by irritation, because the task everyone complains about is rarely the one consuming the hours. And record the before figure for whatever you automate first, since without it you will never be able to tell whether the next one is worth doing.

Frequently asked questions

How much time does automation actually save a small practice?

There is no general answer worth acting on. The variables are client mix, existing software, who does which work and how you charge. Two weeks of measurement gives you your own number, and it is the only one that should drive a build.

How do I run a time audit?

Two ordinary weeks, everybody, tagged at the point of doing rather than reconstructed later, in eight categories, with interruptions logged at their real cost including the lost thread.

Which tasks are worth automating?

Ones with a definite trigger, identical steps each time, a bounded cost of error, and enough frequency to matter. High-frequency short tasks beat rare long ones almost every time.

What if a task needs judgement?

Automate the preparation and stop. Assembling the information and presenting it for a decision removes most of the time while leaving the decision with a person.

What costs should go into the case?

The build, ongoing upkeep, the failures somebody has to fix, and the tail of clients and cases that stay manual. Recovered time measured against build time alone will flatter every project.

Does automation turn into billable hours?

Only if demand is waiting. Otherwise it becomes capacity, or earlier finishes, or work that was previously skipped. All can be worth having; decide which you are aiming for before building.

Why do savings disappear?

Review that costs more than the task, processes with no owner, exceptions arriving unstructured, and automations built for the tidy clients while the messy ones stay manual.

How much of a practice can be automated?

The chasing, repeated answers, data movement, coordination and internal reporting, which is commonly a third to a half of the week, and not all of it. Client work and advisory conversation are the remainder and the point.

How often should this be revisited?

Annually. The ranked list shifts as clients, software and staffing change, and an automation built against a three-year-old picture is often solving a problem you no longer have.

Related reading

• Tax season as a queueing problem
• Closing the loops a practice leaves open
• Receipts, records and what HMRC needs