Short answer: anywhere from ten minutes to a few weeks — it genuinely depends on what you're automating. That's not a dodge; it's the honest range, and most of the variation comes down to a handful of predictable factors rather than random luck. Once you know what drives the timeline, it's much easier to set realistic expectations before you start.
A single-trigger, single-action automation — the kind that connects two tools with one clear "when this happens, do that" rule — is usually the fastest thing you'll ever build. Think: a form submission adds a row to a spreadsheet, or a new email in one inbox posts a message to a Slack channel.
If both tools have a native integration or are well-supported on a platform like Zapier or Make, this can take less than an hour from idea to working automation, testing included. These are a great place to start precisely because they prove the concept quickly and build confidence before you tackle anything bigger.
Most business automations that actually move the needle live here. This is a workflow with a few steps, some conditional logic (if the deal value is over £5,000, notify a manager; otherwise, proceed automatically), and two or three tools involved rather than just two.
A few days covers:
The build itself is often only a fraction of that time. Mapping the process — and catching the edge cases — is usually where the days actually go.
Automating an entire workflow end-to-end (say, everything from lead capture through to onboarding) or connecting a tool that doesn't have a tidy native integration will take longer. This is where you might be dealing with:
Even here, the sensible approach is usually to break the project into phases and launch pieces of it as they're ready, rather than waiting for one big-bang release. It gets value in front of the team sooner and makes testing far less risky.
It's rarely the automation platform itself. The things that stretch a timeline are almost always:
An unmapped process. If nobody has written down what actually happens today — including the "well, except when…" bits — that discovery work has to happen before anything gets built.
Access and permissions. Waiting on admin access to a tool, or approval to connect it, can quietly eat more time than the build itself.
Data quality. Automations are unforgiving about inconsistent data (three different ways of formatting a phone number, say). Cleaning it up first is often non-negotiable.
Scope creep. It's easy for "just connect these two tools" to grow into "and also handle these five exceptions we just thought of." Not a bad thing, necessarily, but it does mean revisiting the timeline.
| Type of automation | Typical time |
|---|---|
| Single trigger → single action, well-supported tools | Under an hour |
| Multi-step workflow with some logic | A few days |
| Cross-tool workflow needing custom setup (webhooks/API) | One to two weeks |
| Full end-to-end process automation, multiple linked workflows | Several weeks, ideally phased |
Treat this as a planning guide rather than a promise — the process-mapping stage is where estimates most often move, in either direction.
Simple automations can be live before your coffee's gone cold; more ambitious ones deserve proper time for mapping, testing, and refinement. The biggest lever you have over the timeline isn't the tool you choose — it's how well the process is understood before anyone starts building.
Not sure how long your process would actually take to automate? That's exactly the kind of scoping conversation we have at WoahFlow before any build starts — get in touch and we'll give you a realistic estimate for your setup.