Use when writing the follow-up message sent to a customer AFTER a support ticket was already resolved — the check-in that confirms the fix actually held, gives a concrete reopen path, and makes one soft satisfaction/rating ask, instead of leading with a survey plea, stacking multiple asks, or guilt-tripping for feedback.
NewStale
Automatic
◆Support pack
What it changes
5 of 13 test cases passed with the skill.
Pass-rate lift
—
Tokens
+148%
Agent turns
0%
Response time
-31%
Model gemini-3.5-flashMeasured 7/8/2026v15 of 13 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: the two benchmark arms were not comparable.
What's inside
The instructions your model reads when the skill loads.
SKILL.md39 linessingle file
Post-resolution CSAT follow-up
This is the message you send after a ticket is already resolved — a short check-in a
day or a few days later. Left to itself, the base model turns this into a survey plea:
it leads with the rating request, stacks several asks, and leans on guilt ("it would
mean the world," "it only takes two minutes," "we'd really appreciate it"). It also
tends to assert the fix worked rather than confirm it, and to close with a vague "let
us know if you need anything" instead of a real reopen path.
Write the follow-up in these three moves, in this order. The rating ask is last, single,
and soft — never the lede.
Confirm the fix actually landed. Open by naming the specific issue that was
resolved and checking that it is genuinely working for the customer now — invite them
to confirm, rather than declaring victory on their behalf. "Wanted to make sure the
export is working for you now" beats "Glad we solved your problem!"
Give a concrete reopen path. Tell the customer exactly how to get help again if it
is not fully fixed — a specific action, not a platitude. "If it's still happening,
just reply here and this ticket reopens" beats "let us know if you need anything." If
the thread stays open for a set window, say so.
Make one soft rating ask, last. A single low-pressure line inviting a rating or
quick feedback, placed at the end and clearly optional. One ask, not several.
Guardrails
Rating ask never leads. The follow-up exists to confirm the fix, not to harvest a
score. If the survey line is the first thing, it is wrong.
No guilt or pressure framing. Drop "it would mean so much," "please," "only takes
a minute," "we really need your feedback." The ask is optional and reads that way.
One ask only. Do not request a rating and a review and a testimonial. Pick the
single softest ask.
Confirm, don't assume. Do not claim the problem is fully solved for the customer;
invite them to confirm it is working on their end.
Skip the ask when it's tone-deaf. If the resolution was partial, delayed, or the
customer was clearly frustrated, confirm the fix and offer the reopen path — and omit
the rating ask rather than force it.
Use when structuring or writing a piece of project documentation: classify the need into exactly one of the four Diataxis modes -- a learning tutorial, a goal-directed how-to guide, dry reference, or conceptual explanation -- and keep the document pure to that one mode instead of blending teaching, steps, lookup material, and discussion on a single page. Do NOT use for setting up a docs toolchain or building the docs site, proofreading or fact-checking existing pages, or planning the documentation team's work.