What to automate first when you run an SME with 5–20 staff
Most owners we meet pick the wrong first project — usually the most visible one, not the most leveraged one. Here's a rubric for picking work that pays back in weeks, and the failure pattern that kills strategies before they ever ship.
We get the call about once a month. An SME owner — usually 5 to 20 staff, somewhere between SGD 2M and SGD 15M revenue — has been told by a friend, a vendor, an article, or their accountant that they should "be using AI." They've watched the same three demos as everyone else. They want to start. They don't know where.
Almost every owner picks wrong on the first round. Not because they're bad at picking, but because the obvious answer — "automate the thing that annoys me most" — is rarely the same as "automate the thing that pays back fastest."
Here's the rubric we walk through in the first 30 minutes of a discovery call. It's not glamorous. It's just the question set that has, more than once, saved an SME a full year of building the wrong thing.
The rubric (four questions)
1. How many hours per week does this task consume across the team?
Not "how often does it happen." Hours. Add up the partial attention from anyone who touches it. A 15-minute task that lives in three different people's heads — once each, every day — is a 4-hour-per-week task, not a 15-minute one.
If the answer is under 4 hours per week, automating it is rarely worth the build cost or the ongoing maintenance burden. Below that line, scripts and templates almost always beat agents.
2. Is it the same task every time, or does it require judgement?
The honest version: how much of this work could a new hire do correctly on day one if they had a checklist?
Tasks where the answer is "most of it" are excellent automation candidates. Tasks where the answer is "almost none of it, you need to know the customer" are bad ones — those need the agent to act as a co-pilot, not a replacement, and that's a much harder build.
A good gut-check: if the task has more than five "it depends on" branches, you don't have an automation problem. You have a knowledge-management problem, which AI helps with but doesn't solve.
3. What's the cost of getting it wrong once?
This is where most pitches go sideways. An AI agent that drafts your social posts can be wrong daily without anyone noticing. An AI agent that pays your suppliers can be wrong once and ruin your week.
We sort tasks into three buckets:
- Reversible, low-stakes. Drafting marketing copy, summarising meetings, suggesting categories for an expense. Ship fast.
- Reversible, medium-stakes. Drafting customer replies, sending invoice reminders, scheduling. Ship with a human-in-the-loop approval step.
- Irreversible, high-stakes. Anything that moves money, signs documents, or makes legal commitments. Don't automate end-to-end. Automate the drafting; keep the signing human.
Owners who lead with the third bucket as their first project will burn six months and end up trusting AI less, not more.
4. Will the workflow change in the next 12 months?
If you're about to switch accounting systems, restructure your sales team, or change your pricing model, automating the current process is a tax on your future self. Wait three months. Or pick a different project that is actually stable.
This is the question that kills the most premature builds. The answer is almost always "yes, kind of, we've been talking about it." Probe harder.
The failure pattern: building the demo, not the workflow
Here's the pattern that kills SME automation projects more often than any technical issue. We've watched it happen at least seven times in the last year, often after the owner has already paid a vendor.
Someone — internal or external — builds a clever proof-of-concept on a clean dataset. The demo looks great. Everyone is excited. The owner approves a budget. The build moves to production data, and immediately:
- The data is messier than the demo data — duplicates, missing fields, free-text where there should be picklists.
- Three edge cases that didn't exist in the demo now break things in obvious ways.
- Nobody in the team owns "running" the new system. It runs, fails, sits broken for a week, and goes quiet.
The cost of this pattern isn't the failed project. It's that the next time someone proposes automation, the owner says "we tried that, it didn't work" — and now their actual leverage is locked behind a year of bad memories.
The fix isn't building better demos. It's choosing first projects with these properties:
- The data is already in a structured system (a real accounting platform, a real CRM) — not in WhatsApp or "John's brain."
- A specific person on staff is named as the owner of the running system, with explicit time budgeted to monitor it.
- The success metric is operational ("hours saved per week," "DSO reduced by X days"), not aspirational ("we're now an AI-first company").
So what should you actually pick first?
For the SMEs we've onboarded, the answer almost always falls into one of three categories:
- AR / collections — high-volume, structured data in your accounting system, repetitive language, immediate cash impact. This is why it's the most common first project we run.
- Reporting and weekly close — pulling together the same five reports the same way every Monday for the same audience. Pure leverage, near-zero downside.
- Inbound triage — first-touch responses on email or WhatsApp, where 80% of inbound is the same five questions and the agent's job is to answer those, qualify, and book. Hand off to a human after that.
If your operation doesn't look like one of these three, the right first move is usually to do nothing for another quarter — and instead clean up the underlying data so a future automation has something to work with. That's a less satisfying answer than "let's build something now," but it's almost always the right one.
If you want to walk your own situation through this rubric with us, book a 30-minute discovery call. We won't pitch you a build unless you actually need one.