The step teams most often skip when they close the customer feedback loop is the last one: telling the person who reported a bug that it is fixed. The task moves to Done, the team picks up new work, and the customer still does not know whether to try again. A short message after you verify the result closes that gap and shows the report was worth sending.
This guide starts when work on the fix is underway or has just finished. Turning a ticket into a task is covered in the guide from support ticket to task. Here you will decide how to keep track of the reporter, when you may say “fixed”, and what to send when there will be no fix or it is not ready yet.
When the customer should hear about the fix
Send the message once the change is available to the customer and someone has checked it under conditions similar to the report. Not when a developer merges the code, and not when the task changes status. Those events track the team's progress; the customer only cares whether their task works again. If the fix reaches everyone only with the next release, wait for the release.
GitHub's documentation explains that an issue linked with a closing keyword is closed automatically when the pull request is merged into the default branch. That reflects the state of the repository, not proof that the fix already works for the customer: GitHub: linking a pull request to an issue.
The customer deserves an answer when the outcome is something other than a fix, too. A decision of “we won't fix this” or “we will check again on a set date” is information they can plan around.
Keep the reporter linked to the task
The loop usually breaks at the handoff. Support creates a task and the ticket is closed as “passed on”. When the work finishes weeks later, nobody remembers who asked for it. If five customers report the same bug, all five tickets should point to a single task.
- The task links to every ticket it covers, including tickets attached later.
- The ticket has an internal note with the task number and the name of the person who will reply.
- For duplicates, you add the new reporter to the existing task instead of closing their case without a trace.
- A quote from the customer's first message is saved so the reply can reuse their words.
The quote field is easy to add if you use a bug report handoff template. Separate the roles as well: the task owner is responsible for the fix, the contact owner for the message. It can be the same person, but then write that down explicitly.
Verify the fix before you write “fixed”
- Go back to the reported steps.Repeat the customer's action in their environment: same browser or device, similar data, same account type.
- Compare with the expected result.Check the outcome the customer wanted, not just that the error message has disappeared.
- Decide whether the customer must act.Refreshing the page, signing in again or repeating an order has to go into the message.
- Record the result on the ticket.A note such as “checked 8 Oct in Safari, saving works” lets a colleague send the message without retesting.
If the check fails, do not send “it should work now”. The other side of this process, asking for confirmation and deciding when to close the case, is covered in the guide on confirming a support resolution. When a change affects many customers and the whole support team, a proper change handoff to the support team helps too.
Reply in the customer's words, not the task's
A task title is written for the team: it names a component, a version or an abbreviation. The customer described the problem differently and will recognise their case by that description. Start with their situation, then say what they will see now. The table below shows invented examples of the rewrite.
Scroll the table sideways to see all columns.
| Task description | Customer's words | Sentence in the message |
|---|---|---|
| Date validation in the reschedule form | I can't move my appointment to tomorrow | Moving an appointment to the next day works again |
| CSV export fails on accented characters | Names show up as garbled symbols in the file | Names with accented letters now export correctly |
| Cart regression after coupon change | My discount code disappears at checkout | Your discount code now stays in the cart until payment |
Leave out the technical cause unless the customer asked about it. One sentence of explanation is enough when it helps them judge whether the problem could return.
Three templates: fixed, won't fix, not yet
Each template has the same parts: a reference to the report, the state of the case, what the customer can do now and whether anyone will be in touch again.
“Hi [name], on [date] you told us that [customer's words]. The fix is now live and we tested it on [device/browser]: [what works now]. If the page was already open, a refresh is all it takes. Just reply in this conversation if anything still looks off. Thanks for the detailed description, it really helped.”
“Hi [name], I'm following up on your report about [customer's words]. After reviewing it, we have decided not to change this behaviour because [short, honest reason]. I understand this makes [customer's goal] harder. For now you can [verified workaround]. If the decision changes, I will write to you in this same case.”
“Hi [name], the problem with [customer's words] is still waiting for a fix. It is on the team's list, but I can't give you a release date today. Until then, [workaround, or a note that there is none]. I will check progress on [specific date] and get back to you then, whatever the outcome.”
In the third template the promise is a contact date, not a fix date. Put it in a calendar or an internal note on the ticket and keep it. If the reason for declining is a product decision rather than a technical obstacle, the guide on customer requests and the roadmap explains how to justify it.
A rule for old reports
Sometimes a fix arrives six months after the report. A message still makes sense, as long as it is short and does not require a reply. Open by reminding them what the report was about, because without that context the message looks like spam.
Agree on one rule for the whole team, for example: reports older than three months get a single informational message with no request to test, and the case is closed if the customer does not reply. Do not write to people who have clearly ended the relationship and do not want further contact. When the bug was part of a wider outage with many tickets, the guide on coordinating customer updates during an incident sets out the order of updates.
Case status the customer can see in Meetlead
In the Projects app you can create a task from a ticket or link an existing task to it, and one task can have several tickets linked. Internal notes on a ticket are not visible to the customer, so you can record the verification result and the person responsible for the message there.
When persistent tickets are enabled on the site, the customer sees a list of their cases in the widget with a reference number, the latest message and a status: open, resolved or closed. A reply sent on the ticket lands in that same case, and if the customer answers a resolved case, the ticket reopens. Changing a task's status sends the customer no message: you write the reply yourself. Projects requires an account, an active app on the site and access in your plan.
Questions about closing reports after a fix
Do I have to ask the customer to test the fix? Not always. If you verified the result under their conditions, an update with an invitation to reply if something still fails is enough. Ask for a test when you cannot reproduce the customer's environment, such as their data or device.
What if the fix only solved part of the problem? Say exactly what works now and what is still pending, and treat the remaining part like the “not yet” template with a date for the next contact. Do not close the case just because the task in Projects is complete. Log the missing part as a separate task linked to the same ticket.
