Skip to main content

Issue resolved email templates: telling a customer it is fixed

Seven emails for the moment the bug is fixed, the problem is solved or the fix is on its way. Copy one, change the bracketed parts, send it the day the fix reaches them.

The templates

Each one copies with its subject line. The parts in brackets are the parts to change; everything else can go out as written.

Bug fixed, update available now

Subject: Fixed: [short description of the problem]

Hi [Name], Good news: the [problem you reported] is fixed in [Product] [version number], which is out now. To get it, [open Product and choose Check for Updates / download it from link]. Once you are on [version number], [the thing that was broken] should work as expected. Thank you for reporting it, and for the detail you sent. It made the bug much quicker to find. If anything still looks wrong after the update, reply to this email and I will take another look. [Your name]
Fixed on the server, nothing to install

Subject: Re: [their subject line]

Hi [Name], This is fixed. The problem was on our side, in [the part of the service that failed], and the fix went live [today / this morning]. You do not need to do anything. [The thing that was broken] should work now; if you had the page open, a refresh will pick it up. Sorry for the trouble, and thank you for letting me know. Reports like yours are how these get caught. [Your name]
Fix done, shipping in the next release

Subject: Update on [short description of the problem]

Hi [Name], A quick update: I have found and fixed the cause of [the problem]. The fix will ship in [version number], which I expect to release [this week / on date]. Until then, [workaround, for example: restarting the app after changing the setting] avoids it. I will write again the day the update is out, so you do not have to keep checking. [Your name]
Resolved with a workaround

Subject: A way around [short description of the problem]

Hi [Name], I have not been able to fix the underlying cause yet, but this gets you working again: 1. [Step one] 2. [Step two] 3. [Step three] The proper fix is on my list for [version number / the next few weeks], and I will let you know when it ships. Does that work for you for now? [Your name]
The cause was a setting on their side

Subject: Re: [their subject line]

Hi [Name], I found what was going on. [Setting or condition] was [set to X], which stops [feature] from [doing Y]. It is an easy one to miss, and honestly the app should make it clearer. Changing [setting] to [value] fixes it. [Optional: I have also added a clearer message for this in the next version, so it will not catch anyone else.] Let me know if it is still misbehaving after that. [Your name]
Resolved after a long wait

Subject: Finally fixed: [short description of the problem]

Hi [Name], You reported [the problem] on [date], and I owe you both a fix and an apology for how long it took. The fix is in [version number], out today. [One sentence on why it took time, if it is true and useful, for example: it only happened on one version of macOS, and it took a while to reproduce.] Thank you for your patience. If it is still not right after updating, reply here and it goes to the top of my list. [Your name]
The short version, for a quick fix

Subject: Re: [their subject line]

Hi [Name], Fixed in [version number], out now. Thanks for flagging it. [Your name]

Subject lines that get opened

The best subject line is usually no new subject at all: replying in the thread keeps “Re: their own words” at the top, and people open replies to things they wrote. When you do need a fresh one, put the outcome first.

  • Fixed: [short description of the problem]
  • Re: [their original subject line] (keeps it in the same thread)
  • Update on [short description of the problem]
  • Good news about [the problem you reported]
  • [Product] [version number] fixes the bug you reported

What makes one of these land

  • The outcome comes first. “This is fixed” in the opening line, before any explanation. Someone reading on a phone may read nothing else.
  • Say what they have to do. Update, refresh, change a setting, or nothing at all. A fix they do not know how to get is not a fix yet, from where they sit.
  • Name the version. “Fixed in 2.4.1” answers the follow-up question before it is asked, and lets them check.
  • Credit the report. People who report bugs are doing you a favour. Saying so is true, and it is what makes them report the next one.
  • Leave the door open. One line inviting a reply if it is still wrong turns a closed ticket into a conversation they are glad to continue.

Why this email so often never gets sent

Nobody forgets how to write “it is fixed.” What gets forgotten is that someone is waiting to hear it. The report came in on Monday, you replied, archived the thread and went to work. The fix shipped on Thursday. By then the conversation is in the archive next to every conversation that genuinely ended, and nothing about it says a customer is still owed a reply.

That gap has a name in how Moorline models support: the work is handled, the customer has not been told. It is the state no mail client can show you, and it is where customers quietly give up. How to never forget to reply to a customer covers the model in full, with or without software.

Questions people ask

When should I send an issue resolved email?

The day the fix reaches the customer, not the day you merge it. If they have to install an update, send it once the update is actually available to them. If the fix is on your server, send it once it is live. Sending it early means a second "sorry, not quite yet" email; sending it late means they found out on their own, or never did.

Should I explain what caused the problem?

One sentence, if it helps them. "It only happened when the file name had an emoji in it" is useful because it tells them whether they are safe. A paragraph about your code is not. The customer wants to know three things: it is fixed, what they need to do, and whether it will happen again.

Should I reply in the original thread or start a new email?

Reply in the original thread whenever you can. It carries the history, so the customer sees their own report under your answer and does not have to remember what they asked. A new email with a fresh subject is right only when the original conversation is months old or went through a different channel.

What if the fix does not work for them?

Ask for exactly what you need to tell the difference: the version they are on, and whether the steps that caused it before still cause it now. Most "still broken" replies turn out to be an update that has not been installed yet, so ask for the version first, politely, before digging in.

Is it worth asking for a review in the same email?

Usually not. The email lands well because it is about them, and a request tacked on the end turns it into an email about you. If the fix made someone happy, they tend to say so in their reply, and that is the moment to ask.