Skip to content

article

Handling a Ticket End to End

A complete playbook for taking a single ticket from intake through triage, routing, resolution, and satisfaction — with the right status and SLA moves at each step.

The full lifecycle

This workflow ties together everything in StretchSupport into one continuous playbook: how a single ticket travels from the moment it arrives to the moment the customer rates it. Follow it and every ticket gets a consistent, auditable path.

Step 1 — Intake

A ticket enters your board one of two ways:

  • Directly — you or a teammate click Create ticket and fill in the subject and message.
  • From a form — a support-tagged submission appears under Support intake, and you convert it into a ticket (see Connecting StretchForms and support intake).

Either way the ticket starts in status New, with defaults (priority Normal, severity Standard, category general) you'll refine in triage.

Step 2 — Triage

  1. Open the ticket and move it to Triage.
  2. Read the message and set the real priority — remember this sets the SLA target (Urgent 4h / High 8h / Normal 24h / Low 72h).
  3. Set severity if the impact is above routine (Elevated or Critical).
  4. Set a category so it's findable later.
  5. If Triage assist is enabled, paste the message and use its recommended category, priority, and sentiment as a second opinion.

Step 3 — Route

  1. Route the ticket to the correct queue — Account & Access, StretchLearn Support, Platform Operations, or Client Success.
  2. Routing stamps the queue's owner team and default priority automatically.
  3. Assign an individual owner if one person should drive it.
  4. The thread records a ticket_routed event so the handoff is auditable.

Step 4 — First response

  1. Move the status to Open.
  2. Reply with the Acknowledge and investigate macro, personalized with the customer's name and the specific issue.
  3. Sending this before the SLA window closes protects your target — the radar rewards a fast first touch.

Step 5 — Work the ticket

  • Need something from the customer? Reply (the Request missing details macro helps) and set Waiting on Customer.
  • Blocked on another team? Set Waiting Internal and post an internal note.
  • Keep an eye on the SLA radar — if the ticket moves to Watch or High, prioritize it; if it Breaches, escalate.

Step 6 — Resolve

  1. Apply the fix or deliver the answer.
  2. Reply with the Resolution confirmation macro.
  3. Move the status to Resolved. This stops the SLA timer (the radar marks it Met).
  4. If an article answered it, link that knowledge-base article to the ticket.

Step 7 — Confirm and rate

  1. When the customer confirms, move the status to Closed.
  2. Invite the customer to submit a CSAT rating (1–5) with an optional comment.
  3. Review low scores and reopen the ticket (back to Open) if the resolution wasn't complete.

A realistic example

A form submission titled "Report export is blank" lands in Support intake. You convert it to a ticket (New), open it, move to Triage, and set Priority: High, Severity: Elevated, Category: reporting. You route it to Platform Operations, assign yourself, move to Open, and send Acknowledge and investigate. You reproduce the bug, need a detail, so you send Request missing details and set Waiting on Customer. They reply; you ship a fix, send Resolution confirmation, move to Resolved, and link the "Exporting reports" KB article. The customer confirms — you set Closed — and rates the experience 5.

Tips

  • Keep status and reality in lockstep at every step; the board is only trustworthy if statuses are honest.
  • Route in Triage so the ticket picks up the right team and priority before real work starts.
  • Send the first-response macro early — a fast acknowledgment is the single biggest SLA protector.
  • Always finish the loop: Resolved → customer confirms → Closed → CSAT. A ticket left at Resolved is a loop half-closed.

Troubleshooting

The SLA timer won't stop. Only Resolved, Closed, or Archived stops it. A ticket in Waiting on Customer is still on the clock.

I resolved too early and the customer came back. Move the status from Resolved back to Open and continue — the thread history stays intact.

A converted intake ticket lost its context. Keep the ticket linked to the originating submission during conversion so the source form data stays attached.

Was this helpful?

Help us improve this article

Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.