If you run a small SaaS on your own, you are also the support desk. The email that costs the most time is never the first bug report. It's the second one: "Still broken after the update."

I build Maildoer, an email assistant, and that two-word "still broken" is the kind of message I think about most: it only makes sense next to the earlier thread. Here is the support-reply habit I'd use with or without any tool.

Why "still broken" is expensive

Read on its own, "still broken" makes you start from zero:

  • Which browser and version were they on?
  • Which workaround did you already suggest, and did they try it?
  • Was it the export failing, or the export producing a wrong file?
  • Did you promise a fix "in the next release", and is this that release?

Ask any of those again and the customer hears "you didn't read my last email". They're right.

The "known so far" block

Open every follow-up reply with a short block that restates the case, then answer the new message underneath it:

Known so far - Problem: CSV export downloads an empty file (reported 3 Nov) - Setup: Firefox on Windows, team plan, 2 users - Tried: clearing cache (no change), Chrome (works) - Promised: fix in the next release; this is that release What's new in your email - Still empty after updating Next step - One question or one action, not five

Three rules make it work:

  1. Restate, don't re-ask. Anything the customer already told you goes in "Known so far", not in a question.
  2. Own the promise. If you said "next release", say plainly whether this release was supposed to fix it.
  3. One next step. A single question or a single action. A list of five diagnostics reads like you're stalling.

A two-email example (labelled hypothetical)

Say the first email reports an empty CSV export in Firefox, mentions Chrome works, and your reply suggests clearing the cache and promises a fix in the next release. A week later, after you ship, the customer writes: "Still broken after the update."

A useful reply says: you're on Firefox, Chrome still works, the cache clear didn't help, and this release was meant to fix exactly this, so here's the one thing I need: the file size of the download. None of that is in the second email. It's only in both emails together.

That's the part Maildoer is built for. When the same person emails it again, it reads the new message together with their earlier emails, so "still broken" is understood against what was already reported and promised, and the reply draft can carry the "known so far" facts forward. You still review and send it.

Pitfalls

  • Pasting a generic troubleshooting macro into a thread that already has history.
  • Closing the original ticket on release day without checking with the reporter.
  • Splitting one customer's case across two threads and losing the workaround they tried.
  • Answering only the newest email when it says "same as before".

A quick checklist before you hit send

  • [ ] "Known so far" lists setup, symptoms, what was tried, what was promised
  • [ ] No question asks for something already answered
  • [ ] The promise is addressed directly
  • [ ] Exactly one next step

If you want to try it on a real thread, forward the emails and what you need back to do@maildoer.com. Every address gets 100 credits on first use as a trial allowance. Details at maildoer.com.