Service desk

Route the ticket on the check that failed, not the words in the email

It is 02:14 on a Tuesday. The check called disk_root on web-03 returns exit code 2. The host sits in the sql-servers group at Acme, and the machine is about to stop accepting writes. In most stacks the monitoring tool emails the service desk. The desk reads the subject line, finds the word “disk”, and drops the ticket into the Linux queue. A Linux technician picks it up at 07:30, opens the monitoring console to find out which machine it was, notices it is a database server, and reassigns it. The database team sees it at 08:10. Nearly six hours have passed and nobody has looked at the disk.

Nothing in that chain is broken. Every product did what it was sold to do. The delay comes from the seam between them, and from the fact that the only thing that crossed the seam was an email.

Why does the wrong queue get the ticket?

Because the intake rule can only see the words. When the monitor and the desk are separate products, the alert arrives as text, and a routing rule that runs on text has to guess. “Disk” in the subject goes to Linux; “SQL” goes to databases; a disk alert on a SQL server goes to whichever rule the vendor listed first. The rule does not know it is a SQL server. It cannot know, because the host group lives in a different database.

The technician who inherits the ticket then does the work the rule could not: opens the monitoring tool, finds the host, checks the group, works out who should own it. That is a person doing the joining, and it happens for every alert that crosses the seam.

What can a rule see when the desk and the monitor are one system?

Everything the monitor saw, because Guardian PSA reads the check, the host and the group from Guardian RMM directly rather than from an email the RMM sent. The conditions an intake rule can match on are these.

Subject or body contains a phraseSender address or domainMachine name matches a patternThe name of the check that failedThe host group the machine belongs toThe exit code the check returned

The first two are what every desk offers. The last four are the point. A rule that says “failing check is disk_root and host group is sql-servers” sends the ticket to the database queue with the machine already attached. Nobody re-keys the hostname. Nobody opens a second console to find out which client it belongs to.

Routed on the words in an email
Routed on the check that failed
The alert arrives as a subject line; the rule matches “disk” and guesses
The alert arrives as a record: check name, exit code, host, host group, client
The device on the ticket is a name typed by a person, or a nightly copy
The device on the ticket is the live record from Guardian RMM
A misrouted ticket waits for a technician to notice and reassign it
The host group decides the queue before anyone reads the ticket
Each vendor release can change the email format and break the rule
One release train; the rule reads fields, not formatting

What happens after the ticket lands?

The SLA clock starts against a real calendar rather than a naive one. Response and resolution targets are set per priority and measured on the hours the support group actually keeps: split shifts, public holidays and time zones, per group, or 24/7 for the teams that are. Acme is on the gold tier, so its one-hour response target applies without a second set of policies. A configurable threshold pages someone while there is still time to act, and if nobody claims the ticket, escalation reassigns it, raises the priority or moves it to another group automatically. We cover that clock in detail in SLAs on real business hours.

The technician who claims it from the database queue opens a terminal on web-03 from the ticket. The credential comes out of Guardian Vault and is injected into the session server-side; the plaintext never reaches the browser. When the disk is cleared, the resolution is published to the knowledge base from inside the ticket, as that technician, already linked to the host and the client. The history of the ticket cannot be edited afterwards; that is enforced by the database rather than by application code.

What else does the desk do?

The ordinary things, done properly. Queues with skills-based claiming. Shared mailboxes via Google Workspace or Microsoft 365, so the client’s reply lands on the ticket rather than in someone’s inbox. Canned responses, watchers and satisfaction surveys. A client portal where contacts sign in with their own identity and see their own tickets, contracts, invoices and projects, and, because the modules share a platform, the devices you look after for them, live. We wrote about deciding what a client should see separately.

What this costs you

Count the alerts that reach your desk in a week and ask how many are touched by a technician before they reach the right person. Each touch is a few minutes: open the console, find the host, check the client, reassign. A desk that handles a few hundred alerts a week can lose a working day to routing alone, and the cost is not the minutes. It is the disk alert on the database server that waited six hours in the wrong queue.

Can I keep routing on email as well?
Yes. Subject, body, sender address and domain remain conditions. The check-based conditions sit alongside them for alerts that come from Guardian RMM.
Does this work if my monitoring is a different product?
No. The check name, host group and exit code are read from Guardian RMM directly. A desk fed by another monitor’s email only has the words.

Bring your worst ticket workflow

The one that touches four systems. That is the one worth walking through together.