Workflow automation for SMEs: where to start and what to skip

Photo by Brett Sayles

Most of the writing on workflow automation is aimed at companies with dedicated IT departments, six-figure tool budgets, and change management teams. I get it — that's where the big contracts are. But it's not very useful if you're running a 20-person logistics company trying to figure out what to actually do.

I've spent the last year doing discovery calls with exactly this kind of company. Here's what I've seen work, what I've seen fail, and what I'd recommend if you're starting from scratch.

The first mistake: trying to automate everything at once

Automation ambition tends to outrun automation readiness. I've talked to companies that want to build a "fully automated operations backbone" before they've successfully automated a single process end-to-end. That almost never works.

The mechanics are simple: every process you automate requires scoping, integration, testing, and maintenance. If you do ten at once, you have ten half-finished automations that each have edge cases you haven't handled. That's worse than manual. One process, done properly, is better than ten processes done sloppily.

My advice: pick one process. Ideally the one that's most repetitive, best-defined, and where errors are catchable (not catastrophic).

How to identify your best first automation candidate

I use a simple mental test when I'm evaluating processes with clients. Ask three questions:

How often does this happen? A process that happens twice a week is a different proposition than one that happens fifty times a day. More frequency means more time saved and faster payback on build cost. If it only happens occasionally, it's probably not worth the investment at your current scale.

How consistent is the input? If the input varies a lot — different formats, missing fields, inconsistent naming — automation becomes harder. Not impossible, but harder. A process where input arrives in a predictable form is a better starting point.

What happens when it goes wrong? Some errors are recoverable. An invoice processed incorrectly can be corrected. A patient medication record processed incorrectly is a different matter. Start with processes where mistakes are visible and fixable.

What "workflow automation" actually means at SME scale

At enterprise scale, "workflow automation" often means expensive BPM platforms with hundreds of configured rules. At SME scale, it usually means something much simpler: one or two pieces of software that you already use, connected to each other so that a human doesn't have to copy data between them.

The most common pattern I see: a company receives information via email (invoices, orders, enquiries, CVs) and someone manually enters that information into a CRM, ERP, or spreadsheet. That's the process. The automation is: read the email, extract the data, push it to the system. Simple in concept, still requires real engineering work in practice — but the scope is bounded.

The integration question: what you're actually connecting

Every automation connects at least two systems. Before you commit to building anything, it's worth checking: do those systems have usable APIs?

Most modern SaaS tools do. Older or heavily customised enterprise software sometimes doesn't — or has APIs that are technically available but poorly documented and unreliable. I've had projects where the primary blocker wasn't the AI logic, it was getting reliable access to a client's legacy system.

This is worth investigating before you scope anything. It's a 30-minute question, not a week-long one. Ask your tool vendors: does this system have an API? Can I access it? What are the rate limits?

A word on "no-code" automation tools

Tools like Make, Zapier, and n8n are genuinely useful for simple automations. If you need to move data between two systems and the logic is straightforward, these tools can do it without custom development. I recommend them for exactly that use case.

They stop working well when: the process has significant branching logic, the inputs require interpretation (not just matching), or you need to maintain behaviour across system updates reliably. That's when custom AI agent development makes more sense. The tools aren't mutually exclusive — we often use them as part of a larger automation architecture.

Realistic expectations on timeline and cost

I want to be honest about this because the AI space has a tendency to undersell timelines and oversell speed. A properly scoped, properly tested automation for a real business process takes weeks, not days. The work isn't just writing code — it's understanding the process deeply enough to handle edge cases, integrating with existing systems that were never designed for this, and testing against real data.

For a single-workflow agent at a small company, a realistic range is 3–6 weeks from kick-off to stable deployment. Simpler processes are faster. Multi-system integrations take longer. Budget-wise: the starting point for custom work at SynthetixBiz is €1,500, but complex projects cost more. The only way to get an accurate number is to scope it properly first.

The one thing that predicts success more than anything else

I've noticed one pattern across projects that go well versus ones that hit problems: the clients who can walk me through their process step-by-step — who have actually documented it, even loosely — are the ones whose automations work quickly. The clients who say "we kind of do it this way, but it depends" take longer and hit more edge cases.

If you're reading this before starting an automation project: spend a few hours documenting how the process actually works today. Every input type you encounter. Every decision point. Every exception. That document is worth more than any tool or platform decision you could make.