Your team uses internal runbooks with the four-field format — error, cause, fix, verify. They work great inside the team. You try to use the same format in your Discord support channel and the response feels stiff. Users perceive it as scripted. Engagement drops.

The format isn't wrong. The medium is. Discord and Slack are conversational; runbooks are documentation. The four-field shape needs to compress and warm up to land in a chat thread.

Here's the variant that works.

The compressed shape: 200 characters or fewer

A runbook card has space for code blocks, sections, examples. A Discord reply doesn't — it has to fit on one screen of a phone, in conversational tone, while still answering the question.

The compressed form:

Sounds like [cause]. Try [fix] — should resolve in [time]. Confirm by [verify].

That's about 100-200 characters depending on specifics. Three sentences max. Conversational opener. Specific fix. Verification step.

A worked example. Original runbook entry:

ERROR: nginx 502 upstream prematurely closed connection
CAUSE: PHP-FPM process crashed under load due to memory limit
FIX:   Increase memory_limit in /etc/php/8.2/fpm/php.ini to 512M; restart fpm
VERIFY: tail -f /var/log/nginx/error.log; load test should not produce 502s

Same content, support-channel variant:

Sounds like PHP-FPM hit its memory limit under load and got killed — pretty common with image uploads. Try bumping memory_limit to 512M in php.ini and restarting FPM. Should fix immediately; watch your nginx error log to confirm no more 502s.

Same diagnostic. Same fix. Same verification. Different register — feels like a person, not a template.

What changes between the two formats

Three things get adapted:

Opener softens. "ERROR" → "Sounds like." Same diagnosis, but framed as a hypothesis the user can disagree with.
Why-explanation is folded in. The runbook splits CAUSE and FIX. The chat reply weaves them together: "X happened because Y, fix is Z." Reads as one thought.
Verify becomes "watch for." Not "run this command and check output" — that reads as homework. Instead "should resolve immediately; tell me if it doesn't" puts the verification on you, not them.

These adjustments don't lose information. They reposition the reply as a conversation rather than a documentation handoff.

The structural template

For longer support replies — anything more than 200 characters — keep the same shape but expand each part:

1. Diagnostic statement (1-2 sentences). What you think is wrong.
2. Specific fix (1-2 sentences + optional code). What to do.
3. Verification + escalation (1 sentence). How to know it worked + what to do if not.

That's the entire structure. No bullet points (they signal AI/template). No headings (they signal documentation). Just three connected paragraphs.

What templates lose vs gain

What they lose: the reply doesn't sound like raw human improvisation. There's a structure, and a thoughtful reader can detect it. After a few replies, your repeat customers will notice the pattern.

What they gain: consistency, completeness (the verification step doesn't get forgotten under time pressure), and triability for new support staff. The cost — slight detectability — is worth the consistency.

The detectability cost can be reduced by varying the opener phrase. "Sounds like" / "Bet it's" / "Probably" / "Looks like" — rotate these. Same template, slightly different surface.

When NOT to use a template

Three contexts where the template hurts more than helps:

The user is upset. Templated replies in emotional moments read as cold. Lead with acknowledgment, address the emotion, then drop into the diagnostic.
The diagnosis is uncertain. If you genuinely don't know the cause, don't pretend with a template. Ask one diagnostic question. The template assumes you have a specific hypothesis to share.
The conversation is past turn 3. By turn 3 you should have specifics that no template anticipates. Templates are for turn 1 — the first reply that establishes you read the question and have a hypothesis.

How to build the template library

Same as engineering runbooks: write the card during the fix, not later. After every successful support resolution, take 60 seconds to write the compressed-form template into a shared doc. After a month you have 30. After three months your support team can answer 80% of new questions by adapting an existing template.

The first ten templates feel slow to write. By template 20 the marginal time cost is near zero — you're recognizing patterns instead of inventing them.

The deeper principle

Templates don't replace thinking; they encode the thinking you already did so you don't have to redo it under pressure. Engineering runbooks for engineers, compressed support templates for chat — same idea, different register.

The trap is using one register's format in the other's medium. A documentation-shaped reply in a chat thread. A chat-shaped reply in a runbook. Both feel wrong for the same reason: format doesn't match medium.

Once you've written the same answer five times in a support channel, the sixth time should be a template — adapted, but not invented. That's the definition of mature support tooling.