Client handover template for B2B SaaS

The client handover with the items a subscription business cannot afford to lose: the lead route and everything in it, the named account lists and how they were built, the agreed definition of an accepted lead, and whatever joins advertising data to pipeline data.

Everything else is the general handover, unchanged. One row per item, named exactly, verified from the receiving side, with ownership distinguished from access.

Use it whenever demand generation changes hands. In this category the ad account is the smallest part of the system, and the parts that matter sit in a sales platform, a form builder and an integration somebody configured years ago.

Start it weeks ahead, because the integrations usually belong to a third team and their availability is the constraint.

In this category the account is the visible part of a system that mostly lives elsewhere.

Between an ad and a conversation there is a landing page, a form, a set of tracking parameters, an integration, a sales platform, assignment rules, a notification, and a definition of what counts. Most of those belong to teams outside marketing, and most of them were configured once by somebody who has since moved on.

A handover that transfers the ad account and the creative has transferred the part that would have been easiest to rebuild. What is hard to rebuild is the route, the lists and the agreements, and those are the rows that need the most care.

The first row is the lead route, and it is one row only because it is easier to read that way — in practice it is a short document.

Write down every step: which form, which page, which parameters, which integration, which object is created, which fields are populated, what assignment rule fires, who is notified, where the record lands. Name the system and the owner at each step.

Then verify from the receiving side by submitting a test lead after the transfer and following it all the way through. A screenshot of the resulting record, showing its owner and its source fields, is the evidence. Anything less is a claim that the configuration looks correct.

Named account lists are frequently the most valuable asset in this kind of account, and they are handed over badly.

A list on its own is a file. What makes it maintainable is the provenance: what the criteria were, where the data came from, when it was last refreshed, who owns the source, and what was deliberately excluded. Without that, a successor either uses it blind until it decays or rebuilds it from scratch, and both are expensive.

Where a list cannot lawfully move, say so in the row with the reason. That is a legitimate outcome and it saves a fortnight of searching.

The accepted-lead definition decides every number the campaigns are judged on, and it is usually an agreement between marketing and sales rather than a setting in a system.

Hand it over in writing, with the date it was agreed and the names of the people who agreed it. Then make sure the receiving side meets whoever holds it on the sales side, because the definition will drift and the relationship is what keeps it honest.

A successor working to a different definition will produce results that look better or worse than their predecessor's for reasons that have nothing to do with their work, and nobody will be able to explain it.

Something connects advertising spend to pipeline, and in most organisations it is one person's query or workbook.

That is the row most likely to be forgotten and most painful to lose. Name it, hand it over, and have the receiving side reproduce a month of reporting with it before the handover is called complete. Reproducing rather than receiving is the test: a workbook that depends on a field only one login can see is not transferred by sending the file.

Write down the parameter conventions alongside it, because the join depends on them.

List every automated rule, every scheduled report and every recurring export.

Rules keep running after a handover, under nobody's authority. Reports keep arriving for people who have left, which is both noise and, occasionally, a disclosure problem. Exports keep writing into places nobody is watching.

Decide explicitly for each: transfer, stop, or rebuild. A decision recorded is what stops the successor discovering them one at a time over six months.

Finally, the notes.

Why a segment was abandoned. Which channel was tried and did not work, and under what conditions. What the last two quarters' allocation was based on. Which tests have been run and what they found. Which parts of the account are the way they are because of a constraint rather than a choice.

In a business with a long cycle this matters more than almost anywhere, because a successor without it will spend two quarters rediscovering things that were settled years ago — and the rediscovery costs a full cycle each time.

In this category several of the most valuable things being handed over are people.

The contact at the sales platform who actually fixes things. The contractor who built the integration. The analyst who maintains the reporting. The sales leader who agreed the lead definition. A platform representative, where one exists.

Each is a row: who they are, what they help with, how they are reached, and what the arrangement is. An introduction made before the handover date is worth more than any document, and it is the item most likely to be skipped because it feels informal rather than operational.

Seven checks. Items are listed by category and named with identifiers. The whole lead route is documented and a test lead has been run end to end after transfer. Every list has its provenance, its refresh date and its owner, or a note saying it cannot move. The accepted-lead definition is in writing with its date and the people who agreed it. The reporting join has been reproduced by the receiving side rather than merely sent. Every rule, report and export has an explicit transfer, stop or rebuild decision. And the notes record what has been tried and what was learned.