Skip to content

Support Levels (L1 / L2 / L3)

Three levels. Different responder, different resolution scope, different escalation trigger. CS does not page L3 directly — they file a JIRA bug with the full taxonomy. The chain stays clear.

Owners: CS Lead, QA, Developer Phase it lives in: After We Build (Volume V) The corpus principle this enacts: Support is a signal collection system for reality.

Where it lives in the chain

The three levels

L1 · First contact

  • Who: CS team.
  • Resolves: known questions from the CS handoff, account issues, password resets, "how do I" guidance.
  • Escalates when: the answer is not in the handoff, the ticket describes unexpected behaviour, or the user reports data that looks wrong.
  • SLA target: first response within 1 hour during business hours.

L2 · Investigation

  • Who: QA or a developer with domain context.
  • Resolves: bugs that can be reproduced, configuration issues, workarounds for known limitations.
  • Escalates when: the issue affects multiple users, involves data integrity, or requires a code change.
  • SLA target: investigation started within 4 hours, resolution or escalation within 1 business day.

L3 · Engineering

  • Who: the development team.
  • Resolves: code fixes, schema issues, integration failures. Follows the bug taxonomy and the hotfix path from Volume IV.
  • SLA target: P0 triggers incident process immediately; P1 same day; P2 enters normal backlog.

The routing rules

CS does not page L3 directly. L1 escalates to L2 with the ticket details, reproduction steps (or attempts), and impact assessment. L2 either resolves (workaround) or files a JIRA bug with the six-dimension taxonomy — including chain-aware label — and assigns to engineering.

L3 hears about L1 patterns through L2's weekly summary, not from individual L1 tickets. Direct L1→L3 pages bypass the discipline and cost engineering's focus for tickets that L2 could resolve.

What good practice looks like

A grader reports "submitting takes forever." L1 reads the CS handoff (handoff said "typical submit under 3s; if longer, check user's network"). L1 walks the user through network checks. The user reports good network, still slow. L1 escalates to L2 with notes: "User reports submit times >10s, network confirmed good, on staging build 2026-05-17."

L2 investigates, reproduces — the slow query under a specific user data shape. L2 files bug/grading-slow-submit-with-large-class, chain-aware label scenario-gap (the load test missed this data shape). L3 picks it up the next morning, fixes the query, ships the fix in the next release.

Three levels, three responses, one bug filed. Without the levels, the same ticket would have either bounced around informally for days or skipped to engineering immediately and consumed an hour for a slow-query investigation that L2 could have done.

200apps · How We Work · NWIRE