Most automation projects have a detailed plan right up to launch day, and then the plan simply stops. There's a go-live meeting, a round of thanks, and an unspoken assumption that the thing will now run forever the way it did on Tuesday afternoon.
It won't. Not because it was built badly, but because the business it runs inside keeps moving. Vendors change their invoice formats. A new hire does the upstream step a little differently. Volume doubles in the busy season. A software update renames a field. Every one of those is small, and every one of them can quietly erode what the automation was supposed to deliver.
Launch day isn't the finish line. It's the midpoint. The next ninety days decide whether the project earns its return or joins the pile of tools nobody quite trusts.
Days one through thirty: watch everything
The first month is for observation, not optimization.
Run in the open. For the first couple of weeks, the automation's output should be easy to see and easy to check. Many teams run it alongside the old process for a short overlap so they can compare. That overlap should have an end date — otherwise it becomes permanent double work.
Read every exception. The exception queue is the best diagnostic you have. In week one it tells you what the build missed. By week four it should be telling you something much less interesting.
Talk to the people using it. Not a survey. A fifteen-minute conversation with the person who used to do the job by hand. They'll tell you what's annoying, what's wrong, and what they've started working around — usually in that order.
Days thirty through sixty: tune
By the second month the patterns are clear, and the work shifts to fixing them.
Turn repeated corrections into rules. If a person has fixed the same kind of exception several times, write the rule so they never fix it again.
Tighten the thresholds. Early on, the system should be cautious and flag anything it's unsure about. As trust builds, some of those flags can become automatic — deliberately, one category at a time, with the supervisor's agreement.
Retire the overlap. Once the output has held up for long enough that checking it feels pointless, stop checking everything. Keep spot checks. Drop the parallel process. This is the step where the reclaimed hours actually become reclaimed, and it's the step most often skipped.
Days sixty through ninety: measure against the number
Every project we build starts with a number — what the problem costs per year, calculated before anyone writes a line of code. That's the method in Do the 2x Math Yourself, and it's the basis of the guarantee.
The third month is when you check the automation against that number, honestly.
Are the hours actually gone? Not "the task is faster" — are the people who used to do it now spending that time on something else? If the time just evaporated into more email, the project hasn't paid yet.
Is the volume what we assumed? If it's higher, the return is probably better than projected. If it's lower, you want to know now.
What are the exceptions costing? Resolution time multiplied by volume. It should be falling.
What broke, and how fast was it fixed? Something will break. The question is whether anybody noticed within hours or within weeks.
Write the answers down. That's your first real return figure, and it's the one that tells you whether the next project is worth doing.
Who owns it after launch
The most important post-launch decision is simple and often never made: whose job is this system now?
Every automation needs a named owner inside the business — the person who watches the exception queue, notices when volume shifts, and calls someone when it breaks. It doesn't need to be technical. It needs to be someone who cares whether the work gets done.
It also needs a technical owner — someone who can actually fix it when a vendor changes a format or an API moves. For some businesses that's an internal developer. For many it's the partner who built it. For companies running several systems with no technical leader on staff, it can be a fractional CTO who owns the whole stack part-time. What it can't be is nobody. Systems without an owner are the ones that quietly stop working, and the organization usually finds out months later from a customer.
Why this matters for the guarantee
We guarantee a minimum 2× return on what a client spends with us. A guarantee like that only works if the ninety days after launch get the same attention as the build. Handing over a system and walking away would make the guarantee a gamble. Watching it, tuning it, and measuring it against the number is what makes it a commitment — the reasoning behind why we guarantee 2x in the first place.
Where to start
If you already have automations running, ask three questions about each one: who owns it, when did someone last read its exceptions, and what is it actually saving compared to what it was supposed to save? If any answer is "I'm not sure," that's your first project — and it's usually a cheap one.
If you're considering your first automation, the AI Automation Scorecard will help you find the right candidate and set the number you'll measure it against.
Go-live is a good day. It's just not the last day that matters.