RTFM-IT-Services-LLC {{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.