From First Call to Running System: How an Automation Project Actually Goes

The most common question in a first call is rarely "what does it cost". It is: "How does this actually work?"

The second most common follows straight after: "And how long does it really take?" Both are fair, and both rarely get a clear answer, because agencies avoid talking about the weeks in which the client has to work. Here is the process as it actually runs with us, in six phases, with real timings.

Phase 1: Taking stock, 1 to 2 weeks

It starts with a list. No tool, no workflow yet. We want to know what happens in your business every week and how much time it eats.

Three concrete things happen. We sit down for two hours and walk through your week, process by process. We look into your systems, usually shop, fulfilment provider, inbox, bookkeeping, and check the state of your data. And we ask you for a tally sheet across five working days: every task you do more than once, with an estimated duration.

The tally sheet is the most important part, and the one clients most like to skip. It is uncomfortable, because it shows that three hours a day drain away into things nobody planned. That is exactly the point. What that calculation looks like is in The true cost of manual processes.

At the end of this phase you have a list: every recurring process, estimated hours per week, systems involved, how stable it is.

Phase 2: Prioritising, 2 to 3 days

Now we sort. Sorting runs along two axes, time saved per week and effort to build. How exciting something sounds plays no part.

The top of the list is almost always the same. For e-commerce brands it is order processing, support requests about parcel status, and reporting. With our own brands the order came out the same way, as described in Automating e-commerce processes.

More important than the order is what we throw out. We advise against anything that costs less than 2 hours a week, against processes that are still changing, and against tasks where a mistake really hurts. With one client we cut two of five wish-list processes last year. A provider who never advises against anything will sell you everything, including the wrong thing.

The result is a roadmap in waves. Wave 1 is exactly one process. Not three. Exactly one.

Phase 3: The first process, 2 to 4 weeks

This is where building happens, and where the part almost nobody plans for shows up: before anything gets automated, the process has to be clean.

We write it down, step by step, including every exception. And regularly it turns out that two people do it differently, or that there is a special case only one person knows about. This clean-up often costs more time than the actual building. It appears in no quote, and you pay it anyway, one way or another.

After that the technical chain gets built. Set up access, connect systems, build the logic, handle the errors. That last point is the biggest job. Roughly 90 percent of our build time goes into the question "what happens when this breaks?". The happy path is built in a day, the 30 exceptions behind it take weeks.

Two weeks is realistic for a clear process with clean data. Four weeks is realistic when several systems are involved or a supplier still has to grant API access. If someone promises you a complete order flow in three days, they mean the happy path.

Phase 4: Shadow testing, 1 to 2 weeks

No system goes live straight away with us. It runs in shadow mode first.

That means: the workflow processes real cases, and it sends nothing outward and changes nothing. It only records what it would have done. You compare that with what actually happened.

Then comes the middle stage: the system prepares, a human approves. In support that is draft replies you check and send. In purchasing it is a suggested order you approve. Only once you have gone weeks with almost no corrections may the standard case run on its own.

With our own support this path took months. First only categorising, then answering a single question automatically, then more. Today around 65 percent of requests go through without us, and WISMO questions, meaning "where is my parcel", make up about 40 percent of the volume. Those numbers are the result of two years of trust built step by step. No launch produced them.

One more thing gets settled in this phase, before anything goes live: the escalation rules. When does the system stop? When does it call a human? Who gets the alert? Sort that out afterwards and you sort it out during the emergency.

Phase 5: Handover, 2 to 3 days

A system only its builder understands is a time bomb. Our handover consists of four things.

• Access. The workflows run on your infrastructure or you have full access. Who owns the automation is the most important question in any quote, see What automation really costs.
• Documentation. What runs when, which systems are connected, what the system does when something fails.
• A training session. One hour in which we trigger an error together and fix it. Live, no video.
• The emergency exit. How you switch the thing off when it does something stupid. Almost nobody asks this question, and it is the most important one.

Phase 6: Operations, ongoing

The point where most projects quietly die. An automation project does not end at launch. It moves into operations, and operations cost time.

Budget 2 to 4 hours a month per serious setup. APIs change, Shopify moves a version on, a fulfilment provider changes its file format, a new supplier needs a new rule. An automation without maintenance rots, and a rotten automation is worse than none, because it quietly does the wrong things.

Monitoring belongs to that. With us every error goes out as a Slack message. Without it you fly blind and only notice from a customer call that nothing has run for four days.

And then wave 2 begins. That is the real rhythm of an automation project: one process, in operation, next process. Nothing all at once.

What you have to contribute yourself

This is the part quotes like to leave out. Plan 10 to 20 percent of the project scope as your own time. Concretely:

The item that delays projects most often is the second row. Getting access to a fulfilment system or a marketplace account sometimes takes three weeks, because somebody there is on holiday. That has nothing to do with technology, and it costs real calendar weeks. Start on it on day one.

The second most important item is the special cases. Nobody knows them as well as you do. Name them only once the system gets them wrong and it gets expensive.

How long it really takes

For a first, clearly scoped process: 6 to 10 weeks from the first call to running unsupervised. Roughly 3 to 5 weeks of that is build time, the rest is taking stock, testing and waiting for access.

A complete setup across several processes, so order processing plus support plus reporting, lands closer to 4 to 6 months. In waves, not in one go.

Our own brands are the best example. The 33 to 46 hours we save every week today grew over three years. At mate, order processing went from 4 hours a day to 15 minutes, at MUSTAX reporting went from 2 days to 2 hours. Both were separate projects, months apart. The full picture is in 3 brands with 2 people.

Why projects fail

Three reasons, in this order of frequency.

The process was never clean. Automation makes a bad process faster, and it stays bad. If three people do a task differently, you first have to agree on one version. That agreement is a leadership decision, and it has nothing to do with technology.

Too much at once. Start five processes in parallel and after three months you have five half-finished building sites and no time saved. One process, finished and running, beats five started ones. Always.

Nobody is responsible. After launch the system needs a human who reads the alerts and takes on those 2 to 4 hours of maintenance a month. With nobody named, nobody reads the alerts. One client of ours went four months without noticing that a partial workflow had stopped, because the alerts landed in a channel nobody had subscribed to.

A fourth reason, rarer and more expensive: the wrong moment. Automate only once you are already at your limit and you pay extra. Systems we built under pressure regularly cost more than planned ones, because there is no time for clean testing.

The limits of this process

So you do not get too smooth a picture:

• The timings apply to clear processes. With old systems that have no API, or processes that run over email and phone, the effort doubles quickly.
• Waiting times cannot be planned. Access, approvals, replies from service providers. We have seen projects hang four weeks on a single API key.
• Some processes should stay manual. Emotional customer cases, rare tasks, anything still changing. The list for that is in What automation really costs.
• The process assumes a decision. If nobody in the company is allowed to decide how a process will run in future, no phase plan will help you.

Conclusion

An automation project runs in six phases: taking stock, prioritising, a first process, shadow testing, handover, operations. For the first process, 6 to 10 weeks is realistic, for a complete setup 4 to 6 months in waves.

The part you cannot delegate is the special cases, the access, and the decision about how a process should run in future. The part almost everyone underestimates is the operations afterwards.

And the most important rule stands at the start: one process, finished, running. Then the next one.

If you want to know what your specific case would look like, write to us at Flowhouse. We do the audit with you, and if the effort does not pay off at your volume, we will tell you that too.