ONE ISSUE. ONE USEFUL TICKET.
Turning repeated reboot deferrals into a single actionable service-desk ticket.
Simplified workflow illustration · no live systems connected
THE PROBLEM.
Pending reboots need user involvement, but repeated alerts can create duplicate tickets. The service desk needs the history and a clear next action.
MY ROLE.
I worked across Automate and Manage to improve the connection between device state, user prompts, tracking fields and ticket creation.
HOW IT WORKED.
Ask the user
Detect a pending reboot and prompt the logged-in user, recording deferrals in EDFs.
Escalate once
Use the deferral count and ticket-created state to raise one actionable ticket after repeated postponements.
Close the loop
Recognise an actual reboot and reset tracking so stale state does not affect the next cycle.
MAKE IT TRUSTWORTHY.
The important paths are repeated deferrals, an existing ticket and a genuine reboot. They need to be checked together: a working prompt is not enough if the tracking never resets or every subsequent check opens another ticket.
Controls that matter
- Persistent deferral tracking
- Ticket-created state
- Duplicate-ticket prevention
- Reset after an actual reboot
- Useful context for the service desk
WHY IT MATTERS.
Engineers receive a ticket when intervention is useful, with the history needed to act. Tracking state connects monitoring to the service desk instead of simply forwarding every alert.
ESCALATE THE PROBLEM. NOT EVERY POLL.
In-house AI gateway
GOT SOMETHING
WORTH AUTOMATING?
Tell me where your RMM is creating work.
Let’s look at what could run better —
and how to get there.