Before the Audit: Pick One Workflow

Choose one piece of work that repeats often and annoys people. Write it down as it really happens today, including the shortcuts and exceptions, and note roughly how often it happens and how long it takes. Bring the person who actually does the work, as well as their manager. Bring a few real examples too: messages, forms, statements or call notes, with personal details blanked out if you like.

During the Audit

The audit goes through the workflow step by step. What starts it? Where does the information come from, and which systems does it pass through? Who decides what? Where does it wait, and where does it go wrong? The aim is an honest picture, including the parts that should stay manual. Sometimes the answer is a simpler process with no automation at all. That's a useful result too.

Reading the Requirements Summary

Before anything is built you receive a plain-language summary to sign off. Read it as a promise. It says what the system will do, what it won't do, what it hands to a person, and how you'll know it's working. If a sentence is unclear, ask for it to be rewritten. Anything missing from the summary should be assumed not to be included.

  • What triggers the workflow and what it produces
  • Which actions need a person's approval
  • Which systems it connects to, and with what access
  • What happens when something goes wrong
  • How success will be measured in the first weeks

Preparing Your Infrastructure

The system runs on an account in your name. You open it, you pay for it, and you create limited accounts for the people who build and support it. Keep a list of those accounts and what each can do, so access can be reviewed or withdrawn at any time. A pre-flight check of the account happens before anything is deployed, so problems surface early.

During Rollout

Rollout starts small: one team, one branch, one type of request, or the new system running alongside the old process. Watch the results and the list of cases handed to people. Expect some adjusting in the first weeks. That's the rollout doing its job. Widen the rollout only when the results are steady.

At Handover

Handover is the point where you can run, change or move the system without depending on its builder. Check three things: you can find the documentation, you know how to switch the system off and go back to doing it by hand, and every account and login is in your name.

After Go-live

Decide who in your business owns the system: who reads its reports, who approves its actions, who updates the information it works from. Review it monthly for the first few months. Most improvements come from what the first real weeks reveal.

What You See Along the Way

Before the build: A plain-language summary of what the system will do, what it will not do and what stays with a person. Nothing is built until it has been read and signed off. Any later change to the scope is written down the same way.

During rollout: Each stage is described before it starts, together with its rollback plan. You can see what is changing, when, and how it would be reversed. Progress is measured against the requirements you signed off.

Every month: A log of our access to your systems, and with the managed service, a monthly report. The log shows which systems were accessed and when. The report covers how the system performed, any incidents and any changes made.

At handover: The architecture, runbooks, recovery steps and credential transfer plan. Together they let your own team, or another supplier, run and recover the system without depending on the original builder. Credentials move to your control in a planned, documented way.