Most automation projects fail on the job, not the tool
Ask a Hong Kong SME owner why their last automation attempt fizzled out and you rarely hear "the software was bad". You hear something closer to: it was set up for a task that only came up twice a month, or nobody trusted the output, or the person who built it left. The tool was fine. The job was wrong.
This piece is about choosing the job. It is a practical filter you can run before you spend anything, and a cheap way to test the choice before it becomes a monthly bill.
Start with a task inventory, not a tool list
Before you look at any platform, spend one week writing down every repetitive task in the business. Not the interesting work — the boring, repeated, rule-following work. Use a plain spreadsheet with four columns:
- Task — what actually happens, in one sentence.
- How often — per day, per week, per month. Be honest.
- Minutes each time — time it twice, then average.
- Who does it — a person, and which person.
Typical entries from small Hong Kong businesses look like: copying enquiry details from a web form into a spreadsheet, sending the same six answers to WhatsApp questions, chasing unpaid invoices, re-typing supplier prices into a quote template, or writing the same follow-up email after a quotation goes quiet.
Do not skip the timing column. Owners routinely overestimate how long a task takes by a factor of two or three, because they remember the annoying version, not the average version.
Score each task on four questions
Now put the spreadsheet through a filter. A task is a good automation candidate when most of these are true:
- Is it repeated? Daily or several times a week beats once a month. Setup effort is fixed; frequency is what pays it back.
- Are the rules stable? If the correct answer changes every time based on judgement, a human is still cheaper.
- Is a mistake cheap to catch? Drafting an internal summary is low risk. Sending a price to a customer is not.
- Can you describe a good result? If you cannot write down what a correct output looks like in two or three sentences, you cannot test the automation either.
Tasks that pass all four are where automation tends to stick. Tasks that pass one or two usually become a subscription nobody opens.
Where automation usually pays off for a small team
In practice, the wins cluster in a few unglamorous places. First-draft replies to common enquiries, where a person still reviews before sending. Turning a form submission into a structured record so nobody re-types it. Summarising long email threads or meeting notes into a short internal brief. Reminders and follow-up nudges on a schedule. Sorting incoming messages into "needs a human now" and "can wait until Thursday".
Notice what these have in common: the output goes to your own team first, not straight to a customer. That single design choice removes most of the risk and most of the trust problem.
Where it usually does not pay off
Automation tends to disappoint when the task is rare but dramatic — the once-a-year tender, the unusual complaint. It disappoints when the input is messy and unstructured in a different way every time. It disappoints badly when the output goes directly to a customer with no review step, because one confident wrong answer costs more trust than the hours you saved.
It also disappoints when the underlying process is broken. Automating a confused approval chain just makes confusion arrive faster. Fix the process on paper first, then automate it.
A two-week test that costs almost nothing
Pick the single highest-scoring task from your spreadsheet. Then run this before committing to any annual plan:
- Collect real examples. Pull 30 to 50 genuine past cases of that task — actual emails, actual enquiries, actual invoices. Not invented samples.
- Write the acceptance test. One page: what a correct output must contain, what it must never contain, and who checks it.
- Run it in draft-only mode. The automation produces output; a human sends or approves everything. No exceptions for two weeks.
- Count three numbers. How many outputs the human accepted unchanged, how many needed edits, how many were wrong in a way that mattered.
- Compare against the clock. If reviewing the drafts takes longer than doing the task, stop. That is a real answer, not a failure.
Two weeks of draft-only running tells you more than any demo. It also gives you the sample outputs you will need later if you ever want to loosen the review step — and it shows your team exactly where the system is weak.
Decide with a rule, not a feeling
Set the bar before you start, so the decision is not a negotiation afterwards. A workable rule: proceed only if the human accepts most drafts unchanged, the errors that matter are near zero, and the time saved per week is clearly more than the time spent reviewing. If two of those three fail, the task is not ready — pick the next one on the list instead.
One more thing worth building in from day one: a written record of what data the automation touches and where it goes. If you are unsure what your current setup already holds, our team can help you map it — see how we work with Hong Kong SMEs.
Summary
Automation succeeds or fails on task selection long before tool selection. Inventory your repetitive work with honest frequency and timing, then score each task on repetition, rule stability, cost of error and whether you can define a good result. Favour tasks whose output goes to your own team first. Test the top candidate for two weeks in draft-only mode against real past examples, count accepted versus edited versus wrong, and decide with a rule you set in advance. If you want help building that test or pricing the build, our pricing page sets out what a project like this actually involves.