Six months after
the build.

Week one: excitement and checking.

The first week after a build goes live is always the same. The owner is excited. The team is cautious. Everyone is checking the outputs more than they will need to in three months.

This is correct behaviour. A new automation has not yet been tested against every real-world case. Checking is what trains it. The owner corrects the drafts that do not sound right. The team flags the summaries that missed something. Each correction is information that makes the next output better.

The checking period is also the period when people decide whether the automation is going to be useful. Teams that experience a few good outputs early develop confidence quickly. Teams where the first outputs are poor will take longer to trust the system, even after it has been corrected.

Month one: the real workload picture.

By the end of the first month, the checking has reduced. The team has a sense of what the system does well and what it does not. They have developed habits around it — when to use it, when to override it, which outputs to send directly and which to edit.

Something else happens in the first month that surprises most owners: they realise the task they automated was connected to other tasks in ways they had not mapped. Automating the intake form reveals that the follow-up process is also slow. Automating the document review reveals that the filing system is the next problem.

This is not a failure of the first build. It is the normal effect of making one bottleneck visible by removing the one in front of it. The second build, when it comes, is always more accurately scoped than the first because of what the first one showed.

Month three: the team has changed.

Three months in, the automation is no longer new. It is just part of how the business works. New staff are trained on it as part of their induction. Nobody talks about it much. It runs.

The team has also shifted. Not in structure, but in where they spend their attention. The hours that were going into first-pass document reading, or manual quote drafting, or chasing clients who had not responded — those hours are going somewhere else.

What they go into varies by person and by team. Some of it goes into higher-value work: deeper client relationships, more complex cases, more thorough preparation. Some of it goes into taking a lunch break that was previously eaten at a desk. Both are outcomes worth noting.

Sara · Lead lawyer, three-person firm — three months after the build, she took a Friday afternoon off for the first time in two years. Not because she ran out of work. Because the work that was left was the work that actually needed her, and it was done.

Month six: the number that surprises people.

The outcome most owners expect from an automation is time saved. They measure it. They are usually right — the hours saved are real and often exceed the initial estimate.

The outcome they do not expect is revenue. Not from a new product or service. From the same services, delivered faster and with fewer delays. Response times to new enquiries went from three days to four hours. Quotes went out the same day instead of the following week. Client onboarding, which used to take two weeks of back-and-forth, took four days.

Faster delivery of the same service produces measurably better conversion. The firm is not doing anything differently in terms of what it offers. It is doing it in a timeframe that keeps more clients in the room. That is a revenue effect without a cost increase.

Most business owners, when they commission an automation, are thinking about costs. Fewer hours, lower administrative burden, fewer mistakes. The revenue effect is usually the larger number, and it usually takes six months to become visible.

What does not work out.

Not everything goes well. The six-month picture is honest about this too.

• Automations nobody uses. If the process being automated was not actually the bottleneck, the adoption rate will be low. The system runs. Nobody opens it. This is a scoping problem, not a technology problem. The fix is to find the real bottleneck and build for that instead.
• Outputs that were never quite right. If the outputs needed heavy editing in week one and still need heavy editing at month three, something in the training is wrong. This is fixable, but it requires going back to the builder rather than assuming the problem will resolve itself.
• Team members who opted out. Some people will not use the automation regardless of how good it is. This is more common in teams where the automation was introduced without explanation of what it is for. The fix is almost always communicative, not technical.