Customer support
Your factory ships with a customer-support department: AI support agents that receive your users’ bug reports and questions, triage them, answer from your product’s knowledge base, file real regressions as engineering work, and follow up until the ticket is closed. This page explains the ticket lifecycle you’ll see on the Customer screen.
Where tickets come from
Section titled “Where tickets come from”- Email — mail to your factory’s support address opens a ticket; replies continue the same ticket.
- The bug-report widget — errors and user reports from the Bug reporting API are grouped, de-duplicated, and triaged; user-submitted reports become support tickets.
- Connected channels — GitHub issues and Zendesk tickets, when connected.
Ticket statuses
Section titled “Ticket statuses”Every ticket moves through a defined lifecycle. The statuses you’ll see:
| Status | Meaning |
|---|---|
new | Just arrived; being screened. |
quarantined | The safety screen flagged it for human review. |
spam / dropped | Classified as spam or malicious; no reply is sent. |
triaged | Classified (intent, priority, tier) and queued for an answer. |
grounded | The agent found sufficient sources to answer from. |
insufficient | Not enough grounded material — escalated to the L2 specialist. |
drafted | A reply draft exists and is going through the QA grounding check. |
escalated | With the L2 specialist (deeper diagnosis, engineering access). |
replied | The reply went out on the ticket’s channel. |
waiting_on_customer | We answered and the ball is with your user. |
fix_in_progress | A real bug was filed to engineering; a fix is being built. When several customers report the same defect, their tickets share one engineering bug rather than filing duplicates — each reporter still gets their own updates and fix-shipped confirmation. |
fix_shipped | The fix deployed — the reporter is asked to confirm it worked. |
handed_off | The reply needs a human: it’s waiting in your handoff queue. |
resolved | Settled; in a short cooling window where a reply reopens it. |
closed | Terminal. A later reply from the customer reopens the ticket. |
reopened | The customer replied after resolution — the ticket re-enters triage. |
How tickets close
Section titled “How tickets close”Closure always records an outcome, so your metrics stay honest:
- Confirmed resolved — the customer said the answer or fix worked.
- Assumed resolved — the customer got an answer and didn’t come back.
- Routed to team — a human on your side took it over.
- Abandoned — we needed input from the customer and never heard back. Abandoned closures are not counted as resolutions in your support metrics.
What your customers hear from us
Section titled “What your customers hear from us”Support agents keep in touch on a schedule you control, and every message is a fixed template — they never invent a delivery date for a fix.
| When | What we send |
|---|---|
| Right after a ticket arrives | An acknowledgement saying when they’ll hear from us (immediately for urgent tickets, otherwise within ~15 minutes). |
| While a fix is being built | Periodic updates carrying the real state of the engineering work — hourly for urgent issues, daily for normal ones — sent even when there’s no change, because silence reads as inaction. |
| When the fix ships | “The fix shipped — did that solve it for you?”, plus a one-question satisfaction ask. Every customer who reported the same bug is told, not just the first. |
| After 2 days of silence | A friendly nudge. |
| After 4 days of silence | A second nudge that states the exact date the ticket will close. |
| After ~7 days of silence | The ticket closes as abandoned. |
| A few days after “resolved” | The ticket closes as assumed resolved. |
A reply at any point — even after closure — reopens the ticket on the same thread, with its whole history intact.
Changing the schedule
Section titled “Changing the schedule”Every window above is configurable per factory, and the whole thing can be switched off if you’d rather your team write every message. Ask your support lead, or set it through the factory’s support policy.
If we can’t send email
Section titled “If we can’t send email”If your factory has no outbound email configured, nothing is silently dropped: each message is queued in a “needs a human” list for someone on your team to send, and tickets are never auto-closed on reminders the customer never received.
Related
Section titled “Related”- Bug reporting API — the SDK and widgets that feed the queue.
- Billing — support agent work meters like any other agent work.