How to Write a Bug Report Auto-Responder

One person on your team handles support. 50 bug reports come in per day. Most are duplicates of the same three issues. The player expects a reply, and a non-reply feels like neglect — but a canned “Thank you for your report” feels worse. A smart auto-responder matches known issues, asks for the right missing info, and lets humans focus on the reports that actually need human judgment.

What Auto-Responders Are For

Auto-responders solve three problems:

1. Acknowledgment. The player knows their report was received.
2. Deflection. Known issues get a pointer to the workaround immediately.
3. Information gathering. Missing details (version, platform, repro steps) get requested before the report waits days for a human to ask.

They do not solve the underlying bug, and they do not replace human support. Think of them as a friendly receptionist: smart enough to handle routine cases, humble enough to escalate everything else.

The Known-Issues List

Build a simple data file with entries like:

[
  {
    "id": "save_corruption_v1_2_0",
    "match_patterns": [
      "save.*corrupt",
      "lost.*progress",
      "save file.*gone",
      "my save is missing"
    ],
    "title": "Save corruption after 1.2.0 update",
    "reply": "Thanks for the report. This is a known issue in 1.2.0 that we fixed in 1.2.1. Please update the game and your save should work again. If you already updated and are still seeing the issue, reply with your player ID and we'll recover your backup."
  },
  {
    "id": "mac_m1_startup_crash",
    "match_patterns": [
      "crash on startup.*mac",
      "m1.*crash",
      "won't launch.*mac",
      "apple silicon.*black screen"
    ],
    "title": "Mac M1/M2 startup crash",
    "reply": "Thanks for the report. Apple Silicon Macs need Rosetta 2 for our current build. Open the app's Get Info panel and check 'Open using Rosetta', then relaunch. We're working on a native build for the 1.3 release."
  }
]

Match patterns are regexes against the lowercased report text. Keep them simple — two to five patterns per issue is enough for most cases.

The Matcher

function matchKnownIssue(reportText, issues) {
  const text = reportText.toLowerCase();
  for (const issue of issues) {
    for (const pattern of issue.match_patterns) {
      if (new RegExp(pattern, "i").test(text)) {
        return issue;
      }
    }
  }
  return null;
}

function buildResponse(report, issues) {
  const match = matchKnownIssue(report.text, issues);
  if (match) {
    return {
      reply: match.reply,
      tagged: [match.id],
      status: "auto-responded-known-issue"
    };
  }

  // Check for missing info
  const missing = [];
  if (!report.version) missing.push("game version");
  if (!report.platform) missing.push("platform (Windows/Mac/etc.)");
  if (!report.repro_steps) missing.push("steps to reproduce the bug");

  if (missing.length > 0) {
    return {
      reply: `Thanks for the report! To help us investigate, could you share: ${missing.join(", ")}?`,
      tagged: ["needs-info"],
      status: "auto-responded-needs-info"
    };
  }

  // Generic acknowledgment
  return {
    reply: "Thanks for the report! We've logged it and a human will review within 48 hours.",
    tagged: ["triage-queue"],
    status: "auto-responded-generic"
  };
}

Run this on every incoming report. The output is a reply, a set of tags to attach to the report, and a status that helps the human triage team prioritize.

What to Never Automate

• Never close the report. Even a perfect known-issue match is still a report. The human team may want to track frequency or respond personally. Tag it, do not close it.
• Never reply in the wrong language. Detect the language from the report text and either reply in the matching language or do not reply at all. A German response to a French player feels worse than silence.
• Never promise a specific timeline. “We’ll fix this in 1.3” is a commitment you may not be able to keep. Say “we are working on it” or “this is on our roadmap.”
• Never send the same reply twice if the player responds. If they reply to your auto-response, the conversation goes to a human.

Tone and Personality

An auto-responder should feel human. Use the studio’s normal voice. Address the player by name if you have it. Use contractions. Thank them specifically for the details they provided. A template like:

Hey Alice,

Thanks for the detailed report! We saw a few others hit the same save file issue on 1.2.0 — the fix is already in 1.2.1, which should auto-update for most players. If your progress is still missing after updating, reply here with your player ID and we’ll pull a backup.

Really appreciate the screenshots too.

— The support team

...is dramatically better than “Your report has been received. Ticket #4872.”

Measuring Effectiveness

Track:

• % of reports that matched a known issue.
• % of “needs-info” replies that got a useful follow-up from the player.
• Player satisfaction with the auto-response (measure with a one-click rating link).

If the match rate is low, add more patterns to the known-issues list. If needs-info replies get ignored, make the ask more specific. Tune the responder monthly based on the data.

“Auto-responders get a bad reputation because most of them are thoughtless. A carefully-written one can handle 60% of your support load and leave players feeling better about your game.”

Related Resources

For handling specific report types, see how to handle bug reports from non-technical playtesters. For deduplication, see reducing duplicate bug reports in game development. For the triage workflow after reports arrive, see how to triage player bug reports efficiently.

Read every auto-response you send yourself before you ship it. If it feels impersonal to you, it will feel impersonal to the player.