What AI changed before, during, and after my team ever touches a ticket, and what we are still figuring out.
By Chris Green, Atlassian Community Champion, CSX Masters
For most of my career in support and services, every ticket started the same way. Empty.
A client would write in to say they could not log in. That was often all we had. One line. From there, an analyst somewhere across our desks in the US, the UK, or India would begin the routine we all know. Ask the basic questions. Search for similar tickets. Hunt down the right internal documentation. Work out the first troubleshooting step, then the second. Every ticket was a blank page, and every analyst filled it in by hand.
That is the part of the job AI changed first. Not the answer. The starting point.
I want to be honest about one thing before I go further. None of what follows works if the operation underneath it is a mess. AI does not fix a support desk that has no structure, no knowledge discipline, and no clear ownership. It amplifies whatever is already there, for better or worse. We happen to run on a single Jira Service Management environment and a shared operating model across all three regions, and that structure is the reason any of the rest is possible. I will take it as a given here rather than argue it, because it is a piece on its own.
Before a ticket reaches a human
Not every request becomes a ticket, and that is the first change worth naming. Before anything reaches an analyst, a client can work with our virtual service agent and our knowledge content to find an answer or complete a guided interaction. When that resolves the question, it never lands on a person's queue at all.
When an issue does need a human, our goal is a simple one. It should arrive with more context than it used to.
Some of that is routing. A ticket now reaches the right team based on product, department, workload, and regional availability, rather than waiting for someone to read it and pass it along. Some of it is classification. A Rovo agent reads the incoming ticket and sets the subcategory based on the product the client selected. It also assigns what we call a CS challenge rating, a one to three complexity score defined on an internal Confluence page, which then shapes how we treat and route the work.
The part analysts notice most is the context itself. For a login or access issue that once arrived as a single line, an analyst now opens the ticket to an internal comment, generated with Rovo, that summarizes what the client reported, points to similar past tickets, surfaces the relevant documentation, names subject matter contacts who may have seen the issue before, flags patterns, and suggests a first action along with any SLA risk.
None of that means the suggested answer is correct. It means the analyst begins with a hypothesis and some real context, instead of an empty search box.
That is the blank page, gone.
During the work
If I had to point to where AI earns its keep today, it is here, in the middle of a ticket.
It summarizes long histories. It surfaces similar issues and pulls knowledge from across our Jira and Confluence spaces, and from client information we hold in SharePoint. It suggests deeper troubleshooting steps. It drafts client responses. It takes fragmented notes and turns them into something an analyst can work from.
The example I come back to is the long running ticket that has moved between analysts, regions, and teams, and has aged past the point we are comfortable with. Without AI, the next person to pick it up has to read weeks of comments just to learn what has been tried, what our product or third-line teams have already said, and what the next action should be. A good summary cuts that orientation time down sharply. The analyst still verifies it against the ticket. But they are reviewing a structured summary instead of reconstructing the whole story by hand.
The same holds when we prepare a client update. AI is very good at a first draft from technical notes. The analyst then makes it accurate, and I mean genuinely accurate, not copied and pasted, and worded appropriately for that particular client.
The distinction we hold to is that AI is a co-pilot, not an autopilot. A human stays responsible for anything that touches compliance, production changes, client commitments, or an escalation decision. AI can identify a plausible troubleshooting step without understanding a client's specific version or configuration. It can make a workaround sound like a confirmed root cause, and those are two very different things. An experienced analyst catches that. They know when a suggestion is too generic, when a change needs formal approval, and when what looks like a technical problem is really a compliance or business process question.
That judgment matters most at the moment of escalation. When we move a ticket to our third-line, product, infrastructure, or professional services teams, we hand over a thorough definition of ready: replication steps, everything we have tested, and whether we have already checked for a related bug. AI helps assemble that evidence. It does not make the accountability decision for us.
After the ticket closes
This is the part I care about most, and historically it is where support has been weakest. Too much knowledge evaporates when a ticket closes. The solution sits in the comments, and unless someone finds the time to turn it into something structured, the next analyst with a similar problem solves it again from scratch.
We have started to close that gap. An automation now captures root cause and solution information as a ticket is resolved. We use AI to spot where knowledge is missing, by looking at ticket volume, repeated questions, what clients search for, where self-service failed, and which issues keep coming back to an analyst. Much of that points straight back to our virtual service agent.
The goal is a loop. A client issue becomes a resolution. The resolution becomes governed knowledge, after a person has reviewed and approved it. That knowledge then helps resolve, or prevent, the next issue. What used to live in one analyst's head, or vanish into a closed ticket, has a far better chance of becoming something the whole team can use.
What it did to the job
It would be easy to assume the point of all this is to close more tickets. Closing more tickets matters, but only if we are capturing root causes accurately and using that data to make better decisions with our product team.
Closing more tickets is not the goal I set for my team.
What I want is for analysts to spend less time searching, summarizing, categorizing, and reconstructing history, and more time understanding the client's real problem, testing the right solution, communicating clearly, and coordinating across teams. Those are the parts of support where human judgment, empathy, and accountability matter most. Those are the parts I do not want to automate away.
I will be honest about how my analysts feel about this, because it is mixed. We have run sessions on Rovo and on using AI well in daily work. Some people saw the value right away and folded the tools into how they work. Others were more cautious, usually because they had seen AI give a generic or wrong answer, and needed practice learning how to steer it. Some worried it would dull their expertise, or that it was there to replace part of their role. That fear is real, and it is the story AI in support has carried across the wider industry.
What we keep coming back to is that the analyst owns the outcome. Trust tends to grow the first time someone watches these tools save them fifteen or twenty minutes on a real ticket. Not a demo. Their ticket.
What we are still figuring out
I would not be telling the truth if I made this sound solved. Plenty still goes wrong.
AI can be overconfident. It can give advice that is broadly right but wrong for a particular client, product version, or configuration. It can miss a small but important detail buried in a long comment history. It can produce a polished, confident response that makes an uncertain conclusion sound definitive. That last one is the dangerous one in support. A well written long answer is still a wrong answer.
So we have not handed over autonomous control. Human review stays around client facing responses, knowledge publication, escalation decisions, and anything that can affect production. In those places the question is not whether the wording is good. It is whether the decision is correct, traceable, and properly authorized.
Auditability is becoming a bigger question the more agents, automations, and integrations we add. If an AI assisted action causes a problem six weeks later, can we reconstruct what happened. Who initiated it, which identity or automation carried it out, what information it relied on, and what changed. AI governance without an audit story is incomplete governance.
Measuring the value honestly is its own challenge. We recently looked at a year of virtual service agent metrics. In July, the agent resolved 112 interactions while our client support team took in a little over 1,400 created tickets. That is a meaningful contribution. But I will not dress it up as a deflection rate, because dividing one number by the other would be misleading. Not every ticket was ever eligible for the agent. The honest measure needs the right denominator, and it needs to account for whether the issue stayed resolved and whether the client had a good experience. Usage on its own does not prove value.
Adoption is unfinished too. We can provide the tools, the training, and the client facing guidance, but making usage consistent without turning it into a box checking exercise is hard. So is helping the team know when to trust an answer, when to challenge it, and when not to reach for AI at all.
There is a longer term piece we are still building, where a resolved ticket is drafted into a knowledge article by AI and then reviewed by a person before it is published, without creating duplicates along the way. We are not there yet.
The biggest question I have not fully answered is where the line should sit between assistance and action.
Where the line sits
Today, I am comfortable with AI removing the blank page. I am comfortable with it finding, summarizing, suggesting, and drafting. The harder question is when, or whether, we let it make more consequential decisions on our behalf.
That line will move. As the technology, the governance around it, and our ability to audit it improve, we will trust it with more. But client trust has to stay more important than the speed of our own adoption. If those ever trade places, we have the order backwards.
So here is where I have landed, at least for now. The blank page is gone. Human ownership is not.
If you are working through the same questions on your own desk, I would like to compare notes. That is a good part of what we do in the CSX Masters community, and the conversation is better with more practitioners in it.
About the author
Chris Green is Associate Director of Global Support Services at StarCompliance, an Atlassian Community Champion, and a leader of the CSX Masters community. He leads client support teams across the US, the UK, and India.
