The ticket is the core unit of work in SysDesks. Every incident starts as a row in the queue and ends either resolved, escalated, or closed as not reproducible — and unlike a quiz, the platform does not take your word for any of those outcomes. It checks the actual simulated state of the account, device, or service the ticket concerns before it lets you close it.
The lifecycle of a ticket
- Open Tickets. The queue lists every incident available to you, with category, priority, assignment group, and an SLA countdown for both first response and resolution.
- Open a ticket and read the requester's description. It is written the way a real user would describe a problem — in their own words, not in technical terms — and the detail that points at the cause is almost always already there.
- Click Assign to me. Tickets are not shared scratch space — until you claim one, it is not yours to change.
- Review the Requester and Device panels. Who is this, what device or account is involved, and is a remote session even authorized for this kind of request.
- Work the ticket in whichever console it actually needs — see the Remote Desktop, NorthMail, Active Directory, Server Room, and Asset Management articles for what each one supports.
- Write resolution notes, choose a resolution code, and click Resolve ticket.
Resolution codes
- Solved (Permanently) — the cause is fixed and verified.
- Escalate — the work is outside your authorization, permission level, or scope, and needs to move to another team.
- Not Solved (Not Reproducible) — you genuinely could not reproduce the reported symptom.
- Closed (Cancelled by User) — the requester no longer needs the ticket worked.
Resolving is not a formality. Every ticket in SysDesks carries a set of resolution conditions defined against the actual simulated state — a service really has to be running, an account really has to be unlocked, a device's display setting really has to match what was requested. If you click Resolve before that state is actually true, the ticket tells you specifically what condition still isn't met instead of silently closing. This is also why restarting a device "to see if it fixes it" before you have diagnosed anything is graded as a guess rather than a fix — it doesn't change whether the underlying condition is met, and it destroys evidence you might have needed.
Resolution notes are graded on substance, not presence. A note that says "fixed it" will not satisfy the documentation requirement — the ticket wants to see the cause, the action you took, and how you verified it. Every resolution note you write is also auto-published to Documentation, which is how the knowledge base grows: it is built from real closed tickets, including yours.
A ticket does not simply vanish once you close it. If you closed something that was not actually fixed, or closed it with a real fault, it can come back as a reopened ticket or spawn a follow-up incident, and any points held in escrow for that closure are affected — see How Scoring Works for exactly how that mechanism works.
Every ticket carries a category, subcategory, priority, and assignment group, and each of those fields does real work rather than sitting there as flavor text. Priority combines impact and urgency into an SLA response deadline and a resolve deadline, both shown as a live countdown in the queue, so you can genuinely triage by what is closest to breaching rather than reading every row in order. Category and subcategory are what route a ticket toward the console it actually needs — an account-only request never opens a remote session, and a hardware request never authorizes a directory change, because the ticket's own classification tells the platform what kind of work this is before you've clicked into it.
Behind the scenes, what evaluates whether you're allowed to resolve a ticket is something we call the state judge: a set of resolution conditions defined for that specific incident, checked against the live simulated state of whatever the ticket concerns. This is also why some tickets can't be resolved through a single obvious action — a NorthMail incident might require correcting a setting and confirming the resolved state actually shows in the client, or a directory incident might require both fixing the account and verifying the user can sign in, because the underlying condition genuinely has more than one part to it.
Not every ticket ends in Solved. Escalate exists because some incidents are deliberately outside what a given role is authorized to do alone — a privileged group change, a security indicator, or infrastructure affecting many people at once. Choosing Escalate correctly, with notes explaining what you found and why it's out of scope, is scored as the right outcome rather than a failure to close the ticket yourself, which mirrors how a real support team actually works.