Case studies / Establishing an AI-native product team / Tickets

Tickets from anything: product owners' ticket admin, cut by four-fifths

Once developers were building faster with AI, writing and tidying tickets became the bottleneck. I built two assistants on the team's written-down rules: one turns a recording, an email or a note into finished tickets, the other checks finished work at the end of each sprint.

One full-time person about 1,700 hours
Saved across the team about 2,000 hours
Fig. 1 Hours back in a year across 15 product owners, at about three hours a week each over 46 working weeks, next to one full-time person's working year (37.5 hours a week). One mark is 100 hours. Assumes everyone saved about the same.
Who used it
Product owners, from inside their own AI assistant
Built with
Skills that run in Claude or Cursor, reaching Jira and the wiki through Atlassian's Rovo MCP server
Reads
The shared pages of team rules, and the product documentation
Result
Ticket admin down about 80%: three hours a week for each of 15 product owners

The problem

Product owners on a complex B2B product spend a surprising share of the week on tickets. Every request, defect and idea needs writing up with the right type, owner, fields, labels and links. At the end of each sprint, finished tickets need tidying so they can be read by customers, reported on and turned into release notes.

When the developers started building faster with AI, this became the bottleneck. Work could be built faster than it could be described.

It is easy, in product management, to convince yourself that AI couldn’t possibly do your job. Most of this part of it, though, follows rules. Once those rules were written down, it could be handed over.

First, a single prompt

The first test was a plain prompt in Atlassian’s own assistant: take this meeting transcript, draft a ticket for its main action, give it the right label, assign it to the developer. It worked: on a real example, a twenty-minute write-up took five.

By hand 20 minutes
One prompt 5 minutes
Fig. 2 Writing up one piece of work after a meeting, by hand and with a single prompt in Atlassian's assistant. One mark is a minute.

But the prompt only worked because the person writing it knew which ticket type, label and project to ask for. Every product owner would need the same knowledge, and type it each time. The rules belonged somewhere every tool could read them, and the prompt belonged in a skill.

The ticket creator

The ticket creator takes a video, an audio file, an email thread or a block of text and turns it into tickets.

  • It knows the rules. It reads the shared pages to choose the ticket type, the owner and the fields, and how linked tickets should be connected.
  • It knows the product. It reads the product documentation to see what already exists, and whether something reported as a bug is in fact intended behaviour.
  • It doesn’t duplicate. It checks the backlog for an existing ticket before raising a new one.
  • It says what it doesn’t know. Anything the input didn’t settle is written into the ticket as an open question for a person.

Recording of a planning call · Into the ticket creator

“…so we'll need the new screen on the front end, and the service behind it has to be ready first. Can someone raise that before Friday?”

  1. Back-end epic · build ticketThe service, with fields filled in from the team's rulesRaised first
  2. Front-end epic · linkedThe screen, linked to the service it depends onLinked
  3. Open questionsWhat the call didn't settle, written into the ticketFor a person
Fig. 3 An illustration of the ticket creator. It spots that a request needs both a back-end and a front-end epic, raises them as the right ticket types, links them, and lists what is still unknown. Details changed.

It runs inside the product owner’s own AI assistant, so it stays a conversation. They review the draft, change what they want, and only then is it written to Jira. Running it there also means each person can adjust how they work with it, without anyone maintaining a separate app.

It works best for defects and small changes. For those, it cut ticket admin by about 80%: roughly three hours a week back for each of the team’s 15 product owners.

Like every tool in this work, it is a skill: plain written instructions that any capable assistant can follow. It reads the rules from the wiki and the tickets from Jira, and writes back to both, all through Atlassian’s Rovo MCP server. So it works the same whether a product owner uses Claude or Cursor. Nobody had to change tools to use it. How the tools fit together is in the overview.

Before about 3¾ hours
With the skill about 45 minutes
Fig. 4 Ticket admin for one product owner in a week, before and after the ticket creator. One mark is 15 minutes. Worked out from the measured saving: about 80%, or three hours a week.

The ticket checker

The checker runs when a sprint closes. It builds on a colleague’s first version in Rovo, made general by reading the shared pages instead of having the rules written into it.

  1. 1 Find Every ticket the owner finished this sprint
  2. 2 Compare Against the shared rules: release version, labels, links, a description fit for customers
  3. 3 Suggest What's missing, with a fix where it's confident
  4. 4 Approve The owner accepts, edits or rejects each one in the chat
Fig. 5 The ticket checker at the end of a sprint, started by each product owner for their own tickets.

It finds every ticket the product owner finished in the sprint, compares each one with what the rules say a finished ticket needs, and checks the description is fit for the many customers who see the product under their own brand. It suggests what to change. The product owner accepts, edits or rejects each suggestion, and only accepted changes are made.

Each product owner runs it for their own tickets, rather than one person cleaning up after everyone. The fixes are made by whoever knows the work best, and the clean-up doesn’t pile up on one desk.

What needed work

These were working tools, not finished ones.

The checker was too strict at first. It wanted to correct slightly awkward phrasing in descriptions that were perfectly clear. The fix was mostly in the shared rules, by making them less specific, rather than in the skill. That is the advantage of keeping the rules outside the tools: one edit to a page changes every assistant that reads it.

The tools also read the rules live from the wiki every time they ran, which was slow and used more tokens than it needed to.

If I built it again

Checking the rules

What I did thenThe AI checked everything, including fields a simple script could check.

What I'd do nowPlain automation checks the hard rules (release version set, label present, links in place) for free, with the same answer every time. The AI only judges what needs judgement, such as whether a description is fit for a customer.

How strict

What I did thenOne kind of feedback, so a wording quibble sat next to a missing release version.

What I'd do nowThree levels: must fix, worth fixing, ignore. Tone is raised only when a customer would notice.

Reading the rules

What I did thenFetched live from the wiki on every run.

What I'd do nowA local copy, refreshed only when a page changes. Faster, and far fewer tokens.

Testing changes

What I did thenA side-by-side test of Atlassian's own agent against the skills was planned, but the skills worked and were quick enough, so it never ran.

What I'd do nowA fixed set of past tickets with agreed right answers, rerun every time a skill or rule changes, so a change is measured before everyone gets it.

Fig. 6 If I built the ticket tools again. Left: what I did in 2026 with the tools approved at the time. Right: what I'd do today.

The first row is the one I’d change first. An AI is the wrong tool for checking that a field is filled in: a script does it for nothing and never has an off day. AI earns its cost on the judgement calls, and keeping it to those makes it cheaper, faster and less irritating to the people reading its suggestions.

What carries into your business

Most businesses have a version of this: a quote, a job sheet or an order written up after every call, in a format someone had to learn. The same approach works.

  1. Try it with a single prompt first. If that saves time, the rest is making it repeatable.
  2. Take the rules out of people’s heads and put them where the tool can read them.
  3. Let code check the facts and AI judge the words.
  4. Have the person who did the work approve the write-up, in a conversation, before anything is saved.

Got paperwork that follows a pattern?

An hour's chat costs nothing. We'll find where the quick wins are in your business.

Talk to us →