Start by measuring, not by buying
Workflow automation services get sold on a promise of hours saved, and the figure is almost always invented. We are not going to give you one either, because the honest answer depends entirely on what your team currently does by hand, and neither of us knows that until it is measured.
So the first step is not choosing a tool. It is timing what you do now. This is a guide to doing that properly and working out whether the arithmetic supports automating anything at all — including the cases where it does not.
The calculation, done honestly
Four numbers:
Time per occurrence. Timed, not estimated. Ask whoever actually does it to time themselves for a week. People consistently overestimate duration and underestimate frequency, and the error runs in both directions.
Frequency. Per week or month, from records rather than memory.
Fully loaded cost of that time. Not just salary. The opportunity cost matters more: what would that person be doing instead, and is it worth more?
Error cost. The part almost everyone omits. Manual data entry between systems produces mistakes, and mistakes cost time to find and fix plus occasional customer goodwill. Count the corrections, not just the original task.
Against that: the one-off build cost, plus running costs — platform subscription, any per-operation charges, and model usage if the workflow involves AI.
Payback is build cost divided by monthly saving. Under six months is clearly worth doing. Six to eighteen depends on whether the process is stable enough to still exist. Beyond that, do not.
Which tasks actually pay back
From the work we have scoped, a consistent pattern.
Moving data between two systems that do not talk. The highest-value category, every time. Entering the same information twice is pure cost with a built-in error rate, and it is usually daily.
Chasing documents and approvals. Someone remembering to follow up is a person doing a job a reminder should do. Automation here also improves the outcome, because the reminder never forgets.
Assembling the same report. Weekly or monthly reports built by hand from three sources. The build is straightforward and the saving recurs forever.
Routing incoming work. Deciding which queue an enquiry, order or ticket belongs in, and sending it there with context. Unglamorous and reliably worth it.
Generating documents from records. Invoices, confirmations, certificates. If the data exists, producing the document by hand is transcription.
What these share: rule-based, frequent, and currently done by a person following steps they could write down. That last part is the real test — if you cannot write the steps down, it is judgement, and judgement does not automate.
What not to automate
Anything requiring judgement. If the answer depends on context, relationships, or what a specific customer is like, leave it with a person. Automation can prepare the material and stop.
Anything done rarely. A quarterly task taking two hours is eight hours a year. The build will cost more than that and will have broken by the second quarter from disuse.
Anything whose underlying process is wrong. This is the important one. Automating a broken workflow makes the same mess faster, and with less visibility because nobody is watching the steps any more.
We map the manual process before building for exactly this reason, and it fairly often reveals that two of five steps should simply be deleted. That finding is worth more than the automation, and it is free.
Where the money goes
Build cost. Quoted fixed after the audit, because only then is the number of steps and systems known. A quote given before anyone has looked at your process is a guess, and it will be revised.
Platform subscription. Zapier, Make or similar, billed per task or operation. It goes in your own account so you see the usage and keep control if we stop working together.
Per-operation charges. Watch these at volume. A workflow running a thousand times a day on a per-task platform costs meaningfully more than the same workflow self-hosted, and the crossover point arrives sooner than people expect.
Model usage, if the workflow involves AI — document extraction, classification, drafting. Usage-based and easy to underestimate, so it should be estimated and capped during scoping.
Monitoring. Optional as a retainer, but error alerting belongs in the build itself. A silent failure is worse than no automation, because you find out when a customer tells you they never heard back.
Our pricing page sets out how we quote this, including what pushes the number up.
What breaks, and how to plan for it
Automations do not fail gracefully by default. They fail silently, which is the entire problem, and planning for it is a design decision rather than a support arrangement.
Third-party changes. A tool you connect to updates its API, changes a field name, or alters a rate limit. Your workflow stops and nothing announces it. This is the most common cause of failure and it is nobody's fault.
Data that does not match the assumption. The workflow was built expecting a phone number and receives a name with a phone number in it. Real data is messier than sample data, always, and the first month of live running is where this surfaces.
Volume. A workflow tested on ten records behaves differently at ten thousand, particularly on platforms with per-operation limits or rate caps.
Credentials expiring. An access token lapses and the workflow stops authenticating. Entirely predictable and still a common outage.
What protects you is unglamorous: alerting on failure so the system tells you rather than a customer, logging detailed enough to identify which step broke and why, and a documented manual fallback for anything business-critical. That last one matters most. If the invoicing automation stops, somebody needs to know how invoices got produced before it existed.
We build alerting and logging into every workflow rather than offering them as an upgrade, because an automation you cannot diagnose is a liability rather than an asset. Monitoring as a retainer is optional; being told when something breaks is not.
Choosing between hosted and self-hosted
Not a religious question. It follows from three things.
Volume. Below a few thousand operations a month, hosted platforms are cheaper all-in once you account for hosting and maintenance of the alternative. Well above that, self-hosting wins clearly.
Data sensitivity. If the workflow touches patient records, student records or payment data, keeping processing inside your own infrastructure is worth the operational overhead.
Who will maintain it. Hosted tools can be adjusted by a non-developer, which matters if you want to change a rule without calling us. Self-hosted generally cannot.
We recommend based on those rather than on preference, and for most clients the answer is a hosted platform.
The audit is the deliverable
Something worth saying plainly: the mapping exercise is often more valuable than the automation.
Sitting with whoever does the task and documenting what actually happens — including the undocumented steps people do from memory and the workarounds nobody mentioned — produces findings that do not need software. Steps that duplicate each other. Approvals nobody reads. A form field that has not been used in two years but is still collected.
On the admission enquiry form we cut, the biggest gain came from removing fields rather than automating anything. The same logic applies to internal processes: subtraction first, automation second.
If you want the audit without committing to a build, that is a reasonable thing to buy, and we would rather do that than automate something that should be deleted.
Sequencing several automations
Most businesses have more than one candidate, and the order matters more than people expect.
Do the highest-frequency task first, even if the saving per occurrence is small. Frequency compounds, and it also teaches you and us how your data actually behaves before anything important depends on it. A daily task that runs cleanly for a month is a much better foundation than a weekly one that has run four times.
Then do whichever task feeds the first one. Automations that chain tend to be worth more than the sum of their parts, because the handoff between them was itself a manual step somebody was doing. Two connected workflows often remove three tasks.
Leave anything touching money or compliance until last. Invoicing, payroll adjacency, tax-relevant records — these are worth automating and they are also where a silent failure is most expensive. Do them once the monitoring is proven on lower-stakes work and your team trusts the alerting.
One practical note: resist automating everything in one project. Six workflows delivered together means six things to verify simultaneously and no clear signal about which one caused a problem. Two at a time, a fortnight apart, gets there faster in practice.
A sequence you can follow
- Pick the task your team most resents. Resentment is a good proxy for repetitive and frequent.
- Time it for a week. Whoever does it, honestly, including the corrections.
- Write down the steps. If you cannot, it is judgement — stop here.
- Ask which steps could be deleted. Often two can.
- Then get it quoted, with the running cost separated from the build cost.
- Ask what happens when it fails, and expect alerting to be included.
Steps three and four are free and frequently end the exercise, which is a good outcome rather than a wasted one.
For the longer view on where automation fits alongside chatbots and lead handling, the AI and automation overview covers how the pieces relate.
