Ticket Workflow

Statuses

Mandatory fields at logging

Requester and organisation · channel · product or campaign · category · description of the actual behaviour and the expected behaviour · steps to reproduce or the exact time of occurrence · impact (who and how many are affected) · attachments or screenshots · priority (proposed by requester, confirmed at triage).

A ticket without impact stated cannot be prioritised correctly, so triage asks for it before assigning priority.

Flow

1. Log — automatic acknowledgement with ticket ID and expected first response.
2. Triage — within the first-response SLA: validate, categorise, set priority, assign owner. Priority is set by impact, not by the volume of the requester's frustration.
3. Investigate — reproduce, diagnose, document findings in the ticket.
4. Communicate — update at the frequency the priority requires, whether or not there is progress. "No update yet, next update by 4pm" is a valid update.
5. Resolve — deliver the fix, state what was done and what caused it, confirm with the requester.
6. Close — on client confirmation, or automatically after the stated no-response window with notice.
7. Post-incident review — mandatory for every P1 and every repeat P2. Output: cause, timeline, fix, prevention, owner, date.

Hygiene rules

• One issue per ticket. A ticket containing five problems will have four of them forgotten.
• Never close a ticket to protect an SLA number. This is the most common form of support dishonesty and it is treated as a conduct matter.
• Reopened tickets retain their original ID and are tracked as a quality signal.
• Every ticket has exactly one accountable owner at all times, including overnight and over weekends on 24×7 accounts.

Reporting

Weekly and monthly: volume by category and priority, first-response and resolution SLA attainment, reopen rate, ageing, top recurring categories, and the actions taken on the top three.