Welcome to Agentic Ticket Triage thatreads a ticket written in whatever words the sender had.
The helpdesk queue is two queues wearing one number. Risely resolves the tickets a rule can decide, sends the rest to the specialist who owns the system, and attaches what it already worked out.
Ticket queue · this morning
6 waiting
Password reset · a student
waitinglocked out the night before a quiz
Canvas access · an adjunct
waitingteaching two sections next term
Wi-Fi certificate renewal
waitinga managed laptop, standard profile
Lab printers offline · science center
waitingall six report the same failure
Grade upload failing · a professor
waitingthe roster file will not take
Software request outside the role
waitinga licensed suite the role does not cover
0
decided by policy
0
sent to a specialist
0
waiting on a person
Half the queue follows a rule that can be checked.
A reset, a course access, a certificate renewal. Risely's agents check each one against the record and the role rules, act when both agree, and write the rule that decided it onto the ticket.
Resolved by policy
checking the rule
Password reset · a student
4 minidentity verified against the record
Canvas access · an adjunct
6 minthe next term's roster grants it by role
Wi-Fi certificate renewal
2 minthe standard profile goes to the device
A resolution the rule cannot justify never happens, so the security review reads a decision instead of a favour.
The hard ticket arrives with the work already started.
Six printers down is one sentence from a user and four questions for an engineer. Risely's agents answer the four before the ticket moves, so the specialist opens it at the cause.
Lab printers offline
working the ticket
All six printers report the same failure
Every one of them sits behind one switch
The switch stopped answering an hour ago
The rack and port map is attached
Networking queue
The engineer opens the ticket at the cause rather than at the symptom.
Six tickets about one outage are one incident.
Separate reports of the same failure look like volume until something matches them. Risely's agents group them, widen the scope as more arrive, and update everyone who filed from the one record.
Three tickets, one cause
matching
VPN keeps dropping · a faculty member
Cannot reach the file share · an office
Remote desktop times out · a lab
One incident now carries the scope
Everyone who filed gets the same update, and the queue count stops lying about the size of the problem.
What no rule covers waits for a person.
Risely's agents gather the request, the role, and what the policy actually says, then stop. The technician who owns the system answers, and the answer becomes the rule the next ticket meets.
Waiting on a person
nothing moves until this yes
A licensed suite outside the role
the role rules do not cover it
An exception to the device standard
a research need, with the case attached
Risely's agents gather the case and stop. The technician who owns the system decides, and the answer becomes the rule next time.
One thing moves. The queue re-runs.
Another ticket on the same failure, a switch that comes back, a policy the director changed on Friday. Any of them changes the queue, and every one runs the same way.
A seventh printer ticket lands
same building, twenty minutes later
Risely matches it to the open incident
one incident, never seven tickets
The scope widens to the floor
the rooms behind that switch join it
The priority recomputes
the outage outranks the queue behind it
Networking sees one page
with every affected room on it
What changes, and how it runs.
The routine half closes on its own
Every resolution carries the rule that justified it.
Specialists start at the cause
The ticket reaches them with the diagnosis on it.
One outage stops looking like a flood
Scattered reports land on a single incident.
The technical read
Connects read-only to your ticketing system, directory, and SIS to start
A technician approves anything the rules do not cover
Every action lands on an append-only log
Runs alongside what you have. Nothing rips out.