Help desk workflow tips to improve your IT support

Routine help desk requests, like granting software access or resetting a password, usually take only minutes to fix. The ticket, however, can stay open for hours while it waits for someone to pick it up or approve it.

Automating these requests can cut that resolution time, but first you need to set up the necessary help desk workflow. Your systems need to be connected, the AI needs reliable knowledge and triggers written the way employees ask, and approvals need to reach the right people.

The six tips below show how to put each of those pieces in place, starting with which requests to automate first.

TL;DR

• Connect the systems the workflow depends on. Your AI needs access to chat, identity, and ticketing tools, with security controls in place before it starts taking action.
• Start with frequent, repeatable requests. Access requests and password resets are good candidates, especially when automation can complete the action rather than simply provide instructions.
• Give AI reliable knowledge. Decide which sources it can use, remove conflicting or outdated information, and make sure important instructions are in a format it can interpret.
• Build workflows around real employee language. Use past requests to understand how employees describe problems, then test triggers against requests that should and shouldn't match.
• Plan approvals and escalations in advance. Define who can approve each request, where approvals happen, and what context IT receives when automation can't finish the job.
• Measure one outcome from the start. Establish a baseline, choose a metric such as auto-solve rate, and give someone responsibility for improving it.

How a help desk ticket workflow works

A help desk ticket workflow is the process a request follows from the moment an employee asks for help until the issue is resolved and the ticket is closed.

Most workflows have five stages:

1. Intake: The employee asks for help through Slack, Microsoft Teams, email, a direct message, or a help desk portal.
2. Triage: The request is categorized and prioritized based on what the employee needs and how urgent it is.
3. Routing and approvals: The request goes to the right person or automated workflow, and any approvals, such as for software access, are collected.
4. Resolution: IT resolves the issue, or automation completes the required action.
5. Closure: The outcome is recorded, and the ticket is closed in the ticketing system.

Requests often slow down between these stages, but there are practical ways to keep them moving. We’ll discuss them below.

6 tips to set up a help desk workflow that resolves requests faster

You don’t need to automate your entire help desk at once. Start with the requests that create the most repetitive work, then make sure the systems, knowledge, and processes around them can support automation. Here’s where to focus your energy.

1. Connect the basics before day one

Automation can only complete requests in the systems it can access. For most IT teams, that means connecting three: an identity provider such as Okta or Microsoft Entra, a chat tool like Slack or Microsoft Teams, and the ticketing system you already run, such as Jira Service Management or Freshservice. 

You don't need to replace your ticketing system. With two-way sync enabled, it will keep every request on record there.

Bring your security team into the process early on. Granting access or resetting a password means giving the automation permission to act on employee accounts, and at some companies, procurement, legal, and governance, risk, and compliance (GRC) review can take four to six weeks. 

Start the review while you set up the connections, and agree on:

• Which system is the source of truth for access policies, so automation follows your existing rules.
• Which actions need human approval.
• How identity is verified before a password reset goes through.
• Who can view tickets from each department, particularly sensitive HR requests.
• What the audit trail records: who asked, who approved, what changed, and when.

You don't have to enable every action at once. Some teams start by allowing the AI to answer and route requests, then give it permission to take actions in one system at a time. That gives security a staged way to review what the automation can access and do.

2. Start with access requests and password resets

Access requests and password resets come up daily and follow the same steps every time, so they're the easiest requests to automate.

The biggest gains come when the automation completes the request itself. A bot that sends password-reset instructions from the knowledge base may save IT a reply, but the employee still has to complete the reset themselves.

Access automation can have a similar problem. One IT lead we spoke to said 40 to 50% of their tickets are access requests, but only 10 to 20% of those are automated.

Part of the reason is that identity providers don't connect to every app a company uses. One ITSM manager we spoke to said Okta reaches 'maybe half' of their apps. Many apps don't support automatic provisioning, or only offer it to larger customers, so someone on the IT team has to sign into each app, manually add the person, and set their permissions.

This becomes particularly noticeable with multi-app requests. Automating access to two apps doesn't save much time if IT still has to provision the other four manually.

To fully automate access requests, so the employee can use everything they requested without IT stepping in, start by listing the apps that generate the most requests. Then check how each one can be provisioned: through your identity provider, through the app's own API, or manually.

Where there's a connection, automate the whole request: collecting the details, getting the approval, adding the person, and removing their access when it's no longer needed. 

In Risotto, for example, a request for access to Stripe runs like this:

1. An employee asks in Slack for a new teammate to get access to Stripe.
2. Risotto asks what level of access the teammate needs and for how long.
3. The manager approves the request in Slack.
4. Risotto adds the teammate to the Okta group that grants Stripe access.
5. Before the access expires, Risotto messages the teammate with an option to extend it. When the time runs out, Risotto removes the access.

Where there isn't a connection, automate what you can. For example, collecting the details and getting the approval can still happen automatically, so the person who manages the app receives a complete, approved request and only has to add the person.

Ironclad handles access requests this way and auto-solves 91% of its access-related IT requests, including requests for several apps at once and apps outside its single sign-on (SSO) that used to need an admin. Time limits on access also help the team prevent license sprawl.

The resolution-time difference can be significant, too. At Jobber, requests handled by Risotto average around three hours to resolve, compared with 35 hours for requests handled by a person.

See how Risotto handles access requests and password resets end to end in Slack or Teams. Book a demo.

3. Clean up your knowledge before you index it

If you want an AI agent to resolve Tier-1 requests without IT stepping in, it needs accurate knowledge to work from. That might include documentation in Confluence or Google Drive, previous tickets, and answers shared in Slack.

The problem is that those sources don't always agree. An old ticket might contain a workaround you no longer use, while a newer process sits in Confluence. If both are available to the AI agent, it may pull from the wrong one.

Before you connect your knowledge sources, decide which information the AI agent should be able to access and use. In particular:

• Establish which sources are authoritative. Remove or update outdated instructions and resolve conflicting information so the agent isn't choosing between different versions of the same process.
• Be selective about what gets indexed. You may not want every Slack channel, historical ticket, or document available to the AI agent. Decide which sources to include and how much history it needs. One team we spoke to, for example, chose to limit the agent to six months of Slack history rather than indexing everything.
• Check that the content is readable by the AI. Important instructions can be buried in embedded PDFs, screenshots, or other formats that are difficult for an agent to interpret. Check how your documentation is structured and move important information into a format the agent can reliably use.

Start with the articles behind your most common requests, especially the ones that still get escalated. You don't need to clean up the whole knowledge base first.

Once the AI agent is handling requests, look at the questions it still can't answer. In Risotto, the experimental Knowledge Gaps tab in Insights groups recurring unanswered questions so you can see where your documentation needs improving. You can also turn a useful answer from Slack into a knowledge article with just an emoji reaction.

Pro-tip: For more on writing articles an AI agent can use, see our guide to ITSM knowledge management.

4. Write triggers the way employees ask

Employees won't always describe a problem using the same language IT uses. One person might say their ‘Wi-Fi isn't working,’ another that ‘the internet is down,’ and another that they ‘can't connect to the network.’ All three could need the same runbook.

Write your triggers around the language employees actually use. For example, an account lockout might come through as ‘I'm locked out,’ ‘I can't log in to Entra,’ or ‘I need to reset my password.’ If the trigger only uses your team's terminology, it can miss requests the runbook should handle.

The opposite can happen too. A trigger that's too broad can send the wrong request down a workflow. One IT team we spoke to found that an ordinary Snowflake access request triggered its emergency ‘break glass’ process, which was intended for urgent, elevated access. 

The trigger had matched on ‘Snowflake’ without enough context to distinguish between the two requests. Be clear about what should and shouldn't match.

Here are a few ways to make your triggers more reliable:

• Use real requests as your starting point. Review past tickets and Slack messages to see how employees describe the issue, including any shorthand used by particular teams.
• Include what shouldn't match. Account for similar-looking requests that need a different workflow, particularly where the wrong match could trigger a sensitive action.
• Test before you publish. Try the runbook against past requests, including different ways of describing the same issue and similar requests that should not trigger it.

Risotto's no-code runbooks let you write and edit these instructions in plain English. That means the people who handle the requests, and who already know how employees describe them, can maintain the workflow themselves.

Documenting the process in the runbook also means it isn't dependent on one person's knowledge. The workflow can keep running when they're away, and other team members can review or update the instructions when needed.

5. Set escalation paths and approvals before go-live

Automation can still stall when a request needs human input. An approval might go unanswered, or an unresolved request might reach IT without enough context to continue.

Before you automate a help desk workflow, decide two things: who approves requests that need approval, and who handles requests the automation can't finish?

For approvals, think beyond simply assigning a manager. One IT team we spoke to had more than 200 access requests sitting in other teams' queues waiting for approval. Another told us that reminders weren't enough because people still ignored them.

A few changes can keep approvals moving:

• Send approvals where people already respond. If your approvers work in Slack or Microsoft Teams, let them approve requests there rather than expecting them to monitor another queue.
• Check that every approver can receive requests. Before go-live, confirm that each approver's identity-provider email matches an active Slack or Teams account, including members of approver groups.
• Give the approver enough context. Include what the employee is requesting, why they need it, and any other information required to make the decision. For access requests, consider making a business reason mandatory so approvers aren't left guessing.
• Don't let one person's absence block the request. Where your policies allow it, use an approver group or a multi-step approval chain rather than relying on one person.
• Keep employees informed while they wait. Let employees know when their request has been sent for approval so they aren't left wondering whether it's reached the right people.
• Keep a record of the decision. Log the requester, approver, outcome, and timestamp with the ticket so you have a clear audit trail.

The approver won't always be the requester's manager, either. Some requests need approval from a particular group or more than one person. For example, an access request might need IT approval first, followed by the employee's department leader. Risotto supports group- and attribute-based approvals, as well as multi-step approval chains, with each decision recorded as part of the request.

When it comes to escalations, give the IT agent the context they need to continue the investigation. An escalated ticket should include the original request, the employee's answers, and any troubleshooting already completed, so the agent doesn't have to start again.

Risotto's Assistant can also help investigate more complex requests. It can use read-only actions to gather information, propose a plan for resolving the issue, and wait for the IT agent's approval before taking the next step. 

If the same type of request keeps coming up, it can also suggest a runbook to automate it in future.

6. Pick one metric and one owner

You can't show whether automation is improving your help desk if you don't know where you started. Yet many IT teams don't have a baseline. One IT lead we spoke to put it simply: ‘I have no metrics whatsoever.’

Before you automate a workflow, choose one metric you want to improve and record where it stands today. Auto-solve rate is a good ITSM metric because it shows how many requests are resolved without an IT agent having to finish the work.

Define what counts as an auto-solve upfront. If a human has to step in to complete the request, don't count it as automated. That gives you a much clearer measure than counting requests the AI answered, routed, or partially handled.

Be clear about how you're calculating the rate, too. Auto-solved tickets divided by all tickets gives you a different result from auto-solved tickets divided by resolved tickets. Choose one calculation and use it consistently so you can track whether automation is actually improving.

You can establish your baseline using the ticket data you already have. For example, look back over the previous six months of requests to calculate your current resolution time and identify how many repeatable requests are already resolved automatically. 

Some teams also test a sample of historical tickets against the AI to see how many it could resolve without human involvement.

Then set a realistic target and give one person responsibility for it. One security company we spoke to started without an auto-solve rate, set a goal of 25%, and recorded its mean time to resolution at 88.6 minutes. The automation target was included in the team's strategy and visible to its CISO.

Your target doesn't need to be 50% from day one. What's more useful is having a number your team can consistently measure and an owner who can investigate why requests still need human intervention.

Gusto shows what having a baseline can make visible. Its team says it doubled its resolution rate on its first day with Risotto, and that rate hasn't dropped since.

From there, the owner can look at the requests that still need IT and work out what to improve next, whether that's a missing integration, a knowledge gap, an approval bottleneck, or a workflow that isn't matching the right requests.

Put the six help desk workflow tips to work

These six workflow tips all help automation do what you actually need it to do: shorten resolution times.

Risotto brings help desk and IT automation together in one system. Employees can ask for help in Slack, Microsoft Teams, or email, and Risotto can triage requests, collect approvals, and keep tickets updated. 

The automation engine can handle work such as resetting passwords, granting or removing software access, managing group membership, and revoking temporary access when it expires.

For company-specific processes, you can create runbooks that tell Risotto when an automation should run and what it should do. You don't have to build every automation from scratch, either. 

Risotto comes with prebuilt workflows for common IT requests, including Okta and Entra password resets, MFA resets in Entra, and BitLocker and FileVault recovery. You can also use the Assistant to create new runbooks, tools, and automations from a description of what you want to automate. By default, it asks for approval as it makes changes, although admins can enable auto-accept.

The result is more routine IT work completed automatically, while requests that need investigation or judgment still reach your team.