Triage IT helpdesk requests and fix the routine ones
Requests from Slack, email and the portal are classified, matched to the user and device, and either resolved by a scripted fix such as a password reset or routed to the right technician with context. For small IT teams buried in repeat requests.
Function: IT · Industry: Any industry
Triage IT helpdesk requests and fix the routine ones
6 steps
At a glance
- Trigger
- An employee submits a request or reports a problem.
- Typical inputs
- Requests and chat messages
- User, device and asset records
- Runbooks and known-error articles
- Approved self-service actions
- Systems it usually connects to
- Jira Service Management
- ServiceNow
- Slack
- Okta
- How the work splits
3 rules, 2 model, 1 person steps
How it runs, step by step
6 steps, each tagged by what does the work. Rules are fixed logic, a model reads or drafts, and a person decides.
- Rules Fixed logic in code
- Model AI reads or drafts, with a confidence score
- Person A named person decides
- 1
Classify the request
ModelA model identifies the category, urgency and affected system, and asks one clarifying question when needed.
- 2
Add user and device context
RulesThe user's role, device and recent changes are attached, and users with known incidents are matched to the incident.
- 3
Suggest the fix
ModelA model proposes a solution from your runbooks and past tickets, with links, for the technician or the user.
- 4
Run approved self-service actions
RulesActions you have approved, such as unlocking an account or resending an invite, run with identity verification.
- 5
Resolve the rest
PersonA technician handles hardware, access exceptions and anything outside the runbooks.
- 6
Update the knowledge base
RulesResolved tickets with a new fix are listed for the owner to turn into a runbook.
Where people approve
The decisions that stay with your team, whatever the confidence score says.
- Technicians approve any change to access or configuration.
- Self-service actions are limited to the list IT signs off.
- Security-related requests always go to a person.
KPIs to track
What to measure, before and after. Targets come from your own baseline.
- 01Share of requests resolved without a technician
- 02Median time to first response
- 03Tickets reopened
- 04Runbooks created from resolved tickets
Questions about this workflow
What stops someone from social-engineering the bot into a password reset?
Self-service actions require verification through a second factor or a manager approval that you define. The assistant cannot reset a privileged account at all.
Does it work with our existing ticketing tool?
Yes. It uses the tool's API and fields, so technicians keep working where they are.
Which steps use rules, a model and a person?
Rules: add user and device context; run approved self-service actions; update the knowledge base. Model: classify the request; suggest the fix. Person: resolve the rest. Rules are fixed logic in code. A model reads or drafts and reports its confidence. A named person decides.
What do we need to start?
Typically: requests and chat messages; user, device and asset records; runbooks and known-error articles; approved self-service actions. You also need read access to Jira Service Management, ServiceNow, Slack and Okta, or the equivalents you use. A workflow audit measures your volumes and past cases first, then gives a fixed price for the build, so you can decide with real numbers.