msp-client-comms

{{COMPANY_NAME}} Client Communications

Defaults you must review. The specific numbers in this skill are shipped example defaults from a working MSP. Review and replace them with your own before anything goes client-facing.

This skill is the source of truth for the messages {{COMPANY_NAME}} sends clients during service: routine, urgent, and awkward. Consistent, calm, plain-English communication during a problem is the product, as much as the fix itself. A client who hears from {{COMPANY_NAME}} quickly, in words they understand, with a promise of the next update, experiences a very different outage than one who hears silence.

Everything here rides on msp-brand: friendly expert, plain English, outcomes not specs, the standard signature block, and no em dashes anywhere.

---

Global Rules

• Plain English, always. "Email is down for your whole office," not "we are experiencing an email service degradation." Per msp-brand, write to the office manager, not to IT.
• No blame, no vendor trash talk. "Our upstream provider is working on it," not naming and shaming. {{COMPANY_NAME}} owns the client experience even when a vendor owns the fault.
• Every time reference carries the date and {{TIMEZONE}}.
• Incident messages always end with the next-update commitment, and {{COMPANY_NAME}} keeps it even when the update is "still working on it."
• Never speculate about cause in writing during an active incident. Facts observed, actions taken, next step. Cause analysis goes in the post-incident summary, after it is known.
• Legal gate: anything touching a possible security breach, regulated data, an admission that could read as fault, or contract mechanics (like the price letter) passes through msp-legal before sending.
• Update cadence and severity words come from msp-helpdesk. A message about a P1 says things are urgent because they are; a P3 does not borrow urgency to look responsive.

Placeholders appear in [brackets]. The support intake address is {{SUPPORT_EMAIL}} ({{SUPPORT_ALIAS_EMAIL}} also opens a ticket; print {{SUPPORT_EMAIL}} in anything client-facing).

---

Templates

1. Planned maintenance (send 3 or more business days ahead)

Subject: Scheduled maintenance [day, date]

Hi [name],

We will be doing scheduled maintenance on [what, in plain terms] on [day, date] from [start] to [end], {{TIMEZONE}}.

What this means for you: [impact, e.g. "email will be unavailable for up to 30 minutes during this window"]. You do not need to do anything.

If anything seems off after [end time], let us know at {{SUPPORT_EMAIL}} or {{PHONE}}.

[Signature block]

For emergency maintenance, same structure plus one honest sentence on why it cannot wait, and an apology for the short notice. Send a two-line "complete, all clear" when done.

2. Incident: initial notice (within 30 minutes of confirming a P1)

Subject: [Company] service issue: [system]

Hi [name],

We are aware that [plain-English symptom, e.g. "email is down for your office"] and we are on it now.

What we know so far: [one or two observed facts]. In the meantime: [workaround, or "no action needed on your end"].

Next update: by [time], {{TIMEZONE}}, sooner if it is resolved.

[Signature block]

3. Incident: progress update (hourly for P1, per msp-helpdesk)

Subject: Update: [system]

Quick update on [issue]: [what has been done or learned since the last note]. [Current state.]

Next update by [time], {{TIMEZONE}}.

[Signature block]

4. Incident: resolved

Subject: Resolved: [system]

[What was affected] is back up as of [time], {{TIMEZONE}}, on [date].

If anything still is not working right on your end, reply here or call us at {{PHONE}}. [For P1s: We will send a short summary of what happened and what we are changing, within 3 business days.]

Thanks for your patience.

[Signature block]

5. Post-incident summary (every P1, standing practice, within 3 business days; through

msp-legal if security or liability adjacent)

Subject: What happened on [date], and what we are changing

Hi [name],

Here is the plain-English summary of [date]'s [issue], as promised.

What happened: [cause in one or two non-technical sentences, stated as fact only once established].

Timeline: [detected time] we spotted it, [milestones], [resolved time] everything was back to normal. Total impact: [duration and who was affected].

What we are changing: [one to three concrete steps, e.g. "we added monitoring that catches this earlier" or "we scheduled the replacement of the aging switch that caused it"].

Questions are welcome. Thanks again for your patience while we worked through it.

[Signature block]

6. Security advisory (e.g. a phishing wave)

Subject: Heads up: [scam type] emails going around

Hi [name],

We are seeing [plain description, e.g. "fake invoice emails that look like they come from your accounting system"] hitting businesses like yours this week. Feel free to forward this to your team.

What to watch for: [two or three concrete tells].

What to do: do not click or reply; forward anything suspicious to {{SUPPORT_EMAIL}} and we will check it, usually within the hour. If someone already clicked, call us right away at {{PHONE}}. Nobody is in trouble; fast beats embarrassed.

We are watching for this on our side as well.

[Signature block]

7. Price change letter

Mechanics come from msp-legal (the MSA's amendment process: 30-day notice, and the client's review window is real, so never obscure it). The number comes from msp-pricing. The delivery belongs in or right after a QBR (msp-qbr) whenever possible; a cold price letter is the last resort. Per the sales philosophy: state the number plainly, wrap it in the value, and never apologize for it.

Subject: An update to your service agreement

Hi [name],

[Two or three specific sentences of value delivered: "This past year we handled [n] requests for your team, verified your backups with a monthly test restore, and got you through the [project] upgrade with no downtime." Pull real numbers from QBR prep, and claim only what actually happened for this client; the monthly restore cadence is established in msp-maintenance, so confirm this client's restore log backs the claim.]

Starting [effective date, 30 or more days out], your monthly rate will change from $[current] to $[new]. [One plain sentence on why: costs of delivering the service, growth of the team we support, expanded scope.]

Per our agreement, this change takes effect after a 30-day notice period, and I am glad to walk through it with you before then. Call me at {{PHONE}} or reply here and we will find a time.

[Warm close.]

[Signature block]

8. New user ready / user offboarded

Subject: [New person]'s setup is ready

Hi [name],

[New person] is all set: account created, email working, [computer] configured, and access to [systems] in place. [Anything they need on day one, e.g. sign-in steps sent to their personal email.]

[Signature block]

For departures, confirm the reverse: account disabled as of [time], mail routed to [person], files preserved at [location], per your instructions. The written confirmation matters; access removal is the kind of thing people later need proof of.

9. Ticket closing notice (no response for 5 business days)

Subject: Closing out: [issue]

Hi [name], we have not heard back, so we are marking [issue] resolved. If it is still acting up, just reply and this reopens; no need for a new request.

[Signature block]

10. Security incident notice, affected client (ALWAYS through msp-legal before sending)

For a suspected or confirmed compromise affecting this client specifically. Facts observed only, no cause speculation, no admissions, no scope guesses. The attorney reviews before it goes out, every time; if regulated data may be involved, the attorney may direct different or additional notice.

Subject: Security issue affecting [system/account], and what we are doing

Hi [name],

We identified [plain factual description, e.g. "unusual sign-in activity on one of your email accounts"] at [time], {{TIMEZONE}}, today. We have [containment steps taken, e.g. "secured the account and signed out all active sessions"] and we are investigating.

What we need from you right now: [specific asks, e.g. "please have staff hold off on clicking anything unusual and call us rather than emailing about this issue"].

Next update: by [time], {{TIMEZONE}}. If you have questions before then, call me directly at {{PHONE}}.

[Signature block]

---

Setup Decisions

The values below shipped as example defaults from a working MSP. Confirm each for your own shop before anything here reaches a client:

• Support intake: shipped as {{SUPPORT_EMAIL}}, with {{SUPPORT_ALIAS_EMAIL}} as a working alias.
• Post-incident summaries: shipped as standing practice for every P1, no exceptions; decide whether that stays absolute for your shop.
• Quiet-close window (template 9): shipped default is 5 business days, matching msp-helpdesk.