Manage support tickets

Some requests can't be closed out in one reply. A ticket tracks a request until it's actually done, with a stage the customer can follow and a status your team can customize.

Two axes, not one

Every ticket has two independent labels:

• Status: the name and color your team defines, like "Investigating" or "Waiting on customer." Statuses are yours to create, rename, recolor, and delete.
• Stage: a fixed, customer-facing progress label: Received, In progress, Awaiting your reply, or Resolved. You can relabel the stage text, but you can't add a fifth stage or remove one of the four.

Each status maps to one stage (or to none, which hides the stage badge). This is what lets you run as many internal statuses as your process needs while customers see one consistent four-step progress bar.

Every status also rolls up to a category (Open, Pending, or Closed), a fixed, reportable bucket that groups statuses for dashboards and workflow conditions, independent of which stage it maps to.

Configure all of this at Admin → Settings → Ticket statuses & stages.

Tip:
Relabel the four stages to match your voice ("We're on it" instead of "In progress"), but keep them short. They're the only ticket language most customers ever see.

Worked example

Quackback ships with these default statuses, which show how category and stage work together:

Notice that two open statuses ("Investigating" and "Escalated") both map to the same "In progress" stage. Internally your team can distinguish them; externally the customer sees progress continuing.

Note:
You can't delete the default status or the last remaining status in a category. Every category needs at least one status mapped to it, and every workspace needs a starting default.

Ticket ↔ conversation linking

A ticket can link to one or more conversations, and a conversation can have at most one linked customer-facing ticket. This keeps the "one open request per conversation" rule intact while still letting a tracker or back-office ticket span several conversations.

Create a ticket from a conversation

Click Create ticket in the conversation header, or press c while a conversation is open. The dialog creates a customer ticket, fixes the requester to the conversation's visitor, and links the new ticket back to the conversation automatically. A system message in the thread records that the ticket was created, and the linked ticket shows as a card in the conversation panel from then on.

Link tickets to issue trackers

When a bug report becomes engineering work, link the ticket to the issue that tracks it. The linked issue keeps the support thread and the engineering tracker pointing at the same work, and status changes flow back automatically.

In the ticket detail panel, each connected tracker shows its own section:

• Link existing issue: paste an issue URL (or a shorthand like owner/repo#123 for GitHub or PROJ-42 for Jira). Available for GitHub, Jira, and Azure DevOps.
• Create new issue: create the issue on the tracker directly from the ticket. The issue gets the ticket's title, the first customer message as its body, and a link back to the ticket. Available for GitHub, Jira, Linear, and Azure DevOps.

Internal notes never reach the external tracker. Only the first customer-visible message is used for the issue body.

When the linked issue changes status

Two things happen when the tracker reports a status change on a linked issue:

1. A team-only note lands on the ticket thread ("GitHub issue acme/app#412 was closed"), and agents watching the ticket get a Linked issue updates notification. This fires even when no status mapping applies, so an issue closing never goes unnoticed.
2. If the integration's ticket status mappings map the new external status to one of your ticket statuses, the ticket moves there too, firing the same stage updates and notifications as an agent-driven change.

Configure ticket status mappings in each integration's settings page (GitHub, Jira, Linear, Azure DevOps, ClickUp, Asana, and Shortcut).

What customers see

Customers never see your internal status name or color. The portal shows only the stage: Received, In progress, Awaiting your reply, or Resolved. If a status has no stage mapped, tickets in that status show no stage badge to the requester.

Next steps

• Configure ticket types: customer, back-office, and tracker intake forms
• GitHub integration: issue linking, creation, and status sync in detail
• Work the support inbox: filter and triage tickets alongside conversations
• Set SLA policies: apply time-to-close targets
• Get help from support: the end-user view of a ticket's progress