Triage and Response
"How we classify support requests and update clients on a schedule."
Why this exists
Without triage, everything feels urgent and nothing gets prioritized. Engineers focus on the loudest client instead of the most critical bug. We classify issues first because unclassified tasks are invisible.
Operational Flow
Receive: Log all support requests in Linear under the Support team, whether they come via email, Slack, or phone calls.
Classify: Label tickets within one hour. Priorities range from P0 (production down) to P3 (minor cosmetic issue).
Acknowledge: Respond to P0 and P1 requests within two hours with a status update, and P2/P3 requests within one business day.
Assign: Give every ticket a single owner who is responsible for updates and the final resolution message.
Update: Send progress notes on a schedule: P0 every 30 minutes, P1 every 2 hours, and P2/P3 daily.
Close: Write a brief note explaining the root cause and what you did to resolve the issue.
What good looks like
- A P0 ticket at 2am gets acknowledged within ten minutes, and updates follow every half hour until fixed.
- A P2 bug receives a workaround on the same business day and a root cause fix before the sprint ends.
- The Support board in Linear has zero unlabeled tickets at the end of the week.
What NOT to do
- Don't go silent after saying 'we're looking into it'. Communication delays read as indifference.
- Don't assign tickets to team aliases. One person must own the issue.
- Don't close a ticket with a one-word note like 'fixed'. Explain the root cause.
- Don't let low-priority bugs sit for weeks. Slow responses encourage clients to escalate everything.
The worst support incidents are caused by poor communication, not unfixable code. A client once found that their database exports had failed for three days only because they checked the files themselves. The fix took forty minutes. Repairing client trust took three months. The failure was entirely communication.
Triage is making a clear decision about where your attention goes, and sharing that decision. When you label a ticket, you name the owner and set the next update time. The client doesn’t need an immediate fix. They need to know that a developer is working on it and will update them by a specific hour. Do this consistently, and incidents stay manageable.