Ce contenu n’est pas encore disponible dans votre langue.
Escalation Levels
Level | Who Handles It | Examples |
|---|---|---|
L1 — First Response | Support staff, using Known Issues / Troubleshooting by Module | "How do I print a duplicate receipt?", common how-to questions |
L2 — Technical Escalation | Dev (or a more senior support person with technical access) | Bug reports, anything requiring DB/log inspection, RLS-related access oddities |
L3 — Incident | Whoever's on point per Incident Response | Outages, suspected data leaks, anything matching SEV1/SEV2 criteria |
Flow
Ticket comes in (via Support Inbox — see Architecture & Infrastructure )
L1: check Known Issues and Troubleshooting by Module first — many tickets are already documented
If unresolved or clearly technical: escalate to L2
If it looks like it's affecting more than one customer, or matches any SEV1/SEV2 criteria: escalate immediately to L3 (see Incident Response ), in parallel with continuing to communicate with the customer
Once resolved: close the ticket, and if it's new/likely to recur, add it to Known Issues or the relevant Troubleshooting page
For incidents (L3) or otherwise significant tickets: write a Ticket Postmortem
When to Escalate to Incident Response
Don't wait to "be sure" — if a ticket could plausibly be SEV1 or SEV2 (see Incident Response decision tree), escalate immediately rather than spending time confirming it alone first.
SLA Notes
_(Document actual response/resolution time targets here once defined — e.g. per package tier, since Enterprise/Chain customers may have a different SLA than Starter.)_