"So, where do we actually start?"
Last month I spent a little over two hours with a manufacturing company CEO. It was our third meeting, and by then his team had already decided to move ahead with automation. But the first question out of his mouth, before we'd even settled in, was this: "So — what do we do first?" The decision was made, but the first step was still a fog. That gap between resolve and execution is exactly where most companies stall out.
In the previous post, I laid out the 5 patterns behind failed automation projects. The question on the other side of that coin is the subject of this post: so how do you make one succeed? The answer isn't flashy. You clear three gates — Diagnosis → PoC → Operation — with a defined set of deliverables and decision criteria at each one.
Stage 1. Diagnosis — Candidate Selection and ROI Estimation (1–2 weeks)
The most common mistake happens right here. Companies throw the question "where in our operations should we automate?" at a consultant and then wait for the consultant to bring back an answer. The order has to be reversed. The answer already lives on the shop floor — the outside advisor's role is to organize it.
The diagnosis stage has three goals. First, list 5–10 candidate tasks for automation. Second, measure the current processing time, throughput, and error rate of each task in numbers (without these numbers, you'll have no way to measure impact later). Third, narrow it down to just 1–2 candidates for the PoC.
To narrow the field, multiply three factors: how repetitive the task is, how clear its rules are, and how low the risk is if it fails. Any task with ambiguous rules or where half the cases are exceptions gets cut from the list — no matter how many hours it burns. Pick that kind of task for your first PoC, and when it fails, the company's entire automation budget goes up in smoke with it.
Only sketch out the ROI at this point. Not precise numbers — just the right order of magnitude. If a 40-hour-per-month task drops to 10 hours, what's that in labor cost? How many months to recover the implementation fee? I covered the specifics of designing these metrics in Episode 3: ROI and KPI Design Guide, so I won't repeat it here.
Diagnosis stage deliverables: ① a candidate task list (5–10 items, prioritized), ② a snapshot of current metrics (baseline), and ③ 1–2 PoC targets with a written success criteria document.
Stage 2. PoC — A 2–4 Week Pilot and a Cold-Eyed Gate (2–4 weeks)
This is the meatiest stage. And most of the problems get decided here. Let's start with what a PoC actually is. A PoC is not "an experiment to see if automation works." That's a tech demo. A PoC is a small-scale run under real operating conditions, whose purpose is to produce data for a go/no-go decision on full adoption. Lose that definition and the PoC ends with "well, it kind of works" — and no one ever uses it.
The standard 4-week PoC flow
Industry convention puts SMB PoCs at 3–4 weeks. Any shorter and you can't validate anything; any longer and the budget and patience burn out first.
| Week | What to do | Deliverables |
|---|---|---|
| Week 1 | Technical validation. Tool selection, minimum working setup with real data | Working prototype, technical risk notes |
| Weeks 2–3 | On-the-ground staff use it in parallel with real work. Collect edge cases | Usage logs, exception list, feedback notes from staff |
| Week 4 | Metric comparison, go/no-go meeting, full-adoption quote | Comparison report, decision document, operational rollout plan |
This is when you lock in the tools. For rule-based repetitive work, something in the n8n / Make family. For work that needs conversational judgment, combine an LLM. For internal system data processing, an in-house script. The reasoning behind these categories is covered in Episode 2: RPA vs. Workflow vs. AI Agent.
Nail down success criteria in writing, up front
This one part deserves the seriousness of a contract. If you don't document the definition of "the PoC went well" up front, then four weeks later everyone will claim success — or failure — by their own private yardstick. Here's what I usually write:
- Quantitative criterion: Reduce processing time for the target task by at least 20% vs. baseline. (Industry cases often show 40–70% reductions for repetitive tasks, but I set 20% as the minimum PoC pass line.)
- Qualitative criterion: At least one frontline staff member explicitly states they "support full adoption." (If they oppose, immediate re-review.)
- Stability criterion: During the parallel-use period in weeks 2–3, zero errors that halted work.
If even one of these three isn't cleared, it's a no-go. A no-go isn't a failure — it's a success in the form of "we spent 2–5M KRW to avoid a hundreds-of-millions misjudgment." Unless the whole team internalizes this framing, PoCs always get forced into a "go" verdict, and then quietly die six months later.
On the cost side, briefly: SMB PoCs in the Korean market typically run 2–8M KRW, starting around 2–5M for manufacturing. Government support programs (like the AI voucher) can lower the real burden further. For the specific cost breakdown structure, see Episode 5: Cost and Budget Guide.
Stage 3. Operation — Measurement, Expansion, and Not Being Forgotten (Ongoing)
Half of the automations that clear the PoC end up abandoned within six months, sitting in a "yes, it runs, but no one's watching" state. The real work of the operation stage is embedding the automation into the company's daily rhythm — not adding new features.
In the first month of operation, set up three things. A metrics dashboard (updating itself weekly, in a form that doesn't require someone to babysit it), a designated owner and backup owner, and a monthly 30-minute review meeting. If even one of these is missing, then when the time comes to discuss expansion, you'll have no evidence to work from and end up repeating the diagnosis stage from scratch.
From a security and governance angle, when you enter operation you must review your log collection setup and access permission policy. This is especially true when an LLM is in the loop — the PII masking, audit logs, and guardrails covered in Episode 6: Security and Governance are the essential checklist for the operation stage.
Don't rush expansion, is my strong advice. Waiting until your first automation has run stably for 3–6 months before moving to the second candidate is much faster than trying to scale three at once and knocking over all three. The speed at which the company accumulates the muscle memory of "automation works here" is ultimately what determines the pace of expansion.
Closing the Series — Eight Episodes as a Single Map
This post brings the eight-episode series The Practical Guide to SMB Business Automation to a close. We drew the overall outline of the map back in Episode 1 (concepts, types, and adoption roadmap), then walked step by step through tool comparison (Ep. 4), cost (Ep. 5), security (Ep. 6), failure patterns (Ep. 7), and this final execution plan — following, one footprint at a time, the path a decision-maker needs to walk to judge whether to adopt automation.
To be honest: reading all eight episodes doesn't automatically make your automation project succeed. But I do think it lets you avoid at least three of the five points where projects fail. If you're just starting out, I'd suggest going back to the Episode 1 hub post and looking at the map again.
At 5years+, we've supported SMBs in Korea and Japan through every stage covered in this post — diagnosis, PoC, and operation. The diagnosis stage in particular starts from an initial consultation with no upfront retainer — we help sort candidate tasks together, calibrate the ROI order-of-magnitude, and assess whether there's anything worth moving into a PoC. You can see the full service scope on our automation consulting page.
"Is automation even right for our company?" — that's a fine question to start with. Request a free diagnosis below and someone from our team will reach out directly.