Support Model
Support is tiered, business-hours, and driven by known-issue runbooks — not a 24/7 pager. At ~18 people, a pager rotation is a promise we can’t keep, so we don’t make it.
Escalation tiers
Section titled “Escalation tiers”flowchart LR Client["Client<br/>primary contact"] --> L1["L1 — Technical Support<br/>Nidal Mohammad"] L1 --> L2["L2 — Team Lead"] L2 --> Dev["Original developer"] L1 -.expedite.-> Board["Bug on the board"]
The SLA
Section titled “The SLA”- Business-hours only. We respond and work within our working hours, per the support retainer. No overnight on-call.
- One primary contact per client on our side (usually L1), and one named contact on theirs. Requests come through that channel, not to individual developers’ DMs.
- Severity sets response, not a clock we can’t honor. A down production system is worked immediately during business hours; a cosmetic issue is queued.
What each tier does
Section titled “What each tier does”| Tier | Who | Job |
|---|---|---|
| L1 | Technical Support (Nidal) | Triage, reproduce, check known-issue runbooks, resolve or route. |
| L2 | Team Lead | Deeper diagnosis, own the fix flow, advise the PM on effort. |
| L3 | Original developer | Code-level fix when it needs the person who built it. |
From report to bug on the board
Section titled “From report to bug on the board”L1 triages every report. A known issue is closed from its runbook. A genuine defect becomes a bug work item and enters the flow board through the expedite lane — it doesn’t wait for a sprint boundary. A new request or change is not a bug; it’s routed as billable — see Warranty Boundary.