How to write a 'we fixed it' message

What a fix message has to do

A fix message has one job: to tell the person who was affected that the problem is gone, and to give them a simple way to confirm it. It is easy to write something vague, such as "we have resolved the issue", that means nothing to the reader. The customer does not know which issue you mean, whether it is fixed for them, or what to do next.

A good fix message is specific. It names the problem the way the customer described it, says what changed, and tells them what to check. It sounds like a person who knows what happened, not a status page. Send it only after the fix is live for the people it affects, because a message that arrives before the fix creates a second round of frustration.

The five parts of a good fix message

Most useful fix messages have five parts, in roughly this order:

1. The problem, in the customer's words. Repeat the symptom they reported, such as "the total showed as blank on the invoice page".
2. What changed. One sentence about the fix, without internal jargon. "The total now loads from the saved amount instead of the draft" is enough.
3. When it went live. Give a date or say "as of today". This matters when the customer has to check something specific.
4. Thanks for the report. Name the detail that helped, such as the browser or the steps, because specific thanks shows that you read the report.
5. An invitation to confirm. Ask them to check one thing and reply if it still fails.

You can cut parts without losing the message, but the thanks and the invitation are the parts most teams skip, and they are the parts that turn a closed bug into a trusted relationship.

Template for the person who reported it

Send this from your own email to the reporter, not from a shared address. Replace the bracketed parts with the facts.

Hi Dana, the blank total on the invoice page is fixed as of this morning. The page now loads the saved amount instead of the draft, which is what caused the blank value after you saved a draft. Thank you for including the Safari version and the steps. They made it quick to find. Could you open the invoice page again and tell me if the total shows now? If it still fails, reply with the invoice number and I will look at that one.

The message has all five parts in four sentences. It does not say "sorry for any inconvenience", which adds nothing, and it does not promise the same fix for every browser. If the fix has a known limit, say it: "This covers Safari and Chrome. I have not checked Firefox yet."

Thank the reporter without overdoing it

Thanks work best when it names something specific that the reporter did. "Thanks for the report" is polite but generic. "Thanks for the steps, they let me reproduce it in one try" tells the person that their effort mattered. Avoid phrases that sound like a form letter, and avoid thanking them for something they did not do, such as "for your patience" when they were not waiting.

If the person found the bug through a long, unclear message, thank them for the part that helped, even if the rest was messy. People remember who was kind to them about a bug.

Invite the reporter to confirm

The invitation is the most useful part of the message. It gives the reporter a simple action and tells you whether the fix works in the wild. Keep it to one request. "Could you check the export on your largest project and tell me if the file opens?" is clear. "Let us know if you have any other feedback" is not.

Invitations also protect you. If the fix does not work for someone, they have a direct way to reply in the same thread, and you can reopen the item with a note instead of finding out weeks later.

Templates for several reporters

When one bug affected many people, you may need to write to each reporter. Keep the core facts the same and vary only the greeting and the detail that matters to that person. Do not paste one message into a bulk tool that makes it look like a newsletter. Each reply should look like it came from you, because it did.

Hi Ravi, the export timeout on large projects is fixed as of today. Exports now run in batches, so the file should finish even for projects with many attachments. Could you try the export on the project you mentioned and let me know if it completes? Thanks for flagging the size of the project, that detail is what let us reproduce it.

For a fix that is live but not yet verified for everyone, say so. "This is live for new exports. Older scheduled exports will run the new way on their next cycle" is honest and gives the reader the one thing they need to know.

Mistakes that make a fix message worse

Do	Do not
Name the symptom the customer described	Write "an issue with the system"
Say what changed in one sentence	Explain the internal cause at length
Give the date the fix went live	Say "soon" or "shortly"
Ask for one specific check	Ask "let us know if anything else comes up"
Say what is still unverified	Claim the fix works everywhere

Sending fix messages from the Escuta Produto inbox

Find the original item in the inbox first. Search the message words to check whether others reported the same problem, and read the page URL and metadata so your fix message names the right page. When the fix is live, set the status to done, and add an internal note that says what changed and which reporters you wrote to. That note is what the next teammate needs when someone writes in again.

Write each message from your own email to the address on the item. Escuta Produto does not send automatic emails to customers, so the fix message is only as good as the reply you write. For how to announce fixes more widely, such as in a changelog, read how to write a changelog customers read. The status meanings and the done state are described in how to design a feedback status workflow, and the widget setup that captures the original report is in the widget docs.