One hour of testing, forty-five tickets in Jira

Here's a number that had been quietly bothering me for years: on a typical UAT cycle, the ratio of time spent finding problems to time spent writing them up runs about one to three. An hour of walking a staging site with sharp eyes will surface thirty or forty things. Turning those thirty or forty things into tickets a developer can actually pick up — classified, prioritised, deduplicated, written in a shape the team trusts — used to eat the rest of the week.

Recently we ran a one-hour UAT walkthrough on a B2B storefront deep in its staging cycle. By the time the team was back at their desks, forty-five tickets were in Jira: fully written, correctly split into defects and change tasks, checked against tickets that already existed, grouped under a staging epic, ready for the developers to pull. The write-up phase — the three hours, sometimes three days, of admin that usually follows a session like that — didn't happen.

This piece is about how, because the interesting part isn't the tooling. It's that we got there by treating our own QA process like a defect: reproduce the failure, form a hypothesis, run the loop until the behaviour is right. And then — this is the part worth stealing — we froze what we learned into a skill, so the loop never has to be run again.

The problem: testing at the speed of talk, logging at the speed of type

Watch a good UAT walkthrough and you'll notice something. The testing itself is fast. Three or four people on a call, someone driving the staging site, everyone narrating: the New Products link is 404ing, that quantity field just accepted a negative number — and the letter E, wait, why is the breadcrumb in the wrong order, can we cap that at ten thousand. A defect every ninety seconds, each one described precisely, in context, at the moment of discovery, with the people who know the intent right there confirming what the behaviour should have been.

Then the call ends, and all of that precision starts to rot.

Someone — usually whoever owns QA that week — sits down with their scribbles and a memory of the call and starts typing tickets. It's slow, so it gets scheduled, so it slips. By the time ticket thirty gets written, three days have passed and "the variant selector did something weird on the second product" is all that's left of a defect that was described perfectly, out loud, on Tuesday. Tickets go in thin. Developers bounce them back with questions. The answers require re-testing the thing that was already tested. Some findings never become tickets at all, and resurface a cycle later as "didn't we already find this?"

The bottleneck of UAT was never the testing. It's the distance between saying a defect and logging it. Everything a well-formed ticket needs — the what, the where, the expected-versus-actual, the severity signal in someone's voice — exists in its richest form during the call, and the traditional process throws that away and reconstructs it later, from worse material.

The hypothesis: the call is the ticket

Which suggested a hypothesis simple enough to be suspicious: the meeting already contains the tickets. We record our walkthrough calls, and the AI meeting notes that come out the other side land in Notion with a transcript, a structured summary by area, and an action-items checklist. That's not a note about the raw material. That is the raw material — every ticket's content, captured at the moment of maximum fidelity.

So the job isn't "write the tickets after the call". The job is extraction: take one artefact, the meeting note, and transform it into another, a set of Jira tickets, without a human retyping anything in between. If that transformation could be made trustworthy, the write-up phase doesn't get faster. It stops existing.

The first attempt took ten minutes and was terrible in ways I'm glad we got to see early. We pointed Claude at a meeting note and said, more or less, "make tickets from this". It made tickets, alright. It made far too many.

The loop: every failure becomes a rule

What followed was the same refinement loop we run on ranking formulas and entitlement rules, pointed this time at our own process. Run the transformation, inspect the output against what a senior QA lead would have produced, find the disagreements, turn each disagreement into an explicit rule, run it again. Each lap took minutes. And the failures were wonderfully instructive, because every one of them was a piece of judgement we'd been applying for years without ever writing down.

The first run ticketed the process chatter. Walkthrough calls are full of project talk — "flag the QA tickets in a new epic", "tell the devs to stop checking against the old design files" — and the naive pass dutifully turned project admin into dev tickets. A human never would. Why not? Because a ticket is work on the product, and a process action is work on the project. Obvious once said aloud; nobody had ever needed to say it aloud. It became a rule: every action item lands in exactly one bucket — ticketable work, process action, or already-ticketed — and the non-ticketable buckets are still listed in the output, so nothing is dropped silently. A surfaced question is cheaper than a missed defect.

The second run called everything a bug. "Fix the category names in the master data" — bug, right? It says fix. Wrong: nothing in the codebase is defective, that's a data correction at source, a content task that flows through on the next sync. Meanwhile "tighten the spacing on the specs table" and "images rendering at zero width" both look like CSS work, and they are not the same thing at all: one is a preference, the other is broken. The rule that fell out is the one I'd now tattoo on any QA process: classify by the state of the world, not the verb in the sentence. Does correct behaviour already exist in intent, and is the implementation failing to deliver it? Defect. Does the desired behaviour not exist yet? Task. The verb is a trap.

The third run was the most dangerous, because it looked the best. Tickets came out beautifully structured — summary, steps to reproduce, expected versus actual — and some of those steps to reproduce had never happened. The call hadn't established how to trigger the defect, so the machine, helpfully, invented a plausible way. Plausible and fabricated is the worst combination in a defect report; a developer burns an hour failing to reproduce fiction. The rule: never invent what the call didn't establish. Write "TBC from QA", flag it, move on. A thin ticket is honest. A confused ticket is a defect in the defect.

And wrapped around all of it, the rule that makes the rest safe to run at speed: nothing writes to Jira until a human has seen the draft. The full set is presented as a one-screen review — every proposed ticket with its classification and priority, grouped by area, plus the flagged-existing list and the process-action list — and only after a yes does anything touch the backlog. The review takes a few minutes. It's also where the human taste lives: flip that one to a bug, merge those two, hold that one for phase 1.5.

Freezing the loop: this is what a skill is

After a handful of laps, the disagreements dried up. The transformation was producing what our best manual pass would have produced, minus the three days. Which raises the question that actually matters: how do you keep it?

Not as a prompt someone pastes from a doc, and not as a memory in one person's head — that's how the original process got slow in the first place. We froze it as a skill: a small folder of instructions that Claude loads whenever the job appears. The classification heuristics, with the tricky edge calls written out. The ticket templates for a defect versus a task. The labelling conventions that make a review's tickets findable as a set. A parser for the meeting-note format. And — the part I'd argue is most valuable — a worked example: a real walkthrough note taken end to end, every judgement call annotated, so the next run starts with the accumulated taste of every previous one.

That last file is where the feedback loop lives on. When a run produces a judgement call worth remembering — this kind of item fooled us, here's the right answer — it gets folded back into the skill. The process now accretes judgement instead of leaking it every time someone rotates off the project. Six months of QA lessons, readable in one sitting, executed in every run.

I want to be precise about what the skill is, because "AI writes our Jira tickets" is exactly the wrong summary. The skill is our QA lead's judgement, reverse-engineered into rules, with the typing removed. Every guardrail in it — never ticket process actions, never duplicate an existing ticket, never invent reproduction steps, never write to Jira before review, never touch assignee or sprint because grooming owns those — is a decision a person on our team once made, now made every time, at machine speed, without depending on that person having slept well.

What the hour actually looks like now

So here's the cycle as it runs today. The team walks the staging build for an hour, on a recorded call, testing at the speed of conversation. And knowing the transcript is the raw material changes how you narrate, in a way that costs nothing: you say the URL out loud, you say what you expected and what you got, you say "that's blocking" when it is. Testing becomes dictation. The meeting note lands in Notion before anyone's back at their desk. One sentence to Claude — ticket up this morning's walkthrough — and the skill takes it from there: parse, bucket, classify, draft, dedupe against the existing backlog, present the review. A human reads one screen, adjusts three lines, says go. The epic is created, forty-five tickets land under it, each labelled back to the session that raised it, and the summary comes back with every key linked and every non-ticketed item accounted for.

One hour of testing. Forty-five tickets: written, classified, verified, logged. The developers were pulling from the epic that afternoon, and the tickets they pulled were better than the hand-written ones used to be — richer context, honest about their unknowns, consistent in shape — because they were written from the best version of the information instead of the three-day-old version.

The real lesson isn't about QA

Step back from staging sites and quantity fields that accept the letter E, and the shape of the thing is portable.

Find the place in your process where information is at its richest, and the place where it gets retyped into another system by a tired human, and ask what's actually happening in between. Usually the answer is: judgement. A set of rules nobody has ever written down, applied by whoever owns the job, leaking away every time they hand it over. That judgement is exactly the thing you can now afford to reverse-engineer — run the loop, let the failures name the rules, and freeze the result into a skill that gets sharper with every run instead of blunter with every handover.

We didn't make ticket-writing faster. We noticed the tickets already existed, an hour before anyone would have started typing them, inside a conversation we were already recording. Most processes have a moment like that. The write-up phase is usually a confession that you threw the good version away.

Forty-five tickets an hour, and the QA lead's week back. Not bad for a meeting that was happening anyway.

AFKN builds B2B commerce platforms on commercetools and Algolia, and runs its delivery process the same way it builds software: hypothesis, loop, ship. If your team's testing is fast but the paperwork is slow, we've got a skill for that — hello@afkn.com.au