Service cases
The customer-issue workspace: warranty claims, damage, repairs and complaints — each with a priority, an SLA clock, evidence, a linked order, and a clear resolution path.
🔄 Case lifecycle & the SLA clock
Every case has a priority, and the priority sets the SLA window (a due time counted from when the case opened):
| Priority | SLA to resolve |
|---|---|
| urgent | 4 hours |
| high | 24 hours |
| normal | 72 hours |
| low | 168 hours (7 days) |
Change the priority and the due time re-derives. Escalating a case raises its priority and records the escalation on the timeline.
🧭 Smart routing
The reason code routes the case to the right team automatically: a missing part → purchasing, wrong item → warehouse, site not ready / access issue → the branch manager, anything else → support.
🗂 What a case carries
- Queue filters — Open / Unassigned / Mine / Resolved.
- Evidence gallery — photos/files documenting the issue.
- Linked order (and the specific line/product) so context is one click away.
- Assignees, tags, a comment thread, the resolution path & notes.
- A CSAT rating (1–5) captured on close.
🛠 Working a case
- Triage — open the queue, set priority (which sets the SLA clock), assign an owner.
- Investigate — attach evidence, comment, link the order line and product.
- Escalate if needed — bumps priority to high (or keeps it at urgent if already there) and re-derives the SLA clock; logged on the timeline.
- Resolve — record the resolution path & notes, capture CSAT, then close.
Support, managers, installers and owners work cases. Resolving needs service.resolve; reading/commenting needs service.read / service.write.
🧾 Case field reference
| Field | Meaning |
|---|---|
| Case type | The broad bucket (e.g. warranty, damage, repair, complaint). |
| Reason code | Drives smart routing — missing_part, wrong_item, damage, site_not_ready, access_issue, defect, other. |
| Priority | low · normal · high · urgent. Sets the SLA clock. |
| Due at | Computed from opened_at + SLA(priority). Re-derived if priority changes. |
| Customer | The affected customer; clicking opens the 360. |
| Linked order / line / product | Context for the issue; one click jumps to the order. |
| Installation (optional) | Link the case back to the work order it relates to. |
| Description | What the customer reported. |
| Evidence | Photos / files attached to the case. |
| Assignee & tags | Who owns it and free-form labels for grouping. |
| Resolution path & notes | How it was resolved. |
| CSAT | Customer satisfaction (1–5) captured on close. |
| Activity timeline | Comments + structured events (priority, escalation, resolved). |
🔑 Who can do what
| Action | Roles |
|---|---|
| Open / read a case | Support, service, manager, installer, owner, admin (+ executive read-only) — service.read. |
| Comment / change priority / re-route | Support, service, manager, owner, admin — service.write. |
| Escalate | Support, manager, owner, admin. |
| Resolve / close | Support (lead), manager, owner, admin — service.resolve. |
| Open a related supplier return | Buyer / manager (when a defect ties back to a supplier). |
❓ FAQ
Tasks vs Service — which do I use?
Use a Task for internal team work; use a Service case for a customer problem that needs a priority, SLA and evidence.
Why did my case get assigned to purchasing?
Its reason code was missing part, which routes to purchasing automatically. Change the reason code if it was mis-categorised.