Known issues

A known issue is a problem your team knows about and is working on — an outage, a bug, a slow export. While it is open, any ticket about it, on any channel, gets the issue’s status message instead of a guessed answer, is linked to the issue, and stays open. When you mark the issue resolved, every linked customer gets the “it’s fixed” message automatically.

Create a known issue

1. 1
   Describe it

   Dashboard → Known issues → New known issue. A title, what customers should be told the problem is, severity, product area and — if you have one — a workaround and an expected fix date (ETA).
2. 2
   Teach it how customers describe it

   Add a few example phrasings (“my export never finishes”, “CSV download spins forever”) and keywords or error codes (ERR_EXPORT_504). Optionally limit it to one ticket category.
3. 3
   Check the messages

   TR-AI drafts one message per stage in your brand voice: investigating, identified, fix in progress, monitoring, resolved, won’t fix, and “fixed on <date>”. Edit any of them; placeholders like {workaround_block} and {eta_block} fill in the workaround and ETA.
4. 4
   Test it

   Paste a real ticket into “Test a ticket text” to see its match score and whether it would get the known-issue reply.
5. 5
   Find customers who already wrote

   Click “Find affected tickets”: TR-AI lists recent tickets that look affected. Untick any that aren’t, then approve — each one gets the current status message once.

What happens to a matching ticket

• The customer gets the stage message + workaround + “we’ll update you automatically”, in their language and your brand voice, with your usual greeting and signature.
• The ticket is not solved: Zendesk tickets are set to Pending and Freshdesk tickets to Pending; other help desks are left open. Zendesk and Freshdesk tickets are tagged tr_ai_known_issue and tr_ai_known_issue_<id>.
• The ticket is linked to the issue (shown under Affected tickets). If the customer writes again before the fix, they get the current status.
• If the ticket also asks something else, TR-AI answers that part as usual and adds the known-issue notice. If that part needs a person, the ticket stays open for your team with an internal note.
• Known-issue notices are sent even in assisted (review) mode, because you wrote and approved their text. Combined answers follow your normal review rules.
• Answers to known-issue tickets are never stored in the answer cache, and appear in logs with the outcome “known issue”.

Stages and updates

Move the issue through investigating → identified → fix in progress → monitoring → resolved (or won’t fix). For each change you choose whether linked customers get that stage’s message. Resolved and won’t fix always send the final message to every linked customer — once each, about 25 per minute per issue, retried with back-off if a help desk is down. Every change is kept in the timeline.

After resolution an issue either stops matching, or (the default) keeps matching for 7 days with “we fixed this on <date>, please try again”, so late reporters get the right answer.

Auto-detected suggestions (Bronze and Growth Pro)

TR-AI suggests known issues from ticket spikes and from groups of similar recent tickets it couldn’t answer (sooner when the AI analyst reports more failed answers). Suggestions are never published by themselves: accepting one creates the issue with matching off so you can check it first.

Status page, API and integrations

• Tick “Show on public status feed” to list an issue at /api/widget/<widget key>/known-issues (customer-safe fields only) for your status page.
• Public API: GET/POST /v1/known-issues and GET/PATCH /v1/known-issues/{id} (read / write scopes); PATCH with status resolved updates every affected customer.
• Webhook events known_issue.created, known_issue.updated and known_issue.resolved (custom connectors), and the MCP tool list_known_issues.
• Incident notices from Proactive messages were moved here automatically, with matching off.