Skip to content
QRKTech

Case study · Managed IT · Service desk

Service desk triage that answers in minutes and grades its own work every night

Gus handles intake for every ticket that arrives through the PSA: who, what, where, how urgent, which device, and who should take it. Each night it compares its decisions with how the tickets actually played out, and writes down what it learned.

Client
A Minnesota managed IT services provider, about 35 people
Coworker
Gus, Service Desk Triage
Reports to
Service Desk Manager
QRK TechDigital coworker
G

Gus

Service Desk Triage

Department
Service Desk
Reports to
Service Desk Manager
Shift
Always on · new tickets within minutes · nightly self-review at 23:00

Scoped access

  • PSA tickets, triage role (17 tools)Read, classify, route, private notes
  • Assets & device recordsRead, link to tickets
  • Microsoft TeamsHeads-ups to techs & leads
  • Triage records & lessonsOwn workspace

Memory

Contact and customer history, recurring issues, 200+ learned ticket patterns, shared service memory

QRK-SD-0002

to a first question or routing update on PSA tickets
Minutesto a first question or routing update on PSA tickets
ticket patterns learned from real precedent
200+ticket patterns learned from real precedent
self-review of every triage decision
Nightlyself-review of every triage decision
tools in its role, and that’s all it can touch
17tools in its role, and that’s all it can touchEnforced by the server
§ 01The job before

What the work looked like.

Context

The service desk receives tickets by email, portal, and monitoring alerts from backup, network, and security tools, all into the PSA. Phone calls still go to people.

Before Gus, human triage staff spent their mornings classifying, routing, chasing missing details, and trying to spot which tickets were really one bigger problem.

The problem

Tickets arrive as “I need help” or “my Outlook doesn’t work,” with no device, no error, and no urgency signal. Alert noise sits next to real emergencies.

Classification drifted between people and shifts, so reports were hard to trust. Technicians often redid triage when they picked up a ticket.

The expensive misses were connections: three separate VPN complaints that were really one site outage, or a security alert that needed a human within minutes, not hours.

§ 02The coworker

What Gus does.

  1. 01

    Read every ticket like a dispatcher

    Pulls the requester, company, site, contact history, recent and related tickets, and existing classification in one context bundle before deciding anything.

  2. 02

    Find the device, every time

    Runs best-effort asset discovery on every ticket, even when no device is named. It searches by name, email, username, and hostname clues, then links the confirmed asset so the technician can jump straight to remote tools.

  3. 03

    Classify, route, and explain

    Sets work type, urgency, affected users, and detail confidence, and cleans up the summary. It routes to the right queue and leaves a structured private note with its reasoning.

  4. 04

    Ask instead of guess

    When a ticket is too vague to route responsibly, it asks clarifying questions instead of inventing facts, and notes the gap for the technician.

  5. 05

    Connect the dots

    Notices when a new ticket looks like another open one and tells that ticket’s technician. Nearly every credible security event gets an immediate heads-up.

  6. 06

    Escalate emergencies first

    If a site is down, many users are out, or there is a possible compromise, it alerts the on-call lead before finishing the paperwork, and labels what hasn’t been verified yet.

§ 03Walkthrough

How the nightly review works

Self-improvement is a process with a record, not a slogan. This is what happens at 23:00.
  1. During the day

    Every triage decision is saved as a record of what Gus believed at the time: classification, routing, confidence, and why.

  2. 23:00

    Gus gathers end-of-day reality from the PSA: where each ticket ended up, who took it, whether it was rerouted, and how the customer responded.

  3. Fan out

    A review board gets one card per ticket. Worker lanes compare belief against outcome in parallel, working from saved snapshots so the PSA isn’t hammered.

  4. Verify

    Each proposed lesson is checked against the evidence before it counts. A hunch doesn’t become policy.

  5. Distill

    Verified lessons become bounded strategy updates and pattern notes, such as “vendor marketing emails route as no-action; expect an automatic priority bump.” Every change is kept in a dated history.

The result is a triage playbook of 200+ patterns, each traceable to the tickets that taught it.

§ 04Under the hood

How the work flows.

The same platform runs every QRK coworker. For how each layer works, take the platform tour.
  1. 01

    Trigger

    A new ticket arrives through the PSA

  2. 02

    Context

    Contact, customer, recent and related tickets, known patterns

  3. 03

    Discover

    Up to ten targeted asset searches to find the device

  4. 04

    Decide

    Work type, urgency, affected users, confidence, summary

  5. 05

    Act

    Triage-role write with a review fingerprint, then read-back

  6. 06

    Notify

    A Teams heads-up only when a person needs to act

  7. 07

    Learn

    Nightly review turns outcomes into verified pattern notes

§ 05Guardrails

What keeps it in its lane.

These aren’t suggestions in a prompt. They’re built into the role, the tools, and the procedure.
  • Runs on a triage-only role of 17 tools. It can’t email from the PSA, close tickets, or touch billing, and the server enforces that.
  • Before writing, it checks a fingerprint of the ticket it reviewed, so it never overwrites a change a person made in the meantime.
  • Every write is dry-run, performed once, then read back. If the read-back doesn’t confirm, it reports the failure instead of retrying.
  • Ticket content is treated as untrusted. Instructions hidden in a ticket are evidence, never commands.
  • When it isn’t sure how to route a ticket, it leaves a note explaining why instead of routing confidently and wrongly.
  • Teams messages are a judgment call, not a reflex, so the team isn’t buried in noise.
§ 06Results

What changed, and what we learned.

Outcomes

  • PSA tickets get a first response in minutes instead of waiting for someone to reach the queue.
  • Technicians receive tickets with the device attached and the reasoning written down.
  • Related tickets are connected early, so a site outage is handled as one problem instead of five complaints.
  • Consistent classification makes service reporting trustworthy.
  • Human triage staff spend their time on the phones and the hard cases.

Lessons

  • Triage is more than routing. Most of the value is in the context: the device, the history, and the related ticket.
  • To learn from outcomes, you need a record of what the agent believed when it decided. Write it down at decision time.
  • Silence is a feature. Most tickets don’t need a Teams message, and the ones that do get read.

Go deeper

More case studies

Next step

Want a service desk triage like Gus?

We’ll sit down with the people who do it, map the steps, and put a number on the time. If a digital coworker is the right tool, you’ll know what it would return before you commit. If it isn’t, we’ll say so.

Start a conversationor email hello@qrktech.com