Handing a CRM programme back to an in-house team

The handovers that go badly are rarely the ones where something is broken. They are the ones where everything works. Every journey is live, every dashboard is green, and six weeks later nobody in the building can say why the win-back programme waits ninety days rather than sixty.

The assets transfer fine. Logins, templates, segment definitions and documentation all move in an afternoon. What does not move is the reasoning, and a programme whose reasoning has been lost degrades quietly. Nobody notices for a quarter, because the campaigns keep sending.

We think an engagement should be designed to end well from the day it starts, and the test of whether it did is not whether the new team can keep the programme running. It is whether they can change it.

Design the exit before you design the first sprint

The right time to agree how an engagement ends is the week it begins. By the time somebody raises it in month eighteen, a set of dependencies has formed that nobody chose.

Three things should be settled at the start, in writing:

• Which capabilities are being built in-house and which are being bought for the duration. A team that never intends to run deliverability itself needs a different plan from one that does.
• Who on the client side shadows each workstream, by name, with time protected for it. A shadow with no allocated hours is a name on a slide.
• What the handover artefacts are, and where they live. In the client's own systems from day one, not in an agency drive to be exported later.

That third point sounds administrative and is the one that decides the rest. Documentation written in the client's environment gets read and corrected as the work happens. Documentation exported at the end is written once, by someone in a hurry, and read by nobody.

The same discipline applies in the other direction when an engagement starts, and we set out what a good brief contains in briefing an agency. A brief that names the intended end state produces a much easier handover than one that does not.

Transfer the decisions, not just the assets

Every mature programme is a pile of decisions that look arbitrary from outside. The sunset window is one hundred and eighty days. The basket journey carries no discount. Two segments are excluded from the weekly newsletter. Push goes before email on one journey and after it on another.

Each of those had a reason, usually a test result, a complaint spike, a legal review or a commercial argument. Without the reasons, the new team faces an unpleasant choice. Preserve everything, which freezes the programme, or change things and rediscover the original problems.

So the central handover artefact is a decision log. One line per decision, with the date, the person, the reason and the evidence. It does not need to be elegant. It needs to be complete enough that an incoming manager can tell a deliberate choice from an accident.

We write it continuously rather than at the end, because a decision log assembled retrospectively is a reconstruction. Two of the entries will be wrong, and they will be the two that matter.

The list of things that actually have to move

Beyond the decision log, the handover has a fixed inventory. Working through it takes longer than people budget, and skipping items is how the first quarter goes wrong.

1. Access and ownership. Every platform, with named owners and a billing contact. Every integration's credentials, with their rotation schedule. Any account still registered to an agency email address is a future outage.
2. Sending domains and DNS. Which records exist, who may change them, and how a change is requested. Deliverability fails slowly and silently when this is unclear, and it is the single most common gap we find after a transition.
3. Data models and contracts. The models behind the single customer view, their tests, and the data contract with each upstream system. What the field means, who produces it, how often, and what happens when it is late.
4. Naming and segment conventions. How campaigns, segments and journeys are named, and why. This is the convention that decays fastest after a handover, and reporting decays with it.
5. The message inventory. Every broadcast, trigger and transactional template, with its owner, trigger, audience and last review date. Including the ones marketing does not own.
6. Consent and preference handling. How the preference centre writes back, where consent is stored, and what the timestamp and source look like for each channel.
7. Measurement definitions. What each headline metric counts, in words a finance colleague can check. Where holdouts sit and how they are maintained.
8. Incident runbooks. What to do when a sync fails, a send goes to the wrong segment, a complaint rate spikes, or a template renders wrongly. Each with the first three steps and who to call.
9. The roadmap and its funding case. Not just what is next, but the argument that got it funded, which is the part that has to be repeated next year. We covered how to build that argument in a roadmap finance will fund.

Read that list as a checklist to complete before the last month, not during it.

Run it in parallel, in both directions

A handover that consists of documents and a workshop is a hope rather than a plan. The transfer has to be rehearsed while there is still someone to catch the mistakes.

We run two phases. In the first, the agency continues to ship and the in-house team reviews everything before it goes out. That surfaces the tacit rules nobody wrote down, because the reviewer asks why.

In the second, the roles reverse. The in-house team builds, schedules and sends, and the agency reviews. This phase is the one that matters, and it needs to run long enough to include a full cycle of the programme's real work. A month of business as usual, at least one peak or campaign moment, one incident, and one reporting cycle.

If the second phase produces no questions at all, something is wrong. Either the team is not really doing the work, or they are not yet confident enough to say what they do not understand.

What tends to break in the first ninety days

Some failures are predictable enough to plan for directly.

Deliverability drifts, because nobody inherited the weekly check. A key person leaves within the first two quarters and takes the undocumented query with them. A vendor renewal arrives with nobody who remembers what was negotiated. A scheduled job fails and the alert goes to a mailbox that was deactivated with the agency's accounts.

The counter to all four is the same. Name the recurring obligations explicitly, with owners and a frequency, and put them in the same calendar the team already uses. Weekly deliverability review, monthly message inventory check, quarterly consent audit, annual vendor review.

Then agree a light support arrangement for the first quarter. Not a retainer that recreates the dependency, but a defined number of hours for questions, with the expectation that the number falls each month. If it does not fall, the handover has not finished.

The honest measure comes a little later. Six months on, has the team shipped something you would not have built. If they have, the capability transferred. If the programme looks exactly as you left it, what transferred was only the operating manual.