What ninety days actually looks like

Deals in this category do not stall on price. They stall on not knowing what you are signing up for.

How much of my team’s time. How disrupted are we. What happens if it does not work. Who is doing what in week four. Nobody wants to ask all of that on a first call because it makes you sound nervous, so people say they will think about it and then think about it for four months.

So here is the whole thing in public, including the bad weeks.

The shape

Two weeks of audit, then roughly eleven weeks of building, then handover. The audit is $1,500 and is credited in full against the rewire if you go ahead. The setup itself is $6,500, and after handover it is $300 a month for support, updates and monitoring. At the end you own everything: the server, the accounts, the documentation, the lot.

The monthly is deliberately small, and it pays for support rather than access. Everything runs in your accounts on your server, and if we part ways it keeps running without us. Ask anyone else in this category whether the same is true of their subscription.

Weeks one and two: the audit

We map how work actually happens, which is different from how anyone thinks it happens.

That means sitting with the people who do the work rather than the people who describe it. It means timing things. It means finding the four places where a process quietly waits three days for one person, and the two places where two people are doing the same thing without knowing.

What comes out is a written map of your processes, a ranked list of what is worth automating, and an honest note on what is not. That last part is not filler. In most audits there is at least one process everyone assumed was the obvious candidate that turns out to be a bad idea, usually because it is judgement wearing an admin costume.

Some agencies find the audit is the whole product. They take the map, fix three handoffs themselves, and do not need us for the rest. We would rather that happened than have someone spend six and a half thousand dollars discovering it in month three. What the audit actually finds goes into the detail, including the things nobody wanted found.

One practical thing about the audit that people underestimate: it needs the people who actually do the work, not their managers. This is occasionally awkward to arrange, because the people who do the work are the busiest people in the building and their calendars are the hardest to get. Every audit that has produced a thin map has produced it because we only ever spoke to team leads. Insist on the practitioners.

Weeks three to five: the first process

One process, built end to end, in production, with real work going through it.

Almost always reporting or onboarding, because both are retrieval-heavy and both fail visibly. We are not looking for the biggest win here. We are looking for the fastest honest answer to whether this works in your agency with your data and your people.

Your team’s time in this phase is real: a few hours a week from whoever owns that process, plus a couple of sessions with whoever holds the passwords. Not a secondment. Not a project team. But not nothing, and any agency telling you their process requires nothing from you is describing a product they will run rather than a system you will own.

By the end of week five you have one process that is measurably different, and everyone has an opinion about it. Both of those are the point.

We also set the measurement up in this phase, before anything changes, because otherwise you will never be able to prove anything. Hours on the process now. Number of handoffs now. Elapsed time from start to client-ready now. Nobody enjoys spending week three writing down how long things currently take, and every agency that skipped it has later had an argument about whether the project worked.

Weeks six to nine: the trust dip

Here is the part most people selling this leave out.

Around week six, something goes wrong in a way that feels significant at the time. An agent produces a draft that is subtly incorrect. A monitor sends an alert that turns out to be nothing. Someone senior looks at an output and says, quite reasonably, that they could have done it better in twenty minutes.

That week is the hardest one, and it is not a sign of failure. It is the point where the novelty has worn off, the system is being used in anger for the first time, and its actual limits are becoming visible rather than theoretical. Ours had it too.

What gets you through it is having said in advance that it would happen, which is why we say it now, and having a specific response rather than a reassurance. The response is usually to narrow the scope of what the system is allowed to do, add a review step, and carry on. Systems that survive this phase are systems that got smaller at week six.

Meanwhile the second and third processes are being built, informed by everything the first one taught you. This phase is where most of the actual value gets created, and it is also the phase where an agency owner who is not being kept informed will assume nothing is happening.

It is also the phase where the second and third processes stop being copies of the first. Whatever you learn on reporting does not transfer cleanly to onboarding, because onboarding has a client on the other end of it and reporting does not. Expect each build to teach you something that invalidates a small assumption from the last one. That is the process working, not the process failing.

Weeks ten to twelve: hardening and handover

The last stretch is unglamorous and it is the part that decides whether this lasts.

Documentation, written for someone who was not in the room. Access transferred to your accounts, in your names. A written record of what each automation does, what it is forbidden to do, and what to check when it misbehaves. A standing review process with a named owner and a date in a calendar. If you want a standard vocabulary for that rather than ours, a published framework for governing this kind of system gives you one.

We also write down what we would do next, which is not a sales document. It is the list of things we did not get to, so that whoever picks it up in six months is not starting from archaeology.

Then it is yours. If you want us afterwards you can have us, and plenty of agencies do, but the design assumption is that you do not need us. What owning it actually means covers the handover in more detail, including what happens when you want to change something without us.

One thing worth doing regardless of how the build has gone: a short review at the end of week six. Not a status update. A structured conversation about what the system has produced, what was corrected, and what anyone is quietly worried about. Half the value is that it gives the internal sceptic a sanctioned place to say the thing they were going to say in the corridor anyway.

What your team actually has to do

The single most asked question, and the one most consultants answer with a shrug.

The process owner for whatever is being built gives roughly three to five hours a week during their process’s build phase. That is the real number and it is front-loaded into the first fortnight of each build.

Whoever administers your accounts gives about four hours total, mostly in weeks one and three, mostly clicking through access grants and swearing at two-factor authentication.

You, the owner, give about an hour a week, and it needs to be a real hour. Every rewire that has gone badly has had an owner who delegated it entirely and reappeared at week eight with opinions.

Everybody else gives nothing except a willingness to say when the output is wrong, which is worth more than any of the above.

One more, and it is the one people are shyest about asking. What if we hate it. The honest answer is that you will know by week five, which is why the first process is built in weeks three to five rather than being the final flourish. If the first one lands badly and the reasons are structural rather than fixable, stopping there is a legitimate outcome and we would rather have that conversation than grind through eight more weeks of something nobody believes in.

What goes wrong, in order of likelihood

Access takes longer than anyone plans. Every single time. Somebody has left, an account is in a former employee’s name, a client’s platform requires their approval and their approver is on holiday. Assume three weeks for what should take three days.

A process turns out not to exist. You go to automate it and find that four people do it four ways and none of them is written down. This is not a setback, it is the audit finding something late, but it costs a week and it feels like a setback.

Somebody senior disengages at week six. See above. Predictable, manageable, and much worse if nobody named it in advance.

Scope drifts upward. The first process works and everyone immediately wants the hardest thing on the list next. Resist this. The order exists for a reason and the reason is that trust is built with boring wins.

What ninety days does not get you

It does not get you a fully automated agency. It gets you three or four processes genuinely rebuilt, a working brain with your history in it, and the internal capability to do the next ones yourselves.

It does not get you a headcount reduction. If that is the goal, say so at the audit and we will tell you honestly whether the numbers support it, and in most agencies of this size they do not. What it gets you is the same team doing different work.

And it does not get you certainty. This is still a field where the tooling changes every few months, and anyone selling you a ninety-day guarantee of a specific outcome is selling something they cannot deliver. The research on why most AI pilots never reach the P&L is worth reading before you sign anything with anyone, including us.

It also does not get you a team that no longer needs training. The systems change what people do, and people need to be shown what they now do, more than once. Budget for that in the months after the ninety days rather than assuming a handover document covers it. A handover document is a reference, not an education.

Why we can describe this so precisely

Because we did it to ourselves first, badly in places, before we sold it to anyone. The week six dip, the automation we killed, the process we discovered did not exist: all of that is ours before it was anyone else’s.

One last thing, because it is the question that should matter more than the schedule. Ninety days of this is invisible to your clients while it is happening, and then it is not. What they register first is operational rather than strategic, and it shows up earlier than anyone expects. We wrote that side of it up separately: what clients actually notice when an agency rewires, from the client’s chair.