# Client health log

This is the tracker you set up once and keep for as long as you have clients. It turns "this client is driving me crazy" into a dated record you can act on, instead of a feeling you carry around until it boils over.

Keep it wherever you already keep client notes: a spreadsheet, a notes field in your CRM, a plain notes app. It needs six columns and a habit, nothing more.

## The columns

| Date | Client | Incident type | Severity (1-3) | Contract clause implicated | Action taken |
|---|---|---|---|---|---|
| | | | | | |

**Date.** Use the day the incident happened. Log the row within 24 hours while the details are still accurate; wait a week and you'll remember the feeling but lose the facts.

**Client.** Name or account ID. One row per incident, even if the same client shows up ten times this quarter. That repetition is the point.

**Incident type.** Use a short, consistent label so you can scan the column later and see a pattern instead of ten different stories. Pick from:
- Scope creep (a request outside the signed scope, delivered as if it were included)
- Late or disputed payment
- Abuse (a call or message where the client was hostile, demeaning, or abusive to you or a team member)
- Renegotiation demand (the client tries to change price or terms outside the agreed review point)
- Missed input (the client failed to provide something they owed you, and it cost you time)
- Other (name it in one phrase)

**Severity (1-3).**
- 1: Annoying, cost you under an hour, resolved the same day.
- 2: Cost real time or money, needed a direct conversation to resolve, left a bad taste.
- 3: Involved abuse toward you or a team member, a broken payment promise, or a demand you could resolve only by giving away something you didn't want to give.

**Contract clause implicated.** If the incident touches something your contract actually covers (scope, payment terms, a deliverable definition), name the clause or section number. If nothing in the contract covers it, write "none," which is itself useful information for the next contract you write.

**Action taken.** What you actually did: absorbed it, had a conversation, sent a written boundary, adjusted the invoice, said nothing. Write it down even when the action was "nothing," because a string of "nothing" rows is its own pattern.

## The monthly review

Pick one fixed day a month and put it on your calendar as a recurring event: for example, the first Monday of the month. On that day, read every row logged since the last review, for every active client, including whichever client is currently on your mind.

For each client, ask:
- Are there three or more rows this quarter?
- Is there a single severity-3 row?
- Is the incident type repeating, or was each one different and unrelated?

A client with a growing column of rows gets flagged for the diagnostic test (see `diagnostic-checklist.md`) before the next incident forces the decision under pressure. That is the entire value of this log: it moves the decision from "I'm furious right now" to "I can see this coming and I have three weeks to think about it."

## What to log going forward

Any incident worth remembering gets a row within 24 hours:
- A request that goes beyond the signed scope
- A payment that comes in late or gets disputed
- A call or message where a client is hostile, demeaning, or abusive to you or your team
- A demand to renegotiate price or terms outside your agreed review cadence

Log it even if you resolved it in five minutes and it seems too small to matter. The small ones are what turn the monthly review from guesswork into an actual read on the relationship.

# Client health log: filled example

This is a sample log for one account, "Meridian Retail," over eleven weeks. It shows what a real pattern looks like on paper, and how a single severity-3 incident can outweigh a long list of smaller ones. Use it as a reference for what a real row looks like.

| Date | Client | Incident type | Severity | Contract clause implicated | Action taken |
|---|---|---|---|---|---|
| 2026-06-08 | Meridian Retail | Scope creep | 1 | Section 2, deliverables list | Reminded client by email that the request was outside the listed deliverables; did it anyway as a one-time favor |
| 2026-06-22 | Meridian Retail | Scope creep | 2 | Section 2, deliverables list | Sent a written note that further out-of-scope requests would need a change order; client acknowledged |
| 2026-07-03 | Meridian Retail | Late payment | 2 | Section 4, net-15 terms | Invoice paid 11 days late with no explanation; sent a reminder at day 10 next time |
| 2026-07-15 | Meridian Retail | Renegotiation demand | 2 | none | Client asked for a 15% discount "given how long we've worked together," with no change in scope; declined, held the rate |
| 2026-07-29 | Meridian Retail | Scope creep | 2 | Section 2, deliverables list | Third out-of-scope request in seven weeks; invoiced it as a change order this time instead of absorbing it |
| 2026-08-11 | Meridian Retail | Abuse | 3 | none | Client's ops manager called a team member "useless" on a recorded call over a delay that was on the client's side; owner took over all future calls with this account personally |
| 2026-08-19 | Meridian Retail | Late payment | 2 | Section 4, net-15 terms | Invoice paid 9 days late again; second late payment in six weeks |
| 2026-08-24 | Meridian Retail | Diagnostic run | (n/a) | n/a | Ran the pattern-versus-bad-week test: 7 logged incidents in 11 weeks, one severity-3 staff-protection incident, owner now personally intervening to protect the team from this account. Result: proceed to Phase 3, try a renegotiation first, since the scope-creep pattern suggests a rate mismatch as well as a conduct problem. If the abuse repeats even once during the renegotiation window, skip straight to termination. |

**What this log shows:** six operational incidents (scope creep, late payment, renegotiation pressure) that on their own might read as "a client with some rough edges," plus one severity-3 abuse incident that changes the read entirely. The abuse incident alone clears the staff-protection bar in the diagnostic checklist even without the other six rows. Together, they show a pattern rather than a bad week, and point to a fix that needs to address both the rate structure and the conduct.

# Diagnostic checklist: pattern or bad week

Before you fire anyone, run this test. A bad week feels exactly like a pattern in the moment. This checklist grounds the decision in the record, so the call comes from what's written down rather than from how angry you are on the day you're filling it out.

## Step 1: pull the record

Open the client health log for this account. If it has been running, you already have dated rows. If it wasn't running yet when this incident happened, write out everything you remember: what happened, when, and how many times, as close to dated as you can get it. Do this before you draft anything.

## Step 2: the core pattern test

A pattern that repeats across weeks or months clears the bar for termination. A single incident, no matter how bad it was, clears that bar only if it hits the severity-3 threshold in Step 3.

Ask:
- Are there three or more logged incidents?
- Do they span more than one calendar week?
- Was at least one of them already raised directly with the client, and did the behavior continue anyway?
- Does the behavior trace to the client, rather than to a subcontractor or vendor mistake the client is unfairly being blamed for?

If you answered yes to all four, you have a pattern. Two or more no answers means you don't have enough yet: log it and revisit at your next monthly review instead of acting today.

## Step 3: severity scoring

Score every logged incident 1 to 3 using the definitions in `client-health-log.md`:
- 1: annoying, resolved same day, cost under an hour.
- 2: cost real time or money, needed a direct conversation.
- 3: abuse toward you or a team member, a broken payment promise, or an unresolvable demand.

A single severity-3 incident is treated as sufficient on its own, even with fewer than three total logged rows. Three or more severity-1 or severity-2 incidents spanning more than a week also clears the bar. One lone severity-1 incident falls short.

## Step 4: the staff-protection check

This is the one check that overrides everything else. Ask yourself plainly:

**Does responding to this client currently require you, or a team lead, to personally step in, repeatedly, to protect other team members from how the client treats them?**

If the honest answer is yes, that is a severity-3 pattern by itself, regardless of how many rows are in the log. This is a team-retention problem as much as a client-relationship one: every week you leave it running is a week your team learns that a client's revenue outranks their treatment. That lesson is expensive and it doesn't show up on an invoice.

## Step 5: copy-paste checklist

Use this as your final gate before moving to the next phase.

- [ ] Three or more logged incidents, or one severity-3 staff-protection incident
- [ ] Incidents span more than one calendar week
- [ ] At least one incident was already raised directly with the client
- [ ] The behavior traces to the client's own conduct rather than a vendor or subcontractor mistake wrongly pinned on them

## Step 6: what the result means

- **All boxes checked, no staff-protection issue:** this is a pattern worth acting on, but try the fix short of firing first (see `renegotiation-alternatives.md`). Many "bad client" patterns turn out to be a pricing or scope-structure mismatch that a renegotiation can fix.
- **All boxes checked, staff-protection issue present:** treat this as urgent. A rate change won't fix someone who is abusive to your team. Move toward the contract check and termination sequence.
- **Boxes unchecked:** you don't have enough yet. Log it, tell yourself honestly that this is not termination-ready, and revisit at the next monthly review.

Record whichever result you land on back into the client health log as its own dated row, so the next person reading the log (including future you) can see the decision and when it was made.

# Renegotiation alternatives: fixes short of firing

Run this before you draft any termination notice. A lot of "bad client" patterns turn out to be a pricing or scope-structure problem wearing a conduct problem's clothes. Fix the structure first; only move to termination if the fix doesn't apply or the client won't take it.

## When this phase applies

Open the diagnostic result from Phase 2. This phase applies when:
- The pattern is mostly scope creep, renegotiation pressure, or payment friction, rather than abuse toward you or your team.
- The engagement is priced or scoped in a way that structurally invites the friction (a flat project rate with an open-ended scope, a retainer that hasn't been repriced in over a year, no change-order process at all).
- There has been no staff-protection incident (Phase 2, step 7). A client who requires you to protect your team from them is not a renegotiation candidate; skip straight to Phase 4.

If the friction is abuse, a broken payment promise, or a demand you can't resolve without giving away something you don't want to give, this phase doesn't apply. Go straight to the contract check.

## The three alternatives

### 1. Rate increase

Use when the work has grown beyond what the current rate covers, but the client relationship and scope definition are otherwise sound.

Draft language: "Since we started working together, the scope of what we're delivering has grown to include [specific additions]. Starting [date], our rate for this engagement moves to [new rate] to reflect that. If that doesn't work for your budget, let's talk about scaling the scope back to match the original rate."

- [ ] The specific scope growth is spelled out explicitly
- [ ] The new rate and effective date are both stated
- [ ] An alternative (scale back scope, or end the engagement) is offered alongside the increase

### 2. Scope boundary reset

Use when the core problem is repeated out-of-scope requests treated as included work, but the underlying rate and relationship are fine.

Draft language: "Looking back over the last [period], we've delivered [list of specific out-of-scope items] outside our original agreement. Going forward, requests outside the signed scope will go through a short change-order process: a quick estimate and a yes from you before we start, so nothing catches either of us off guard."

- [ ] The specific out-of-scope items are named, drawn from the client health log
- [ ] The change-order process is described in one or two concrete steps
- [ ] The reset applies to work going forward only (billing past scope creep, if you choose to, runs through the final-invoice-checklist process separately)

### 3. Project-to-retainer conversion

Use when the friction traces to project-rate pricing itself. Project-based and performance-based engagements carry structurally higher churn than retainer or hybrid arrangements, per this skill's cited sources; a client generating scope creep on a project rate may need a different pricing model more than a different attitude.

Draft language: "Given how [ongoing/recurring] this work has turned out to be, I think we'd both be better served moving to a monthly retainer: [rate] per month for [defined scope of ongoing work], with anything beyond that scoped and quoted separately. That gives us both a steadier rhythm than repricing project by project."

- [ ] The retainer scope is defined concretely (hours, deliverables, or a mix)
- [ ] The rate and what counts as "beyond scope" under the retainer are both stated
- [ ] The client's current project is wound down or folded into the retainer cleanly, with no gap in billing

## Presenting the proposal

1. Pick the one alternative that matches the pattern from the diagnostic (rarely more than one applies cleanly).
2. Draft the specific language using the client's own numbers and incidents from the client health log.
3. Present the full draft to the user for approval. Send nothing without the user's explicit yes in the same turn.
4. On approval, hand the approved text to the user's own send channel. This skill drafts the proposal; the user sends it themselves.

## If the client accepts

Log the outcome as a row in the client health log (new rate, new scope terms, or new retainer structure, with the effective date) and close this phase. Continue the monthly review as usual; this account goes back to normal monitoring rather than the termination sequence.

## If the client declines, or the friction continues after acceptance

Move to Phase 4 and start the contract review. A renegotiation that was tried in good faith and still didn't hold is itself useful information: it shows the pattern isn't a one-time misunderstanding, and it strengthens the fit-mismatch framing in the eventual termination conversation.

# Contract termination checklist: clause-by-clause pre-termination check

This is the single most legally load-bearing step in the whole sequence. Read the actual signed contract before drafting anything in Phase 6. A termination that skips this step risks a breach claim even when the client is clearly the problem.

## Step 1: locate the termination clause

Read through the contract (or engagement letter, master services agreement, or statement of work) and find the section that governs ending the relationship. It may be titled "Termination," "Termination for Convenience," "Term and Termination," or buried inside a general "Miscellaneous" section. Common shapes:

- **Termination for convenience:** either party can end the agreement with notice, no cause required.
- **Termination for cause:** one party can end the agreement early if the other breaches specific obligations (nonpayment, missed deliverables, confidentiality violations).
- **No termination clause at all:** some contracts, especially short or informally drafted ones, never address how the relationship ends. This is its own risk category (see Step 6).

- [ ] The termination clause (or its absence) is identified and quoted or paraphrased accurately
- [ ] The clause type is noted: for convenience, for cause, or absent

## Step 2: confirm the notice period

Find the specific number of days' notice the contract requires before termination takes effect. Most service contracts specify something in the 30 to 90 day range, with 30 days most common for ongoing retainer work, but use the number written in this specific contract, never that range as a default.

- [ ] The exact notice period (in days) is recorded
- [ ] The trigger date for that notice period is clear (date of written notice, date of the conversation, date of a specific letter)
- [ ] The resulting effective end date is calculated and double-checked

## Step 3: confirm any early-termination fee

Some contracts, especially fixed-term retainers or project agreements, charge a fee for ending before the term is up.

- [ ] Confirmed whether an early-termination fee exists in this contract
- [ ] If it exists, the fee amount or calculation method is recorded, along with the section number
- [ ] The fee (if any) is passed to the final-invoice-checklist process as a line item

## Step 4: confirm the required delivery method

Some contracts specify exactly how notice must be delivered for it to count: written notice to a named address, certified mail, email to a specific address with read confirmation, or notice to a named contact person.

- [ ] The required delivery method is identified (or confirmed that the contract is silent on method, in which case any reasonable written notice suffices)
- [ ] The named address or contact, if any, is recorded exactly as written in the contract
- [ ] This requirement is passed to Phase 6 so the written notice, if one is needed, gets delivered correctly

## Step 5: confirm deliverables and data handover obligations

Check what the contract says the outgoing party must hand over on termination: work product, source files, account credentials, client data, or IP assignment terms.

- [ ] Any explicit handover or deliverable obligations on termination are listed
- [ ] Any IP or ownership clause relevant to work in progress is noted
- [ ] These obligations are passed to the offboarding-checklist for execution

## Step 6: what to do if the contract is missing, unreadable, or ambiguous

- **No written contract exists:** stop. Tell the user plainly that this skill cannot confirm a notice period or termination right without a document to read, and recommend a specific-clause legal review before any notice goes out.
- **The contract exists but the termination language is genuinely ambiguous** (conflicting sections, an undefined term the outcome hinges on, no clear notice period): stop and recommend the same review. Do not guess at what an ambiguous clause probably means.
- **The contract exists and is clear:** proceed to Phase 5 with the notice period, fee, delivery method, and handover terms confirmed above.

## Copy-paste checklist: contract confirmed before drafting anything

- [ ] Termination clause located and its type identified (for convenience, for cause, or absent)
- [ ] Notice period confirmed in days, with the effective end date calculated
- [ ] Early-termination fee confirmed (amount recorded, or confirmed none applies)
- [ ] Required delivery method confirmed (or confirmed the contract is silent)
- [ ] Deliverable and data handover obligations listed
- [ ] If any of the above couldn't be confirmed, this skill stopped and recommended a legal review rather than guessing

# Final invoice checklist

Send this before the termination conversation. A client who already knows the relationship is ending has less reason to pay promptly, and every day of delay after that conversation makes the invoice harder to collect. Get the money question settled first, then have the conversation.

## Step 1: calculate the outstanding balance

Go through every open invoice for this client and confirm what is unpaid right now. Don't rely on memory. Pull the numbers from your invoicing tool or your books.

- [ ] Every open invoice is listed with its due date and amount
- [ ] Any invoice already past due is flagged separately
- [ ] The total outstanding balance is a single confirmed number

## Step 2: capture unbilled work in progress

Anything you've delivered or are mid-delivery on that hasn't been invoiced yet needs to go on the final invoice now, while it's fresh and while you still have the standing to bill for it in full.

- [ ] Hours or units of work completed but not yet invoiced are listed
- [ ] Work that is partially done gets billed for the portion actually completed, per your contract's terms on partial delivery
- [ ] Any pending approvals needed to bill (a client sign-off, a milestone confirmation) are chased down now, before the notice goes out

## Step 3: add reimbursable costs

- [ ] Any costs you paid on the client's behalf (software seats bought for their project, materials, subcontractor fees) are itemized
- [ ] Receipts or backup for each reimbursable cost are attached or ready to attach

## Step 4: apply the early-termination fee, if one applies

Check your contract check from `contract-termination-checklist.md`. If there is an early-termination fee written into the agreement, and this termination triggers it, add it as its own line item on the final invoice, referencing the specific clause.

- [ ] Confirmed whether an early-termination fee applies
- [ ] If yes, the clause is cited by section number directly on the invoice or in a cover note

## Step 5: set the due date

Use the payment terms already in your contract (net-15, net-30, due on receipt) unless the contract's termination clause specifies different terms for a final invoice. Keep the standard terms even though the relationship is ending. A shortened due date you can't defend gives the client an easy reason to dispute the whole invoice.

- [ ] Due date matches the contract's standard terms, or the termination clause's specific terms if different
- [ ] The due date appears as an explicit date printed on the invoice itself

## Step 6: sequence it

1. Finalize this invoice completely: balance, work in progress, reimbursables, any early-termination fee.
2. Send the invoice through your normal invoicing or accounting channel.
3. Only after the invoice is sent, or scheduled to send within the same window, move to the termination conversation.

Getting this order backward is the single most common way owners lose money on a client exit. The client has every incentive to pay quickly while the relationship is still intact, and far less incentive once they've heard the word "termination."

# Termination call script

Use this after the contract check and the final invoice are both settled. Read it once through before the call so the words are close to automatic, because this conversation goes sideways fastest when you improvise mid-sentence.

## Before you dial

- Have the contract's notice period and effective end date written in front of you.
- Have the final invoice status in front of you (sent, due date, amount).
- Decide in advance: is this a phone call, a video call, or written notice only? If your contract requires a specific delivery method (certified mail, written notice to a named address), treat the call as a courtesy and send the written notice regardless of whether the call happens.
- Get your own explicit go-ahead in the moment before you send the notice or make the call. Treat this as a rehearsal draft: read it through once more even when it feels ready.

## Opening (10-15 seconds, no build-up)

"Hi [name], I wanted to talk with you directly about our working relationship. We're ending our engagement, effective [date from your contract's notice period]."

Say it plainly. Skip the apologies, and keep the wording as firm as the decision actually is.

## The reason (one or two sentences, factual, not personal)

Give a reason that is true and specific, without turning it into a list of grievances. Pick whichever fits:

- "The scope of work has consistently gone beyond what we agreed to, and we've raised that a few times without it changing."
- "We've had repeated payment delays that make this engagement not sustainable for us."
- "The way [incident] was handled on [date] isn't something we can continue working around."

Give one reason. A list of complaints invites a point-by-point argument; a single, true reason closes the conversation instead of opening a debate.

## What happens next (the logistics, stated plainly)

"Here's what happens between now and [end date]: [name any final deliverables owed under the contract]. Our final invoice for [amount] was sent on [date] and is due [date] per our standard terms. [If applicable: any handoff materials or account access will be transferred by (date), per our offboarding checklist.]"

## If the client pushes back

**If they ask "why" again, more pointedly:** repeat the same one reason you already gave, in fewer words. Hold the line rather than adding new reasons under pressure. "As I mentioned, [reason]. That's the reason for the decision."

**If they offer to fix it on the spot:** "I appreciate that, but this decision is made. If you'd like to talk about a different kind of engagement in the future, we can revisit that separately, but this current arrangement is ending as of [date]."

**If they get hostile or personal:** "I'm going to end the call here. Everything you need is in the notice you'll receive in writing." Then end the call. Let the record in your health log speak for the reason; you don't need to argue it live with someone being abusive on the phone.

**If they ask for more time:** extend the date only if your contract allows it and you want to. "The notice period in our agreement is [X days], and that's what we're going with." A grace period you didn't plan for tends to become the new normal.

## Closing (short, no re-litigating)

"I'll follow up in writing with the details we just covered. Thanks for the work we've done together up to this point." Then stop talking. Let the silence sit instead of filling it with reassurance you don't mean.

## Right after the call

- Send the written termination notice within the same day, even if the call felt complete. A verbal notice alone is easy for either side to misremember later.
- Log the call itself as a row in the client health log: date, "termination delivered," and a one-line note on how it went.
- Move to the offboarding checklist for access revocation and handoff.

# Offboarding checklist: handoff and access revocation

Run this after the termination conversation (Phase 6) and before this account is considered closed. The goal is a clean exit: the client gets what they're owed, your team's access to their systems ends, and their access to yours ends on a defensible timeline tied to payment.

## Step 1: deliverables and work product

- [ ] Every deliverable owed under the contract through the effective end date is identified and its status confirmed (delivered, in progress, or not started)
- [ ] Work in progress is either completed to the effective end date or handed over in its current state, per whatever the contract specifies
- [ ] Source files, working documents, and raw materials the client is entitled to are gathered in one place, ready to transfer
- [ ] The transfer method is confirmed with the user (shared drive, direct file transfer, a specific platform's export tool)

## Step 2: shared tool and account access

- [ ] Every shared tool or account the client's team has access to through this engagement is listed (project management boards, shared drives, staging environments, analytics dashboards, communication channels)
- [ ] For each one, note whether access belongs to the client or to you, since that determines who revokes it
- [ ] A revocation date is set for each item, tied to the effective end date and the payment confirmation in Step 4

## Step 3: your team's access to client-owned systems

- [ ] Every system owned by the client that your team has access to is listed (their CMS, their ad accounts, their analytics, their CRM, their codebase)
- [ ] Your team confirms it has exported anything it needs for its own records before access ends (reports, historical data, documentation you authored)
- [ ] The client is asked to revoke your team's access on the effective end date; it's their system, so the revocation itself is their action to take

## Step 4: confirm payment before closing access entirely

- [ ] The final invoice from Phase 5 is confirmed paid, or has a firm, confirmed payment date
- [ ] Deliverable access and shared-account access on your side stays open until that payment condition is met, unless the contract itself sets a different rule
- [ ] If payment is disputed or late past the confirmed date, this is flagged to the user as a collections issue, handled separately from the offboarding sequence itself

## Step 5: internal wrap-up

- [ ] Any team member who worked on this account is notified that the engagement has ended and by when their own access should stop
- [ ] Recurring calendar holds, shared channels, and automated reports tied to this client are canceled or archived
- [ ] The client health log gets its closing row (Phase 8, step 26): termination date, reason category, referral status

## Copy-paste checklist: ready to close the account

- [ ] All owed deliverables transferred or confirmed complete
- [ ] Shared tool and account access revocation scheduled for the effective end date
- [ ] Your team's access to client-owned systems exported first, then handed back to the client to revoke
- [ ] Final invoice paid or on a confirmed payment date before access closes entirely
- [ ] Internal wrap-up done: team notified, recurring holds canceled, log closed out

# Referral note template

Use this only when Phase 8 confirms a referral fits: the fit mismatch traced to scope or budget rather than conduct, and sending the client toward a better-suited provider protects your reputation and closes the exit cleanly. A referral is earned case by case; run the check below before drafting anything.

## When to consider a referral

- [ ] The termination reason was scope, budget, or working-style fit rather than abuse or a broken payment promise
- [ ] The client's underlying need is real and could be well served by a different provider (a smaller agency, a specialist, a lower-cost freelancer, an in-house hire)
- [ ] You know, or can find, a specific provider you'd actually recommend, rather than a generic suggestion to "shop around"
- [ ] Sending this referral doesn't create a conflict with an existing client or partner relationship

If any box above is unchecked, skip the referral. It isn't owed to every client, and a forced or generic one reads worse than none at all.

## Referral note to the client

Use this after the termination conversation, typically alongside or shortly after the written termination notice.

> Hi [name],
>
> Following up on our conversation about wrapping up our work together. I wanted to pass along [provider name], who I think could be a strong fit for [specific need: ongoing content work, a smaller retainer, a specific specialty]. [One sentence on why: worked with them before, know their pricing fits smaller budgets, focused specifically on your industry.]
>
> Feel free to mention that we spoke. I wish you well with [specific project or goal, if known].
>
> [Your name]

- [ ] The provider is named specifically, with a concrete reason for the match
- [ ] The note doesn't promise an outcome on the referred provider's behalf
- [ ] The tone matches the fit-mismatch framing from the termination conversation: no leftover tension carried into this note

## Optional: a short introduction to the referred provider

Send this only with the client's separate permission, since it shares their information with a third party.

> Hi [provider name],
>
> Wanted to introduce you to [client name], who's looking for [specific need]. I think you'd be a good fit for what they need, and wrapping up our own engagement with them. [One line of context they'd find useful.] I'll let you two take it from here.
>
> [Your name]

- [ ] The client has agreed to being introduced before this goes out
- [ ] No confidential client details beyond what's needed for the introduction are shared

## Presenting the draft

Present whichever note applies to the user for approval before anything is sent. This skill only drafts the referral language; the user decides whether to send it and sends it themselves.

# Termination notice: filled example

This is a sample written termination letter for "Meridian Retail," the same account from the client health log example. It follows the contract-termination-checklist requirements: notice period cited, effective date stated, delivery method matching what the contract specifies. Use it as the reference for structure and tone, and swap in the specifics from whichever contract and incident record applies to your account.

---

[Your business letterhead or name]
[Date]

Sent via certified mail to: [Meridian Retail's registered address, per Section 9 of the agreement, "Notices"]

Attn: [Client contact name]
Meridian Retail
[Address]

**Re: Notice of termination, Master Services Agreement dated [original contract date]**

Dear [contact name],

This letter serves as formal written notice of termination of the Master Services Agreement between [your business name] and Meridian Retail, dated [original contract date], pursuant to Section 8 ("Termination for Convenience") of that agreement.

Per Section 8, this agreement requires 30 days' written notice for termination. Accordingly, this engagement will end effective [date 30 days from this letter's date].

Between now and the effective end date, we will complete the following deliverables owed under the current scope: [list specific deliverables, or state "no further deliverables are outstanding" if that's accurate]. Our final invoice, covering all outstanding balances and work completed through the effective end date, was sent on [date] and is due [date] per the agreement's standard payment terms.

Per Section 11 ("Handover on Termination"), we will transfer the following materials by the effective end date: [list source files, account access, or data per that section]. Please confirm the best method for this transfer by [date].

We appreciate the work we've done together and wish Meridian Retail well going forward.

Sincerely,
[Your name]
[Your business name]

---

**Notes on filling this in for your own account:**

- Cite the specific section number and title from the contract you confirmed in the contract-termination-checklist.
- Calculate the effective date from the notice period in that specific contract; this example uses 30 days because that's what Meridian Retail's agreement specified, and a different contract may specify a different number.
- Match the delivery method to whatever the contract requires (Step 4 of the contract-termination-checklist). If the contract is silent on method, any reasonable written delivery works, but certified mail or another method that provides proof of delivery is safer than plain email alone.
- Keep the tone factual and administrative. This letter is the formal record; leave the fit-mismatch reasoning from the termination conversation in the call itself and in the client health log.

Check for a pattern: three or more logged problems spanning more than one week, or a single incident where you or a team lead had to step in to protect staff from how the client behaved. One rough call or one payment that came in a day late falls short of that bar.

Usually yes. If the friction traces back to how the engagement is priced or scoped rather than the client themselves, a rate increase, a scope-boundary reset, or a move from project to retainer often solves it. Only move to termination once that's been tried or clearly doesn't apply.

Check the signed contract first. Most service agreements specify a notice period, commonly 30 to 90 days, and skipping it can expose you to a breach claim even when the client is clearly the problem.

Before. Get the final invoice out and, where possible, collected or at least issued before the termination notice goes out, so the money question isn't tangled up with an already tense conversation.

Keep it short, frame it as a fit problem rather than an accusation, and assume the conversation could become public knowledge one day. A brief warning beforehand, delivered by phone or in person rather than by email, tends to land better and burns fewer bridges.

Keep a running log, wherever you already track client notes, of every incident worth remembering: scope-creep asks, disputed payments, calls where someone on your team was treated badly. Review it for every active client on a fixed day each month, so the next bad fit shows up as a pattern in week three instead of a crisis in month six.