KoltrixClosing the loop: following up after a fix ships
A runbook for telling customers their bug is fixed: track who reported it, write the follow-up, confirm it works, and handle the cases where it does not.
On this page(12 sections)
- Why bother
- Step 1: Record who reported it, at report time
- Step 2: Get notified when the fix ships
- Step 3: Verify before you write
- Step 4: Write the follow-up
- Step 5: Handle the replies
- "It's still broken for me"
- "It's fixed, but now X is broken"
- No reply
- Step 6: Clean up
- What to avoid in the follow-up
- When there are many affected customers
- When you decide not to fix it
- The runbook at a glance
- Bottom line
The customer reported the bug, you said "we're looking into it," engineering fixed it two weeks later, and nobody told the customer. That silence is one of the easiest support failures to prevent.
A follow-up after a fix ships costs a few minutes per customer and turns a bad experience into evidence that reporting problems to you is worth it. This runbook covers the whole loop, from the moment a bug is reported to the confirmation that it's resolved for that customer.
Why bother
Customers who report bugs are doing you a favor. They took time to describe a problem instead of quietly leaving. When they never hear back, they learn that reports disappear. When they get a short "this is fixed, thanks for flagging it," they learn the opposite, and they tend to report the next problem too, which is exactly what you want.
There's a practical reason as well: a customer who worked around a bug may never notice it's fixed. Telling them restores the workflow you built for them.
Step 1: Record who reported it, at report time
The follow-up is impossible if you can't find the people who reported the issue. Do this when the bug comes in, not when it's fixed.
- Link every report to one issue. When a bug is filed in your tracker, include the thread link for the first reporter. When a second customer reports the same thing, add their thread link to the same issue instead of opening a new one.
- Label the threads. A label like
waiting-on-fixin the shared inbox gives you a second way to find affected customers. - Tell the customer what happens next. "I've logged this with our engineers and linked your message, so I'll email you when there's a fix" sets the expectation and commits you to the follow-up.
A simple issue section works:
Reported by:
- [thread link] — [customer/company] — [date]
- [thread link] — [customer/company] — [date]
Workaround given: [yes/no, what]
Step 2: Get notified when the fix ships
Support shouldn't have to watch the deploy log. Agree on one trigger with engineering:
- The issue is closed with a note like "deployed to production," and support is subscribed to it, or
- The engineer posts in the support channel with the issue link when the fix is live.
"Merged" isn't "shipped." Agree that the trigger means customers can see the fix.
Step 3: Verify before you write
Before emailing anyone, confirm the fix yourself if you can. Reproduce the original steps from the report. This catches the uncomfortable case where the fix covers the engineer's test scenario but not the customer's exact setup. If you can't reproduce in your own account, at least check with the engineer that the customer's scenario was the one tested.
Step 4: Write the follow-up
Keep it short and specific. The customer may have forgotten the details, so remind them.
Subject: Re: [original subject]
Hi [name],
Good news: the issue you reported on [date], where [one-line description],
is fixed as of today.
[If there was a workaround:] You can stop using [workaround] now.
[If they need to do anything:] You may need to [refresh / re-sync / reconnect].
Could you let me know if it's working for you? If anything still looks
off, reply here and I'll pick it straight back up.
Thanks again for reporting it. It helped us find the cause.
[name]
A few notes on the wording:
- Reply in the original thread so the context is right there.
- Describe the problem in their words, not your internal issue title.
- Say what changes for them, especially if they used a workaround.
- Ask for confirmation. It invites them to tell you if it isn't fixed and shows you care whether it works.
- Thank them specifically for the report, not generically for "their patience."
Step 5: Handle the replies
Most replies will be a quick "works, thanks." Some will not.
"It's still broken for me"
Treat this as a new piece of evidence, not a failure. Ask for exactly what you need to compare (steps, time, browser or app version, screenshot), reopen or relink the issue, and tell the customer you've done so. Don't send a second "it's fixed" until you've verified their specific case.
"It's fixed, but now X is broken"
Thank them, split it into a new issue, and treat it as a fresh report. Don't fold it into the old thread's issue, which will confuse everyone.
No reply
That's fine. After a few days, remove the waiting-on-fix label and close the thread. Don't send a second nudge for a confirmation; one follow-up is enough.
Step 6: Clean up
- Remove the
waiting-on-fixlabel from every thread you followed up on. - Note on the issue that all reporters were contacted.
- If the bug was common, update any help article or snippet that mentioned the workaround.
What to avoid in the follow-up
- Over-explaining the cause. One sentence is plenty unless the customer is technical and asked. Internal details ("a race condition in the sync worker") rarely help and sometimes alarm.
- Blaming another team or vendor. The customer doesn't care whose code it was. "We found and fixed the cause" is enough.
- Bundling a sales message. A fix follow-up is not the moment to mention an upgrade.
- Sending it before it's live everywhere. If the fix is rolling out gradually, wait until it reaches the customer's account, or say clearly when it will.
When there are many affected customers
If dozens of people reported the same problem, individual replies are still best for the ones who wrote in. You can use the same template, but personalize the first line. For customers who were affected but never reported it, a short product update or changelog note is usually enough. Don't email your whole customer base about a bug most of them never saw.
When you decide not to fix it
Closing the loop also applies to "won't fix." If the team decides a reported bug won't be addressed soon, tell the reporters honestly, explain the workaround, and thank them. Silence is worse than a no.
The runbook at a glance
- At report: link the thread to the issue, label it, tell the customer you'll follow up
- Agree with engineering on a "shipped" notification
- Verify the fix against the customer's original steps
- Reply in the original thread with what changed and a request to confirm
- Handle "still broken" as new evidence, not a closed case
- Remove labels, note on the issue, update help content
Bottom line
Following up after a fix is cheap, quick, and one of the clearest signals that your team listens. The work is mostly bookkeeping at report time: link the thread, label it, and promise the follow-up. When the fix ships, verify it, write a short specific email, and ask whether it works for them.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
