Go-live is the start of the automation's working life, not the end of the project. The bot that passed UAT on a quiet Tuesday now has to survive month-end, a system patch, a change in the input file and a Monday when the volume doubles. The first ninety days decide whether it becomes a dependable part of operations or an intermittent source of tickets. This is the runbook we follow.
Days 1 to 14: hypercare.
Hypercare means the build team is still on the case, watching every run. The aim is to find the gap between what the design assumed and what production does.
- Review every run, not just the failures. Look at timings, item counts and the exceptions that were handled silently.
- Hold a short daily call with the process owner. Ten minutes: what ran, what did not, what surprised us.
- Keep a hypercare log of every defect and every deviation, with a decision for each: fix now, fix in the first release, or accept.
- Do not tune in production on instinct. Change thresholds and rules through the same release process used for the build, even if it is faster to edit the config directly.
- Define the first-release scope by day 10, so the fixes ship as one tested change rather than a series of hot patches.
Days 15 to 45: stabilise and instrument.
Once the obvious defects are out, the work shifts to making the automation observable. A bot that fails quietly is worse than one that was never built, because people stop doing the work manually and nobody notices the gap.
Monitoring that someone will act on.
- Heartbeat: did the scheduled run start, and did it finish within its window?
- Throughput: items processed per run against the expected range. A sudden drop usually means an upstream problem, not a bot problem.
- Exception rate by type: business exceptions and system exceptions tracked separately, with a threshold that triggers a review.
- Queue age: the oldest unprocessed item. This catches the slow build-up that daily counts hide.
- Licence and machine utilisation, so capacity is planned before it runs out.
Every alert needs a named recipient and a documented response. An alert that goes to a shared mailbox is not an alert.
Agree the SLAs.
Now that there is data, set service levels the operations team can hold the automation to: run completion time, maximum queue age, exception turnaround, and incident response times by severity. Write them down with the process owner. Vague expectations become disputes in month six.
Days 46 to 90: hand over and improve.
The handover package.
The build team leaves. What they leave behind decides whether the next person can support the bot. The minimum package:
- Solution design document, updated to reflect what was actually built, including the hypercare changes.
- Runbook: how to start, stop, rerun and recover, with screenshots where the steps are in a console.
- Exception catalogue: every known exception, its cause, its handling and who owns the fix.
- Credential and access inventory: which accounts the bot uses, who owns them, when they expire.
- Dependency list: the systems, files, schedules and people the bot relies on, and the contact for each.
- A named owner on the operations side who has run the bot, with the build team watching, at least twice.
The first improvement cycle.
By day sixty there is enough exception data to see the top three root causes. Fix them at source. A supplier template added to the model, a validation rule relaxed with the process owner's agreement, a master-data record corrected. Each fix should move the straight-through rate visibly. Report the before and after to the sponsor. This is the point at which the automation starts paying for its own upkeep.
The day-90 review.
Close the period with a short written review for the sponsor: volumes processed, hours released against the business case, straight-through rate trend, incidents by severity, and the improvement backlog. Then decide the support model going forward: in-house, a managed service, or a mix. Whatever the answer, the bot now has a history, an owner and a measure of its own health. That is what production-grade means.
An automation is finished when someone other than the person who built it can keep it running.