There's a useful distinction in a recent study we conducted on the State of AI in Employee Support that deserves more attention. Among the reported benefits of AI, 52% cited faster first-response times, while 32% cited reduced ticket volume. Getting back to an employee quickly and having less work left in the queue are two different outcomes.
As an IT professional, you already know how this happens. The employee gets an answer in seconds, but you're still the one checking their access and opening the admin console. They know somebody has received their request; they're still waiting for somebody to do something about it.
I believe this is where the conversation about AI ticketing systems needs to spend more time. If you're looking at one for your team, you need to understand which parts of the request it can actually complete and which parts will still land with you.
So let's break down how these systems work, why automation gets stuck, and how to get a useful first request running.
What is an AI ticketing system?
An AI ticketing system uses AI to understand incoming requests and help resolve them. That might mean finding the right answer in your documentation, sending a ticket to the right team, or taking an approved action in a connected system.
The difficulty is that all of these capabilities fit under the same label, so a tool that summarizes tickets for your agents can call itself AI help desk software alongside a system that provisions application access. Look at what happens after the employee sends the message.
Take a request for a software license. The system needs to work out which application the employee means, check what they're eligible for, and get approval if the policy requires it. Once that's done, it needs a way to grant the access and check that the change went through.
If it stops after telling the employee how to request a license, the remaining steps still belong to your team. That can be useful assistance, but you'll want to know exactly where that handoff happens before you buy it.
Why does automation stop after the first reply?
The most common AI uses in Ravenna's report include answering employee questions, guiding troubleshooting, and creating or maintaining knowledge content. Plenty of requests can be resolved with information you already have.
The trouble starts when answering the question requires changing something. Your documentation might explain who can request a tool, but the system also needs to know who this particular employee is and what access they already have. Then it needs permission to make the change.
You've probably seen how much of this context lives with the person handling the queue. You know which manager to ask, which group grants the right access, and which application still needs somebody to provision it manually. The ticket itself might contain none of that.
Why I bring this up is that connecting an AI agent to your help desk doesn't automatically give it the information you use to finish a request. You have to make those rules available, connect the relevant systems, and decide what should happen when the information is missing.
How does this look in practice?
Let's use a standard application request, with manager approval required. An employee asks for access in Slack, and the agent identifies the application and the person making the request. It then checks the access policy to see what that person can ask for.
In Ravenna, this is handled through Applications, Access Levels, Access Policies, and Approval Templates. Those settings describe the available permissions and the conditions for granting them, including who needs to approve and how long access should last. The software access guide walks through the setup.
Once the request is approved, the configured provisioning method determines what happens next. A group assignment can automate the grant through your identity provider, while a tool that needs manual setup still creates work for your team. That's worth checking application by application.
For the employee, the important thing is knowing whether they can get back to work. For IT, it's knowing what changed and having enough information to investigate if it didn't work. The approval is one part of that process, and a request shouldn't disappear from the queue just because it came through.
And there's still a human decision in this example: the manager approved it. You can remove the manual work around that decision without calling the request fully autonomous. Keep those outcomes separate when you measure the rollout, otherwise you end up arguing about the number instead of understanding the improvement.
What should you automate first?
Pick a request your team handles repeatedly and already understands well. A standard application request is a useful candidate if the eligibility rules are clear and you have a supported way to provision it. Keep the first version to one app and one access level, and you'll have a much easier time seeing where the process needs work.
You don't need to make the first pilot cover every exception in your environment. You do need to know how it will handle an exception when one arrives, because employees won't limit their questions to the exact wording you tested.
Password and MFA resets rank first among the request types respondents say benefit most from AI in Ravenna's report. That's a reason to examine them, and it also means taking identity verification seriously. A common request can still give the wrong person access if you get it wrong.
The same applies to device actions. Looking up a laptop and wiping it have very different consequences, even if both start in the same support thread. The device lockout guide covers Ravenna's Jamf integration and the use of approvals around destructive actions.
Choose the approval rules for each action before you switch it on. The agent needs a defined path when it can't establish identity or confirm eligibility; guessing its way through either one should never be the fallback.
A practical way to get your first automation running
Step 1: Write down what finishing the request means
Start with the result the employee needs. For an application request, that means the right access has been granted and the employee can use it. Sending instructions or collecting approval is progress, but there is still work left to do.
Write down how you'll check that result, including what you'll look at in the connected system, and you have a test you can actually run once the automation is configured.
Step 2: Make the rules available to the system
Work through the decisions your team makes today. Who can request this access, who approves it, and does it expire? Check where the employee and manager information comes from, because an approval route is only useful if it reaches the right person.
Look for informal arrangements that haven't made it into a policy yet. If two people on your team would handle the same request differently, settle that before asking the agent to handle it consistently.
Step 3: Connect the action and its failure path
Set up the supported action that completes the request, then decide what happens if it fails. An approval might succeed while provisioning fails, and the next person needs to know that before they try again.
Keep the attempted action and its result with the ticket. When the request reaches your team, it should explain what's already happened and what still needs attention; otherwise you're back to reconstructing the conversation before you can help.
Step 4: Test the awkward requests too
Submit a request as an employee would, then follow it all the way into the connected system. Check that the right person receives the approval and that the requested permission actually appears after the action runs.
Then try someone who isn't eligible, an app the system doesn't support, a request with missing information, and a declined approval. These tests show whether the system can stop sensibly and explain the next step, which matters just as much as completing the easy request.
Step 5: Check whether your team is doing less work
Compare the same request type before and after the pilot. Look at how long it takes to resolve and how often someone has to step in, including the requests that come back because the original issue wasn't fixed.
Keep approval time visible too. If the automation provisions access immediately after approval but the request waits on a manager all afternoon, you know where to look next. Adding another automated step won't fix that particular delay.
How do you know the numbers mean anything?
Ravenna's report also found that 41% reported improved employee or end-user satisfaction from AI. That's encouraging, and it's something you should measure alongside response time. An employee can appreciate a quick answer and still be frustrated by what happens afterward.
Ask how any resolution rate is calculated before using it to judge a product. Does it cover the whole queue or just the requests selected for automation? Does a request count as resolved if the employee comes back later with the same problem?
The survey gives you context, not a forecast for your own team. It covered 526 US IT, HR, and People Operations professionals in July 2026, and the figures describe their reported experiences. Your pilot should establish what actually changes in your environment.
The best place to start is the request you already understand. Follow it from the employee's first message to the completed action, and pay attention to every point where somebody still has to intervene. That will tell you far more about an AI ticketing system than watching it answer a question in a demo.
If you'd like to work through one of those requests with us, we're happy to show you how Ravenna handles it.
Frequently Asked Questions
Can an AI ticketing system resolve requests on its own?
Yes, when it has the information and permissions needed to complete a supported request within your rules. If someone needs to approve the action, you still have a human decision in the process. You can still automate the work around that decision, and it's worth measuring how much that removes for the person handling the queue.
What should happen when the AI can't finish a ticket?
It should explain the situation to the employee and pass the request to the right person with the relevant context. Your team needs to see what was attempted and what happened, so they can continue without asking the employee to start again.
Can employees use AI ticketing through Slack?
Yes, employees can submit requests and follow progress in Slack. Check which actions the system supports behind that conversation, including whether a request can be fulfilled automatically or still needs manual work.
