A system can pass every demonstration and still fail in week two. The screens worked. Someone clicked through a happy path on a quiet afternoon. Then Monday arrived, a real enquiry landed, the usual person was out on a job, and nobody was sure who owned the next action. That is not a software fault. It is a handover fault. System handover training is the work of making the new path usable by the people who will run it, under load, without the builder sitting next to them.
Go-live fails at handover more often than it fails at code. Training, ownership and support windows matter as much as build quality. Treat those three as an afterthought and the firm quietly reverts to the old inbox, the old spreadsheet and the habit of asking whoever still knows how it works. The new system becomes a parallel track that only the project sponsor still believes in.
Why the build can look finished while the team is not
Most go-lives are signed off by the people who commissioned the work. They sat in the workshops. They know which status means what, and who to ping when something looks wrong. That is not the team. The team is the receptionist, the office manager, the estimator who is already late, and the person covering Friday afternoon. If those people cannot complete a real job without the builder in the room, you have not gone live. You have staged a demonstration.
The gap shows up in ordinary places. Access still sits with the supplier, so a password reset becomes a ticket. The documentation was written for the builder: field names and environment notes a busy operator will not open. Exceptions were never walked through, so the first unusual enquiry sends everyone back to email. The cutover was booked for a Friday because diaries were free, which means the first real week starts with nobody around who built it.
There is also a quieter failure. Staff keep a private workaround because they do not trust the new path yet. They copy the record into the old spreadsheet. They BCC the old shared inbox. Two weeks later you have two sources of truth, and the new system looks empty because the work never entered it. Leadership then concludes the tool was wrong. Often the tool was fine. The handover never made the new path the easy path. The test is whether a named person on the client side can take live work from first contact to a recorded next action, on the agreed screens, without asking the supplier to drive.
What system handover training actually has to cover
System handover training is not a slide deck and a recorded walkthrough sent on the last day. Those artefacts have a place as reference. They do not teach a team how to behave when the phone rings during a half-finished quote. Training has to happen on the live pathway, with the people who will use it, before you switch the old route off.
Cover the job, not the feature list. Start at the door the public actually uses: a web form, a phone call, an email, a booking. Walk one complete piece of work through intake, ownership, doing the work, and close. Then walk the ugly version: a duplicate, a complaint, a change of date, a no-show, a record that arrived with half the fields empty. If the training only shows the happy path, the first exception will be handled in a chat thread and never reach the system of record.
Train the operators, not only the sponsor. A walkthrough with the director who bought the work proves the screens exist. It does not prove the Friday cover can file an enquiry, assign it, and tell the caller what happens next. Sit with the people who will touch the pathway every day, on the screens they already open. Let them drive. Watch where they hesitate. Those pauses are the real syllabus. Name the statuses in the language the team already uses. If closed means invoiced to one person and paid to another, settle that in the room and write it down.
Leave them with a short operating note, not a novel. Who owns a new enquiry. What in progress is allowed to mean. Where to put an exception. Who can change an automation or a form. How to tell a fault from a training gap. The note should be usable on a phone, in the middle of a busy morning. If it needs a table of contents, it will not be opened.
Named ownership is the handover, not a shared login
A shared login feels like collaboration. It is how ownership dies. When everyone can see the queue, nobody is late. When the supplier still holds the admin account for convenience, the client does not actually run the system. Handover means the accounts, the domain, the repository and the third-party licences sit in the client’s name, with named people who can log in without ringing the builder.
Split ownership in two. One person owns the pathway: the way work is supposed to move, the meaning of each status, the rule for exceptions. Another person owns the tools: who can edit the form, the automation, the mailbox routing, the access list. In a small firm those can be the same human. They still need to be named, with a deputy who can cover leave. A cover page that says the office is not an owner.
Write decisions down as you make them, including the options you rejected. Handover is when that record becomes the team’s, not the supplier’s private memory. If you changed a routing rule because Friday afternoons were drowning the wrong person, that reason has to survive the project. Otherwise the next keen starter tidies it back to the version that looked logical on a whiteboard.
Access is part of training. Walk the named owner through password resets, user invites, and how to revoke access when someone leaves. The person who processes enquiries does not need the ability to delete the automation. The person who reports on the week does not need to edit the public form. Handover that skips access control leaves a system that only the original builder can safely touch.
A support window is part of the product
Training without a support window is how teams get stranded on day four. The first week of live use produces questions that no workshop predicted. A field that seemed obvious in the demonstration turns out to be ambiguous. A supplier portal times out. Two staff interpret the same status differently. That is normal. What is not normal is a supplier who disappears the morning after cutover, or a support arrangement that is actually a new sales conversation.
Agree the window before go-live. How long the builder stays close. How a fault is logged. What counts as a defect in the agreed scope, and what is a new request. Who is reachable, by what channel, during which hours. A named person beats a rotating queue. Releases during the window should still be controlled, at times the client agrees, never unannounced on a Friday.
Watch real work, not dashboards alone. Sit with the first few live jobs. Note where people hesitate, jump back to the old spreadsheet, or ask a colleague instead of using the screen. Fix the path if the path is wrong. Retrain if the path is right and the habit has not caught up. Then end the window in writing: what remains in place, how to request further work, and what is now the client’s to run. A bounded window is how a team learns they can operate without the builder in the chair.
- Train on complete jobs and exceptions, with operators driving, before you switch the old route off.
- Name one pathway owner, one tool owner, and a deputy for both.
- Put accounts, domains and admin access in the client’s name before cutover, not after.
- Write a one-page operating note: statuses, exceptions, who to call, how to log a fault.
- Agree a support window with hours, a named contact, and a clear line between defects and new work.
- Watch the first live jobs and fix hesitation in the path or the training, not with a private workaround.
- Keep a tested way back until the new path is the one the team actually uses.
- Retire the old inbox or spreadsheet on a date, or it will remain the real system.
Lightning Business Solutions hands work over as part of delivery, not as a courtesy at the end. Scope, staged build, named ownership, documentation and a support arrangement are how a UK organisation ends up running the system it paid for. If a recent go-live is already leaking back into email, start with training, ownership and the support window, not with another feature.
Talk through the pathways that matter on our contact page, or see how the pieces fit under capabilities.