You said DNS. They heard nothing.
The scenario:
Your engineer explained the outage. It was accurate, complete, and useless, because the client understood none of it and felt stupid for asking twice.
Every unexplained acronym costs a little trust. Clients rarely say “I don’t understand”. They say “fine, thanks”, then they call another provider who talks like a human.
The prompts:
In your AI tool of choice.
STEP 1 - Find your jargon
You are building a plain-English communication standard for an MSP.
Context:
Paste three recent client-facing messages from your team: [tickets, emails, incident updates]
Highlight every term a non-technical business owner would not confidently explain, every sentence written for an engineer rather than a client, and every place the business impact is missing. Rank the three worst habits you find.
-
STEP 2 - Build the transition layer
Produce the standard:
A translation table for our 20 most-used technical terms: the term, the plain version, the one-line analogy
The message structure for any client update: what happened in business terms, what it means for them, what we are doing, when they hear from us next
Three rewritten versions of the messages from step 1, as worked examples
-
STEP 3 - Make it a habit
Design the practice loop: a five-minute segment in the weekly team meeting where one real message is rewritten together, a peer-check rule for incident comms (no technical update goes to a client unreviewed during a P1), and the quarterly check: pull five random client messages and score them against the standard. Include the score sheet.