The flow may be running, but if the team has not taken it over the work still sits on one person. In this lesson you fill in the handover list: roles, permissions, first week support, the single door for problems and putting the rules kept in the head into writing.
The lessons up to here built the system: the task was picked, the process written, the data defined, the tool chosen, the flow built, the systems connected and the exceptions decided. This lesson takes on the people who will use the system.
The distinction is this: the flow may be running, but if the team has not taken it over, the work still sits on one person. When that person goes on leave the automation keeps running while the decisions at its edge stop. Handover is the sharing of those decisions too.
Prerequisites: a running flow and the exception log from the seventh lesson. Without the log, half of the decisions to be handed over are not written down.
Automation does not take the work away, it changes its shape. Repeating steps move to the system side; decisions, exceptions and talking with the customer stay on the human side.
When this change is not written down, the team tries to do two things at once: it keeps running the old manual work and also watches the new system. The load does not drop, it doubles. The handover list exists precisely to get ahead of that.
Triggering, creating records, moving data, reminders. The work whose steps are written down and which runs on rules.
Decisions, exceptions, talking with the customer and eyeballing what the system produced. These do not shrink, they become visible.
Going through the pending list, looking at alerts, filling in the log. This work needs an owner too, otherwise nobody does it.
The list sits on a single page and each row describes one person or role. The four columns correspond to the four questions asked at handover; when one column stays empty, that person has been handed the system halfway.
Filling the list in before the handover is different from filling it in after. Filled in first, missing permissions and ownerless work come out on paper; filled in later, they get discovered one by one during the first week.
The fourth column is what makes the list work. Left empty, everyone asks a different person and the same question gets answered several times.
Handover is written by role rather than by name, because people change while roles stay. For each role the screens that role actually touches are listed; a screen it does not touch stays off the list.
This distinction also changes the training: instead of showing everything to everyone, each role is shown its own screen. A screen that was not shown goes to the door anyway when it later causes trouble.
Once the list is complete, every screen of the system has an owner. A screen with no owner becomes the screen nobody looks at by the end of the first month.
Permission causes trouble in both directions. Granted narrowly, the work stops and everyone goes to the same person; granted widely, a change made by accident cannot be taken back.
The criterion is this: what does this role have to see and what does it have to change in order to run its work? Where seeing is enough, the permission to change is not granted. The access row from the sixth lesson comes down to the person level here.
Being able to open the record and the list. For most roles it is enough to run the work and it produces no result that cannot be taken back.
Opening records, updating them, going through pending. Once who may change which field is written, the argument ends.
Stopping the flow, changing a rule, opening a new user. A permission kept narrow and written by name.
Handover does not end with a meeting. The first week is the week the system runs together with the team, and that week somebody needs to stand by.
Standing by does not mean doing the work for them; it means answering when asked and, when not asked, going over the first days by eye. Once the name of the person standing by is written, the team does not hesitate to ask.
The questions asked become the input of the exception log. If the same question came three times, what is missing is not the person but the unwritten rule.
This is the most often skipped row of a handover. When the team meets a problem, do they go to the person who built the system, to the manager, or to the provider? Left unwritten, everyone knocks on a different door and the same problem gets told several times.
A single door does not mean piling problems on one person. The door is where the incoming problem gets classified and passed to the right place: is it a usage question, an exception, or a real fault.
The "where did I do this from" kind. It goes to the person supporting in the first week and the answer gets added to the training note.
A situation the rule does not cover. It goes to the owner of the log, a decision is made and a row is opened.
The system works wrongly despite what is written. It gets narrowed with the diagnosis checklist, then goes to the building side.
The shortest way to explain the system to the team is to show it on their own records and then have them do it. Explanation on its own gets forgotten at the first real record.
The record used during the showing should be real but its result should be reversible. A test record is one recognisable by its name and cleaned up afterwards.
The output of the showing is not a document but the second record the person completed alone. The document earns its keep next to that record.
Resistance is mostly not against the technology but against uncertainty. Under the sentences "will it take my job", "what happens if I make a mistake", "the old way was faster" sit three unanswered questions.
A handover made without talking these through can end with the system left unused on the side. The system existing does not mean the system is used.
Once it is written which steps the automation took over and which work stays with people, the worry turns into a concrete list.
It shrinks once the rollback path is shown. Someone who knows how a wrong record gets fixed does not hold back from using the system.
If the old way is still open, the new way does not get used. Where the manual fallback is kept open on purpose, the case for using it is written.
Every team has rules that are not in the system: which customer gets called back first, which request gets held, in which case the phone is picked up. These usually sit in one person's head.
Handover is the best moment to make that knowledge visible, because in the first week the questions come by themselves. Writing the answer down comes cheaper than answering the same question a second time.
Once this step is complete, the handover covers not only the screens but the decisions. That is the real handover.
The same handover test done for the process map in the second lesson is done here for the system. The criterion is the same: does what was written run without the person who wrote it?
For the test, the person who built the system steps aside for a day and the team runs the work on its own. The questions asked and the places they get stuck are the output of the test.
Passing the test once does not count the handover as complete; getting the same result a second time does. The first time there is a share of luck.
The office picked a pilot task, wrote its process, defined its data, chose its tool, built the flow, connected the systems and opened the exception log. Until now one person used the system: the office coordinator.
At handover two roles get defined: the office coordinator and the field advisers. Because the screens and permissions of the two roles differ, the list opens as two rows.
The office coordinator row: uses the request list, the pending list and the exception log screens. The permission is written as opening records, updating them and going through pending; the permission to stop the flow is not granted. The first week support is the person who built the system, with the office manager as cover.
The field adviser row: sees only their own requests and writes the appointment result. Seeing permission is wide, changing permission is limited to a single field. Because this distinction is written from day one, the argument about "touching someone else's request by accident" does not open at all.
The first week arrangement is set up like this: every morning the pending list is gone through, in the afternoon the alerts get checked and the questions go into a note. Over the week twelve questions come in; nine are classified as usage questions, two as exceptions and one as a real fault.
Three repeating questions get worked into the process map as rules: "what happens when the phone is empty", "which record a second message from the same person goes to" and "where the record waits when an appointment is cancelled". All three were rules kept in the head; the handover puts them in writing.
In the handover test in the second week the office completes the day without asking the builder. The only step they get stuck on is the report screen, and the note list for that step gets written the same day.
This week open the handover list and write a row for every role that will use the system. You do not have to wait for a new build; handing over a flow that already runs uses the same list.
Download the handover checklist (xlsx) · a one page list with the columns who uses what, which permission, who supports in the first week and where to go when something breaks; the demonstration, the first week questions and the handover test are in it too.
The ones below come not from the system but from the handover being left incomplete. What they share is this: none of them shows up in the system as a failure.
A presentation gets made and the handover counts as done. At the first real record the questions start but nobody is standing by.
Wide permission gets granted to everyone for convenience. Who made the accidental change cannot be found either.
The old manual way is not closed and no rule is written. On a hard day the team goes back to it and the system stays half used.
The same question gets asked to three people three times. The answer is produced afresh each time and sometimes comes out different.
New work such as going through the pending list or looking at alerts is written to nobody. After a while nobody does it.
Only one person can use the system. When that person goes on leave the decisions stop, and the work does not move even though the automation runs.
If every item on this list can be answered once the handover week is over, the handover counts as in place.
Terms that come up in handover conversations. Calling the role and the permission by the same name keeps the list readable in the second month too.
In this lesson you handed the system over to people: you wrote down roles and permissions, set up the first week routine, named the single door and put the rules that lived in one head into writing. The lesson ahead takes on measuring the result and growing what was built.
If you would like to carry on from the published lessons, the module that handles the exceptions at the edge of the flow with a log is next.
The exception log, the alerting path and the measurement that makes silent faults visible.
The process map and the handover test. The handover test here is that test applied to the system.
The whole training section and the modules added since.
If you would like to fill in the handover list together, write to us and we will draw up the roles.
Get a Quote on WhatsApp