Automation · 8 min read
What automation is worth, and what it is not
Automation is the third most requested thing we see. Most of what people want automated is not worth automating — and the test that separates the two takes about a minute.
Updated 29 August 2026 · GoDesign build team
The short version
- Automation appears in 3,015 of 27,169 briefs — the third largest category after e-commerce and maintenance.
- Worth automating: frequent, identical, and currently done by a person who costs money. Missing any one of the three usually kills the case.
- The cost people forget is maintenance. An automation is a small piece of software and it breaks when anything it touches changes.
- Handoffs beat tasks. The highest returns come from automating the gap between two people, not the work inside one person's job.
Automation shows up in 3,015 of the 27,169 project briefs we hold, behind only e-commerce and maintenance. That makes it one of the most requested categories, and in our experience one of the most frequently misapplied, because the enthusiasm for automating something is only loosely correlated with whether automating it pays.
The three-part test
A task is worth automating when all three of these are true. Missing any one of them usually means the project costs more than it returns, however satisfying it would be.
- It happens often. Weekly at minimum; ideally daily. A quarterly task takes years to repay the build even if it takes an hour each time.
- It happens the same way every time. Automation handles the identical case well and the exception badly. A task with four common variations is four automations, or one fragile one.
- A person currently does it, and that person's time has a cost. Automating something nobody does yet is not a saving, it is a new feature with a saving-shaped justification.
The third one catches most of the bad cases. A great deal of what gets proposed as automation is not replacing manual work — it is adding capability, which may well be worth doing but should be justified as such rather than by a time-saving that does not exist.
The arithmetic, honestly
The naive version is: time saved per run, times runs per year, times an hourly cost, against the build cost. That version overstates the return in two specific ways, both of which matter.
| What the naive sum assumes | What actually happens |
|---|---|
| The task disappears entirely | Someone still checks the output, at least for a while |
| The saved time becomes productive time | Ten minutes freed up five times a day is rarely an hour of work |
| The automation runs forever unchanged | It breaks when a form field, an API or a tool it touches changes |
| Exceptions are rare | Exceptions are handled manually, and now with less context than before |
The third row is the one that catches people out. An automation is a small piece of software with dependencies, and dependencies move. A workflow connecting four services has four opportunities a year to break because one of them changed something. Budget for that, or the automation quietly stops working and nobody notices until the consequence surfaces.
Automate handoffs, not tasks
The highest-return automations we see are almost never a person's task being replaced. They are the gap between two people being closed.
A sale closes and somebody has to tell delivery. An enquiry arrives and somebody has to assign it. A form is submitted and somebody has to create the record. In each case the work itself is seconds; the cost is the delay, the things that fall through, and the follow-up conversation to check whether it happened. That is where automation pays, and the payoff is reliability rather than time.
It is also why onboarding is such a consistently good candidate. New client onboarding is frequent, near-identical, spans several people, and every dropped step is visible to the customer at the exact moment their impression is forming.
What not to automate
- Anything where the exception rate is above roughly one in five. You will build the automation and then run it manually anyway.
- A process nobody has written down. Automating an undocumented process encodes whatever the last person did, including the parts that were wrong.
- A process about to change. Automating something three months before it is replaced is the most reliable way to waste the build.
- Judgement. If the step requires deciding rather than doing, automate everything around it and leave the decision to a person, with the context assembled for them.
The last one is worth expanding, because it is the highest-value pattern available and it gets missed. Most processes that look unautomatable because of one judgement call can be automated everywhere except that call, so the person is presented with a decision and everything needed to make it. That is usually most of the benefit at a fraction of the risk.
Questions people ask
How do I know if a task is worth automating?
Three things must all be true: it happens at least weekly, it happens the same way nearly every time, and a person whose time costs money currently does it. Missing any one of the three usually means the build costs more than it returns. The third condition rules out most proposals, because they add capability rather than replacing manual work.
How do I calculate automation ROI realistically?
Start with time saved per run times runs per year times an hourly cost, then treat about half of it as real in year one. The naive figure ignores output checking, manual exception handling, the fact that small freed intervals rarely become productive work, and the maintenance an automation needs when the tools it connects change.
What is the best thing to automate first?
A handoff between two people rather than a task inside one person's job. Sale to delivery, enquiry to assignment, form to record. The work itself takes seconds; the cost is the delay and the things that fall through, and closing that gap buys reliability rather than time. Client onboarding is the most consistently strong candidate.
What should not be automated?
Anything with an exception rate above roughly one in five, any process nobody has documented, anything about to change, and judgement itself. For the last one, automate everything surrounding the decision and present the person with the choice and the context — usually most of the benefit at a fraction of the risk.
Do automations need maintenance?
Yes. An automation is a small piece of software with dependencies, and those dependencies change. A workflow connecting four services has four chances a year to break because one of them altered a field or an API. Budget for that upfront, or the automation stops silently and the failure surfaces as a consequence rather than an alert.
Built by GoDesign FZE, who build WhatsApp and CRM automation for UAE businesses.
Get in touch
Want someone to just do this part?
The tool is free and stays free. If you would rather hand the work over, tell us what you are dealing with and you get a straight answer on scope, cost and timeline.
- You own everythingRepository, hosting and domain credentials sit in your name from day one, not handed over at the end.
- A written timelineMilestone dates are agreed in writing before work starts, so you always know what ships next.
- One business dayEvery enquiry gets a reply from the person who would scope the work, not a sales sequence.
Media City, Dubai, UAE · DHA Phase 2, Islamabad, Pakistan
Would rather type than fill in a form?
Message on WhatsApp