Continuity by Design: A Handover Protocol for UK MedComms Account Transfers

In UK medical communications, an account can change hands for reasons that are planned and reasons that are not: a handler moves to a new agency, takes parental leave, steps into a leadership role, or returns from annual leave to find the portfolio redistributed. The file may be complete. The client relationship may still be intact. Yet the thread can snap in the small gap between what is recorded and what is understood. A handover hour, properly prepared, is one of the most cost-effective continuity tools available to a medcomms team. It is not a calendar invitation with a slide deck. It is a disciplined transfer of context, ownership and confidence.

Across the MedComms Networking UK community, the same refrain appears after a difficult transition: the outgoing colleague knew the client’s approval quirks, the unwritten deadlines and the reason a particular review comment mattered. None of that was in the status report. The aim of this protocol is to move that knowledge out of one person’s head and into a shared, usable record before the thread is tested.

Begin with the pre-handover audit

The transfer meeting should not be the first time the incoming handler sees the account. A short audit, completed by the outgoing handler and reviewed by the line manager or account lead, gives the meeting a factual spine. Keep it proportionate: a two-page account map is usually more useful than a forty-slide history.

The audit should cover six areas. First, the client map: named stakeholders, their roles, decision rights, approval chains and preferred channels. Second, live work: each project’s status, next milestone, owner, dependency and risk rating. Third, compliance context: where the ABPI Code, MHRA requirements, GDPR obligations or internal medical and regulatory review sit in the workflow, and which documents evidence that review. Fourth, the paper trail: where the master files, approval records, briefs, contact reports and version histories are stored, and whether access permissions are already in place. Fifth, commercial and contractual matters: purchase orders, rate cards, scope changes, invoicing cycles and any agreed variations. Sixth, the unwritten norms: how the client likes to be contacted, what has caused friction before, which meetings are essential and which are ceremonial.

Use a simple red-amber-green rating for live projects and a separate column for ‘must know’ versus ‘nice to know’. The discipline lies in distinguishing a fact from an interpretation. ‘The client prefers a Tuesday call’ is a fact. ‘The client dislikes surprises’ is an interpretation that may still be useful, provided it is labelled as such. The incoming handler should be able to read the audit and ask informed questions, not simply receive a download.

Speak to the client before the client hears it elsewhere

Client-facing communication should be agreed with the account lead and, where relevant, the client services director. The principle is simple: the client should hear about a change of handler from the agency, not from a delayed email, an out-of-office reply or a copied-in colleague. A single, clear message is usually better than a sequence of partial updates.

That message should name the incoming handler and any interim backup, explain the overlap period, confirm the effective date and offer a short introductory call. It should not over-explain internal reasons. ‘Sarah is moving to a new role within the team and will hand over to James over the next two weeks’ is sufficient. ‘Sarah is leaving under a restructure and we are still finalising cover’ invites uncertainty that the client does not need. If the change is leave rather than departure, say so plainly and give the return date only if it is confirmed.

For UK teams, timing matters. Avoid issuing a handover note on a Friday afternoon before a bank holiday weekend or in the middle of a major review cycle unless there is no alternative. Where a client has a formal supplier contact protocol, follow it. Where the client has a procurement or vendor-management contact, include them in the message. The goal is not to make the change sound insignificant; it is to make the continuity feel controlled.

The 60-minute transfer meeting

The meeting should include the outgoing handler, the incoming handler and, where possible, the line manager or account lead. It should be minuted, and the actions should be owned and dated. The agenda below is deliberately tight. Sixty minutes is enough if the audit has been shared in advance.

0–5 minutes: Purpose and roles. Confirm who owns the account from the effective date, who is accountable for live projects during the overlap, and how escalations will work. Agree that the meeting is a dialogue, not a monologue.

5–15 minutes: Client map and relationships. Walk through the stakeholder map, noting who influences whom and where the incoming handler should be visible. Identify any relationship that needs a personal introduction rather than a general email.

15–30 minutes: Live work and risk. Take each red and amber project in turn. Confirm the next deliverable, the client decision needed, the internal reviewer and the date by which the thread must be picked up. Record any promises made to the client, including informal ones.

30–40 minutes: Compliance and documentation. Confirm where approval records sit, which version is authoritative and what the incoming handler must not do without medical or regulatory sign-off. Check access to systems, shared drives and client portals during the meeting rather than after it.

40–50 minutes: Client preferences and communication norms. Cover meeting cadence, reporting format, tone, escalation routes and any known sensitivities. Distinguish between preferences that are contractual and preferences that are habitual.

50–60 minutes: Actions and next check-in. Agree the introductory client communication, the first status report, the date of the 30-day continuity review and the person responsible for updating the account map. Close by asking the incoming handler to summarise the three biggest risks in their own words. If they cannot, the handover is not finished.

Small signals that the thread has been picked up

Clients rarely judge a handover by the quality of the transition document. They judge it by whether the next interaction feels informed. The strongest signals are small and cumulative: an acknowledgement within one working day, an accurate reference to a previous decision, no repeated questions about matters already settled, and a clear owner for the next action. The incoming handler should be able to explain why a deadline moved, not merely that it moved.

Internally, the signals are equally concrete. The account map has been updated, not merely read. Access permissions are verified. The risk log has a named owner. The calendar reflects the client’s real meeting cadence. The outgoing handler is no longer copied into routine correspondence by default. And the incoming handler has begun to build their own relationship with the client rather than borrowing the outgoing handler’s authority.

False signals are easy to spot too. Copying the incoming handler into every email is not a handover. Forwarding a folder is not a handover. Saying ‘I’m across it’ in a status meeting is not a handover. The test is whether the incoming handler can make a routine decision without calling the outgoing colleague, and whether the client can feel that continuity without being told to look for it.

Treat the hour as the start, not the end

A handover is not complete on the day the transfer meeting ends. A 30-day continuity check gives both handlers and the account lead a chance to catch what the audit missed. Keep it short: review the risk log, confirm that the client introduction has taken place, check that the first status report was accurate, and update the account map with anything newly learned. For teams connected through MedComms Networking UK, this is also a useful moment to compare notes with peers who have managed similar transitions. The details differ, but the pattern rarely does: the thread holds when context, ownership and communication are transferred together, and it slips when only the files are.