Trigger: any customer question, bug report or request. Owner: Jonny Allum. Policy anchors: POL-02, POL-08.
1. Channels and response targets
Support arrives by email (the address given at onboarding) and, for managed clients, the agreed direct channel. Targets (working hours, UK):
| Class | First response | Resolution target |
|---|---|---|
| P1 — tenant cannot operate (login broken, data wrong, money broken) | 4 hours | Same day; escalate to SOP-05 |
| P2 — module/automation broken with workaround | 1 working day | 3 working days |
| P3 — question, how-to, cosmetic, feature request | 2 working days | Best effort; feature requests → kanban |
A "how do I…" answer should link the relevant section of docs/GETTING_STARTED.md — and if the doc doesn't answer it, the doc gets improved, which is the permanent fix.
2. Working inside a tenant's workspace
- Only with the tenant's knowledge, for the stated purpose (POL-03 §3).
- Prefer reproducing in a demo workspace over touching their data.
- Any direct data fix follows SOP-04's logged-support-action rule: the request, the SQL, before/after captured in the ticket.
- Never move data between tenants; never screenshot real data into replies.
3. Data subject requests arriving via support
Route per POL-02 §4: identity check, controller-vs-processor split, one calendar month clock. Log receipt date immediately — the clock runs from receipt, not from when you get to it.
4. Ticket record
Every issue gets a row (in the CRM or the support tracker): reporter, tenant, class, received, first-responded, resolved, and cause tag (bug / data / docs / how-to / billing). Monthly, scan the cause tags — three tickets with the same tag is a product defect, not a support pattern (file it on the kanban).
5. Tone
Plain English, no blame, no jargon, honest about timelines. Small-business owners are the audience — the product's promise is that it makes their compliance life easier, and support is where that promise is tested.