How a handover actually runs, from the first list to the day you own it

Onboarding has a reputation for being the slow part, and it usually is, but not for the reason people assume. The build is rarely the bottleneck. The bottleneck is a handful of decisions that only you can make, sitting unanswered while everything downstream of them waits.

So here is the whole shape of it, honestly, including the parts where the ball is in your court.

It starts with a short, boring list

The first thing you get is not a project plan. It is a list of between six and ten items, each of which blocks something specific. Every item on it exists because a build stalls without it, and the list is deliberately short so that it is possible to finish in one sitting rather than impressive to look at.

A typical list asks for the domain and who controls its DNS, an export from whatever you are leaving, the names and roles of everyone who needs access, your real working hours and holidays, how a deal actually moves through your business, and the date you need to be live by.

The last one matters more than it looks. A real date changes the order things get built in. Without one, everything is built in the order that makes sense to a builder, which is not the order that makes sense to someone who has an event on the eighteenth.

Why each request exists

The two items people push back on are the data export and the question about how you sell. Both are worth explaining.

The export is asked for early, even if the migration is scheduled for later, because exports are where the surprises live. Contacts with no email address, four different spellings of the same company, a custom field that was used for three unrelated purposes over two years. Finding that in week one means it can be cleaned while other work continues. Finding it the night before go-live means moving the date.

The question about how you sell decides what your pipeline looks like. If we guess, you get the default: a tidy set of stages that matches nobody. If you describe your real process, including the ugly bit where things sit for three weeks waiting on a survey, you get stages that match what your team actually does, and they will use it. A pipeline people work around is worse than no pipeline, because now the truth lives in somebody’s notebook and the system quietly lies to you.

The build happens without you watching it

Once the list is answered, most of the work is invisible and that is intentional. Accounts get created, the snapshot or template is loaded, calendars are set up with your genuine availability rather than a placeholder, automations are built, and the phone and email channels are registered and verified.

That verification step is the one worth knowing about, because it involves waiting on third parties. Sending domains need DNS records to propagate. SMS sender registration is reviewed by carriers on their own schedule, not ours, and it can take days. If a launch date is tight, these are started first even though they look like details, because they are the only parts nobody can accelerate.

While that is happening you will get short status notes rather than silence. Every one of them ends with either what is happening next or what is needed from you, so you always know whose turn it is. If a note says the desk is waiting on something from you, that is the thing holding the date.

Everything gets tested as a customer, not as an admin

Before anything is shown to you, the flow gets walked as an outsider. A booking made from a phone, on a real calendar, producing a real confirmation email that arrives in a real inbox. A form submitted from a browser that has never logged in. An automation triggered by something a customer could plausibly do at eleven at night.

This catches the category of fault that looks fine from the inside: the calendar in the wrong timezone, the notification that only sends to the person who built it, the automation that works for the admin account and silently skips everyone else. Testing as an admin proves the thing exists. Testing as a customer proves it works.

The walkthrough is recorded for the person who joins in March

Handover includes a recorded walkthrough of your actual setup, with your data in it, not a generic product tour. It gets recorded because the person who most needs it has not been hired yet.

Watch it once during handover with the specific goal of interrupting. The questions you ask in that session are the ones your team will ask later, and answering them while somebody is still in the detail is much cheaper than answering them in an email six weeks afterwards.

Sign-off is a checklist, not a feeling

Sign-off should never be somebody asking whether you are happy. It should be a short list of statements you can each check yourself:

• Every person who needs access can log in, on their own device, and sees what they should see.
• A test booking, form submission and payment path each complete end to end.
• Notifications reach the right people, including out of hours.
• The data that came across matches the counts from the old system, and any difference is explained in writing.
• You know how to make the three changes you will most often want to make.

If any line is not true, it is not done, and saying so at that point costs nothing.

After the handover, nothing goes quiet

The first month is when small things surface: a permission that is slightly too narrow, a field everyone wants renamed, one automation that fires at an annoying hour. These are expected, and they are support rather than new work, so raise them.

The line between the two is simple enough. If something that used to work has stopped, or something already agreed has not been delivered, that is support. If you want something new built or changed, the desk will scope it and come back with what it involves before anyone writes anything, so there are no surprises on either side.

One address either way: your email becomes a tracked request as it arrives, and a person reads it.