What AI automation actually costs a small firm

2026-07-26 · 7 MIN READ · BOTTLENECKS

What AI automation actually costs a small firm

How much does AI automation cost for a small business?

There are five costs, not one: the one-off build, the automation platform subscription, metered model usage, ongoing maintenance, and your own team's time during and after the build. The build is usually the largest single number but the smallest long-run one. Work out what the process costs you today in hours, price all five layers against that, and only proceed if the payback lands inside about twelve months.

What are you actually paying for?

Five layers, each with a different shape. Price them separately, because they behave differently over three years.

LayerWhen you payShapeHow to estimate it
BuildOnce, up frontFixed if scoped properlyGet a fixed written quote before work starts
Automation platformMonthlyScales with runs and stepsCount monthly runs, check current pricing tiers
Model usageMonthly, meteredScales with volume and document lengthRuns per month multiplied by rough size per run
MaintenanceIrregular, ongoingSmall most months, occasionally notAssume a few hours a year per workflow, more in year one
Internal timeDuring build, then ongoingConcentrated up frontHours for interviews, testing, training, exceptions

There is a sixth line that catches people out: tool upgrades. Plenty of SaaS products gate API access behind a higher plan tier, so connecting the CRM you already pay for can mean moving up a plan for every seat. Check that before you scope, not after.

How do you work out what the process costs you today?

Multiply frequency by duration by a loaded hourly cost. That single number is the one the whole decision hangs on, and most firms have never calculated it.

  1. Count how often the process runs in a month. Not how often it feels like it runs. Count last month.
  2. Time it honestly, including the interruption cost of switching to it. If an enquiry takes four minutes to file and reply to, but breaks concentration for ten, use something closer to ten.
  3. Work out the loaded hourly cost of the person doing it. Salary plus superannuation, leave, payroll tax and tools, divided by the hours they actually work in a year. That figure is meaningfully higher than their hourly wage.
  4. If the person doing it could otherwise be billing, use their charge-out rate instead. That is the real loss.
  5. Multiply the three. Then multiply by twelve for the annual figure, which is the number that makes the decision obvious in either direction.

Do this before you talk to anyone about building anything. A firm that knows a process costs it a certain amount a year can evaluate a quote in about a minute. A firm that does not is guessing, and will either overpay for something trivial or refuse something that would have paid for itself in a quarter.

How do you estimate the model usage cost?

Estimate volume first, then look up the current rate, in that order. Model pricing is published per million tokens, and a token is roughly three-quarters of a word for English text.

The calculation:

  1. Estimate the runs per month.
  2. Estimate the words going in and coming out per run. An enquiry email plus a drafted reply might be a few hundred words each way. A twenty-page contract is a different scale entirely.
  3. Convert words to tokens by dividing by about 0.75, then multiply by the runs.
  4. Divide by one million and multiply by the provider's current published rate. Input and output are usually priced differently, so do the two halves separately.
  5. Double the answer for safety. Retries, testing and the runs you forgot about are real.

For most small-firm workflows this lands as one of the smaller monthly lines, because the volume simply is not high. The exception is anything that reads long documents at scale, where the cost is driven by document length rather than by the number of runs. If your workflow is in that category, do the estimate carefully before you commit, and check whether a smaller, cheaper model handles the task well enough.

What does the build itself cost?

More than the tool suggests and less than the problem costs, if it was scoped properly. The honest answer is that quotes for the same brief vary widely depending on who you ask and how much of the discovery work they do properly.

For orientation only: in the Australian small-firm market, a single well-scoped workflow built by an independent specialist generally sits in the low four figures, and a connected set of several workflows with training runs into five. Treat that as a way to sanity-check a quote rather than a price list. What actually varies is how much thinking happens before the building, and that is usually the part worth paying for.

What should be in a build quote regardless of who writes it:

  • A fixed price, in writing, before any building starts.
  • An explicit list of what is out of scope, which is more informative than the inclusions.
  • Named accounts and keys, in your firm's name.
  • Documentation and a handover, not just a working workflow.
  • A defined window during which fixes are included.
  • A change-order process, priced before the change happens rather than invoiced after.

The first workflow always costs more than the second. Discovery, account setup, conventions and error handling are largely one-off. If a provider prices your third workflow the same as your first, ask why.

What does it cost to keep it running?

Budget maintenance as a real line rather than zero, because zero is the number that turns a working automation into an abandoned one. Connected apps change their APIs, a login expires, a supplier renames a field in their export, and something stops.

A sensible planning assumption for a small firm is a few hours a year per workflow, weighted towards the first year while the edge cases surface. That might be your internal person, a support arrangement, or an occasional paid call to whoever built it. Pick one deliberately.

The other ongoing cost is exceptions. A good workflow handles the common path and stops on anything unusual, which means someone still deals with the unusual cases. That is correct behaviour, not a defect, but it means the saving is never one hundred per cent of the manual time. When you model the benefit, assume you keep some of the work.

What is the payback test?

Divide the total first-year cost by the monthly saving. If the result is more than about twelve months, it is probably not the right first automation, even if it is a real problem.

Total first-year cost is the build, plus twelve months of platform and model fees, plus your maintenance assumption, plus a fair estimate of internal hours during the build. Monthly saving is the hours returned multiplied by the loaded hourly cost, discounted for the exceptions you will still handle manually.

That test does two useful things. It stops you automating something impressive but rare, and it gives you a defensible reason to say yes to something dull but constant. The dull constant ones are almost always the better first build.

What to do next

Pick the process that annoys you most and cost it out this week using the frequency, duration and loaded-rate calculation. Do it for two more processes so you have something to compare. That hour of arithmetic will tell you more than any quote.

Then take the one with the shortest payback, get a fixed-scope quote for it, and insist that the five cost layers are all named in writing rather than folded into a single number. A short paid scoping exercise before any build is the cheapest way to find out whether the maths works, which is how Shift starts every engagement, and occasionally how it ends one.

Common questions

How do I work out what a manual process is costing us now?

Multiply how often it happens by how long it takes, then by a loaded hourly cost for whoever does it. The loaded cost is their salary plus superannuation, leave, payroll tax and tools, divided by the hours they actually work in a year. If the work is done by someone who could otherwise be billing, use their charge-out rate instead, because that is the real number you are losing.

Is the AI model usage expensive?

For most small-firm workflows it is one of the smaller lines, because the volume is low. A workflow that runs a few hundred times a month on short documents is usually a modest monthly cost, while one that reads long documents thousands of times a month is not. Estimate it before you build by multiplying your monthly runs by the rough size of each run and checking the provider's current published rate.

What ongoing costs do firms forget?

Three: API access on tools they already pay for, which is often gated behind a higher plan tier; maintenance when a connected app changes something; and the internal time to handle the cases the workflow deliberately does not cover. None of these are large individually, and all three are commonly budgeted at zero.

When is automation not worth the money?

When the process runs rarely, when it changes every few months, or when nobody has written down how it actually works. In those cases the build cost is real and the saving is not. Fix or document the process first, then look again in six months.

Next step

Work out what yours is costing.

The calculator on the home page takes about ten seconds, and the fit call is thirty minutes with no deck. If the honest answer is "not yet", you'll hear that.