Software demonstrations are designed to go well. The presenter knows the path, the data is clean, and every click lands where it should. Then the system goes live, a site engineer opens it on a phone in the field, and the first real file hits a permission nobody thought to check.
Sign-off deserves better than applause at the end of a demo. Before a system runs your hiring or your approvals, every role that will touch it should have worked through it — in its own account, on its own permissions, against a script that covers the awkward paths as well as the happy one.
That is how we run acceptance on every build. It is slower than a demo — and it is the cheapest insurance a go-live can buy, because by the time the system is live, your team has already run it.
What a demo cannot show you
A demo usually runs on one account — an administrator's, which is precisely the account nobody will use in daily work. Admin accounts see everything and are allowed everything, so a demo is structurally incapable of revealing permission problems: the approver who cannot open the attachment she must rule on, the coordinator who can edit a field he should only read, the manager whose dashboard quietly includes another department's data.
A demo also walks the happy path — the requisition that gets approved, the candidate who accepts. Real operations are made largely of the other paths: rejections that need recorded reasons, resubmissions after changes, files that must escalate when they sit too long. None of that appears in an hour of presentation, and all of it appears in the first week of live running.
And a demo happens on the presenter's machine, on good bandwidth, on a large screen. Your site engineers will live in the system on phones, in the field. If field roles are tested only from a desk in head office, the gap surfaces at the worst possible time — after go-live, in front of the people you most need to convince.
One account per role, one script per role
So our sign-off is structured around roles. Every role the system serves — approver, HR, site engineer, management — gets its own test account, carrying exactly the permissions that role will hold in production. No shared logins, no admin shortcuts. If a role cannot do something in testing, it will not be able to do it live — and surfacing that is precisely what sign-off exists for.
Each role then receives a structured test script: the sequence of actions that role actually performs, written step by step, with the expected result of each step stated in advance. The approver's script has them approving, rejecting and returning files. HR's script moves a candidate through the stages. Management's script checks that the dashboard says what the underlying records say.
The scripts are deliberately unglamorous, and that is the point. Sign-off is not about being impressed; it is about confirming that the ordinary work of every role behaves correctly under that role's own permissions, before anything real depends on it.
Rehearse the paths you hope never to use
Good scripts spend as much time on the unhappy paths as the happy ones. When an approver rejects, does the requester see the reason? When a file sits unattended, does the reminder fire — and reach the right person? When someone attempts an action outside their permissions, are they stopped cleanly, with a message that makes sense?
These are the paths where systems fail in production, precisely because they are the paths nobody rehearsed. Working through them in testing costs days. Discovering them live costs the one thing a new system cannot afford to lose — the team's trust. A team that hits three broken paths in its first week stops using the system in its second, and then you are back to spreadsheets with a licence bill.
There is a quieter benefit too: the scripts force the rules to be stated. Deciding what the reminder should do when a file waits, or who may override a rejection, is process design — and it is far better done around a test table than argued out live, with a real file stuck in the middle.
It is slower than a demo and far faster than a failed go-live.
Approval means you approve everything
Run this way, sign-off stops being a signature on a delivery note and becomes a record: every role has run its script in its own account and accepted the result. Where a script fails, we fix the build and that role runs it again. Nothing goes live on our assurance — you approve everything before go-live, module by module.
This changes the team's relationship with the system before day one. The people who will use it are not meeting it for the first time; they have rehearsed their own job inside it and said yes to what they saw. Kickoff training then lands on prepared ground, confirming what hands already know instead of introducing something foreign.
Module by module matters, too. A system that runs hiring end to end — requisition, screening, offers, joining — is really several processes chained together, and each deserves its own acceptance rather than one sweeping yes for the lot. Approving in modules keeps every question small enough to answer honestly.
It also settles arguments before they start. When the record shows the approver herself accepted the approval flow in testing, the conversation after go-live is about improvements, not blame.
The best go-live is an anticlimax
By launch day there should be nothing left to discover. The approver has already cleared test files under her own login, the site engineer has already raised requests from his phone, and management has already read the dashboard and checked it against reality. Going live simply means the data is real now.
This is one part of how we hand over every product — alongside SOPs and decision flowcharts for every module, and kickoff training — because a system is only finished when your team runs it confidently without us, and keeps running it long after go-live.
A demo asks your team to believe. Role-wise testing lets them verify. For software that will carry your approvals, your hiring and your projects, verification is the only sensible basis for saying yes.