Client Support Retainer Primary Contact Change Pack With AI

When the person who owns your support retainer on the client side changes—promotion, resignation, reorg, or a new vendor manager—you are not starting a new contract and you are not offboarding. You are doing a mid-contract primary contact change: tickets keep flowing, SLAs still apply, and both sides need a written handoff before someone assumes escalation authority.

This pack uses ChatGPT for structured drafts, Google Docs for the addendum everyone signs off on, and Gmail for a short, professional sequence. It complements your retainer kickoff (first week) and is the opposite of termination offboarding (contract end).

Browse more playbooks in guides.

When to run this pack

Trigger it when any of these happen:

• The named primary contact in your retainer SOW is no longer the day-to-day owner.
• A new PM or ops lead will approve scope, hours, and escalations going forward.
• Access or distribution lists still point at someone who has left or changed roles.
• The client asks, "Can you loop in Sarah instead of James?" without sending a formal update.

Do not treat a casual CC as sufficient. A one-page addendum prevents duplicate threads, wrong approvers, and accidental access gaps.

What you will produce

1. A FACT / ASSUMPTION snapshot of open work and contacts.
2. A Primary Contact Change Addendum (Google Doc): new names, channels, escalation ladder, access notes.
3. A three-email Gmail sequence: outgoing thank-you, incoming welcome + doc link, internal team sync.
4. An access audit checklist (remove old, add new, verify shared inboxes).
5. A line item for your next monthly retainer review: "Contact change completed on [date]."

Step 1 — Build the FACT / ASSUMPTION snapshot

Paste into ChatGPT (or your preferred model) with no client secrets—use initials and ticket IDs only:

You are helping a support retainer provider document a primary contact change.

FACTS (only what I provide):
- Client:
- Outgoing primary contact (name, role, last day if known):
- Incoming primary contact (name, role, start date):
- Retainer tier / hours / SLA summary:
- Open tickets or themes (IDs + one line each):
- Tools/channels in use (email, Slack, portal):

ASSUMPTIONS (label clearly):
- Incoming contact has authority to approve hours top-ups and change requests: [Y/N/unknown]
- Outgoing contact will remain copied for [X days]: [Y/N]

Output:
1) Three risks if we skip a written handoff
2) Bullet list of open items the incoming contact must know
3) Questions to confirm in one 15-minute call

Save the model output in a scratch doc. You will reuse sections in the addendum.

Step 2 — Draft the addendum in Google Docs

Create a doc titled "[Client] — Retainer Primary Contact Change — [date]" with these sections:

Section	Purpose
Summary	One paragraph: what changed and effective date
New primary contact	Name, role, email, phone, timezone, backup contact
Outgoing contact	Thank-you line + whether they stay on CC and until when
Escalation path	L1 → L2 → client exec; response expectations unchanged
Channels	Which inbox/Slack channel is authoritative; what to retire
Open work index	Table: ID, summary, owner, next action, needs approval?
Access notes	Who loses/gains portal, shared drive, billing visibility
Acknowledgment	Both parties confirm by reply or e-sign

Ask ChatGPT to turn your FACT block into polished prose for Summary and Open work index rows. You edit every line—AI speeds formatting, not judgment.

Step 3 — Access audit (15 minutes, no shortcuts)

Work from the addendum access table:

• Remove or downgrade the outgoing contact on ticket systems, shared drives, and billing CC lists unless the contract requires a longer overlap.
• Add the incoming contact with the minimum role needed (read vs approve).
• Verify shared inboxes: if the client used a personal inbox before, recommend a role-based address (support@client.com) so the next change is cheaper.
• Document what you changed in the addendum footer ("Access updated [date] by [you]").

If the client cannot remove the old contact immediately, note it as an open risk in the doc and set a follow-up date.

Step 4 — Gmail sequence (paste-ready)

Email A — to outgoing contact (cc incoming + your lead)

Subject: Thank you — [Client] retainer handoff to [Incoming name]

Hi [Outgoing],

Thank you for partnering with us on [Client]'s support retainer. As [Incoming] steps in as primary contact effective [date], we've published a short addendum (link) covering escalation paths, open items, and channels.

You'll [remain on CC for X days / roll off ticket approvals on date]. If anything still needs your sign-off, reply on this thread before [date].

Best,
[You]

Email B — to incoming contact (cc outgoing if overlap)

Subject: [Client] support retainer — your primary contact pack

Hi [Incoming],

Welcome as primary contact for [Client]'s support retainer. Attached/linked is a one-page addendum with:
- How to reach us and SLA expectations
- Open tickets/themes and what needs your approval
- Official channels (please use [inbox/portal] for new requests)

Please reply "Acknowledged" or add comments in the doc by [date]. We can do a 15-minute walkthrough if helpful.

Best,
[You]

Email C — internal (your team only)

Subject: INTERNAL — [Client] contact change complete

Contact change effective [date].
New approver: [Incoming] — [email]
Outgoing: [Outgoing] — [roll-off date]
Doc: [link]
Access: [done / pending item]
Do not discuss billing or scope with outgoing after [date] unless client confirms in writing.

Step 5 — Optional 15-minute alignment call

Use the questions ChatGPT listed in Step 1. Confirm:

• Who approves hours top-ups and change requests now?
• Whether the outgoing contact stays on P1 incidents only, or fully rolls off.
• If billing contact differs from operational primary (common in SMBs).

Update the Google Doc live during the call; send Email B immediately after.

Step 6 — Log it for the next monthly review

Add a row to your retainer health notes:

Date	Event	Link
[date]	Primary contact change	[Doc URL]

This prevents your monthly review from treating a spike in "who is CC'd?" threads as a mysterious SLA issue.

Common mistakes

• Skipping written ack — verbal "Sarah's in charge now" does not update approvers for credits or CRs.
• Leaving old access live — security and duplicate replies; fix the same day.
• Confusing with offboarding — termination packs archive work; this pack continues the retainer with new ownership.
• Confusing with kickoff — kickoff sets initial rules; this amends rules mid-flight.

Tie-in: change requests and hour approvals

A contact change often surfaces the same week someone asks for extra scope. That is a separate change request pack—but the approver name in your CR memo must match the addendum. After the contact change, search your draft CRs and hour-top-up memos for the old name; update before sending. If utilization is tight, cross-link to your hours top-up playbook only after the incoming contact confirms they hold signing authority.

Scenario notes (SMB vs agency client)

Single-location SMB: The owner may have been the primary contact while a office manager runs tickets. Clarify in the addendum who can commit budget versus who can log requests.

Agency or holding company: Marketing ops might own the retainer while IT owns access. Split the access table into operational and technical columns so you do not revoke the wrong Slack workspace.

Overlap period: When the outgoing contact stays 5–10 business days on CC, state in Email A exactly which message types still require their reply (billing disputes, legal, executive escalations only).

Human-in-the-loop

AI drafts tables and email tone; you verify names, dates, ticket IDs, and contractual authority. Never auto-send Gmail without reading. If the change happens during an active P1 incident, finish stabilization first, then run this pack within 48 hours.

Quick checklist

• FACT / ASSUMPTION snapshot saved
• Google Doc addendum shared with both contacts
• Access audit completed or dated follow-up
• Three Gmail messages sent (or scheduled)
• Incoming contact acknowledged
• Monthly review log updated

You keep the retainer running smoothly when people change seats—without pretending the contract restarted or ended.