How a First Workflow Gets Built, Week by Week

“We will automate your intake process” is not a plan, it is a heading. Here is what the weeks actually contain, so you can see where your time goes and where these projects usually slow down.

Timings below are typical for one workflow. Bigger scopes stretch, they do not compress.

Week one: watching the work happen

We sit with whoever runs the process today and watch them do it. Not a meeting about the process, the actual process, narrated while it happens.

This consistently turns up steps nobody mentioned in the initial conversation, and they are usually the ones that matter. The check somebody does before sending. The account that bills differently. The colleague who gets called when a number looks wrong.

What we need from you: a couple of hours from the person who actually does the work, not a summary from someone who manages them.

Where it slows down: when the only available person is the owner, describing a process they have not personally run in two years.

Week two: deciding what runs and what waits

We come back with the process written down and a proposal: which steps run unattended, which get staged for approval, and what happens when something fails.

This is the meeting worth taking seriously. It is where you decide how much control to keep, and it is much cheaper to decide now than to rebuild later. Most people start conservative and loosen it after a month of watching. That is a sensible instinct.

What we need from you: a decision on the approval boundaries, and credentials for the systems involved.

Where it slows down: access. Almost always access. Somebody has to find who administers the CRM, and that person is on holiday.

Weeks three and four: building it

The connections get made, the logic gets built, the approval step gets somewhere to live. You see it working before it is finished, on your real data, because a demo on invented data proves very little.

Expect at least one surprise here. A tool’s API does not do what its documentation claims, or the data is messier than anyone thought. We will tell you when that happens and what it changes.

What we need from you: to look at it once or twice mid-build and say whether it matches what you expected.

Week five: running it alongside the old way

The workflow runs, and for a short period you keep doing it the old way too. That feels redundant and it is the cheapest insurance in the project. It catches the cases nobody anticipated while the cost of catching them is low.

This is also when the corrections start, and corrections are the point. Each one gets written into the instructions the system reads, so it stops recurring rather than being fixed repeatedly.

What we need from you: to actually use it, and to tell us when it is wrong rather than working around it quietly.

After that

The old way stops. We write a short runbook covering what it does, what to check, and who to call. If there is an ongoing arrangement, monitoring moves to us.

Then you decide whether there is a second workflow worth doing. Usually there is, and it is faster, because the connections already exist.

The honest version of the timeline

Five weeks is what it looks like when access arrives promptly and the right person is available. The two things that reliably add weeks are credentials nobody can locate and a process that turns out to be three processes wearing a coat.

Neither is a disaster and both are easier to handle when you are expecting them.

Here is how the phases and pricing work, or get in touch if you have a process in mind.