#helpdesk

##Intake

Three channels, one queue. Nobody has to learn a portal to report a broken printer.

Whatever the channel, the ticket is created with the requester, the time, the raw text and any attachments, and then enriched. Enrichment never overwrites what the person wrote.

##Classification

Every ticket gets a category, a priority and, where possible, a linked asset. Categories are deliberately few, because a taxonomy with forty branches is a taxonomy nobody uses.

• network - connectivity, wifi, VPN, slowness that follows the person rather than the machine
• device - hardware faults, performance, battery, disk, peripherals
• software - installs, crashes, updates, licence prompts
• access - passwords, permissions, shared drives, mailbox rights
• account - joiners, leavers, role changes, name changes
• other - held deliberately, and reviewed rather than hidden

The asset link is the part that does the heavy lifting. "My laptop is slow" becomes a ticket against a specific four-year-old machine with 94% disk usage and a drive reporting reallocated sectors, which is a different conversation.

##How priority is set

Priority comes from three inputs, in this order.

1. How many people are affected. One person cannot print; the whole floor cannot print. The second is not a bigger version of the first.
2. Whether work is blocked. "Cannot open the payroll file" on the 28th outranks "second monitor flickers" on any day.
3. What happened last time. If tickets in this category have historically escalated, the starting priority reflects it.

Priority is a suggestion like everything else. An operator can change it, and when they do the change is kept as a signal.

##Similar tickets

Each new ticket is compared against the closed history of your own workspace - not a generic corpus. Matching uses the text, the category, the asset involved and the user, so a repeat fault on the same machine ranks above a similar phrase on a different one.

Three repeats of the same fault on the same asset inside sixty days raises a pattern flag. That is the point at which the fix stops being a restart and starts being a replacement, and the flag exists so somebody notices.

##Suggested fixes

A suggested fix is a resolution that already worked, retrieved with the ticket it came from. It is not generated advice, which is why it can be audited.

suggested   restart AP-2
source      #2188, resolved 14 Aug by ravi.k
evidence    same asset, same symptom, 47 days quiet since
scope       one device · service restart · no data touched
runs        only after an admin approves

# declining is also recorded. The reason, if you give one,
# is what stops the same suggestion coming back next week.

###When there is no precedent

New faults get no suggestion. The ticket arrives classified, prioritised and linked to its asset, with the device state attached, and that is all. We would rather offer nothing than offer something invented - and the first resolution you write becomes the precedent for next time.

##The queue

The default order is what needs a person, soonest. Auto-sorted tickets with an accepted suggestion drop below anything waiting on a decision.

##Response timers

Each priority carries a response window. The timer measures the first human response, not resolution, because that is the promise you can actually keep.

Working hours and holidays are per workspace, so a Friday evening ticket is not breached by Monday morning. Service providers can set a different window per client org, which is what most contracts actually say.

##Limits