Almost every team that uses QA checklists handles the first pass and ignores the second. Rework is exactly where defects escape, and it is exactly when the checklist is least useful. Here is the fix.
The gap nobody designs for
Most teams that use QA checklists attach them when work is created. Someone ticks the boxes, the work ships, everyone moves on. That part is well understood.
What almost nobody handles is what happens when the work comes back. A client asks for a change, the ticket reopens, someone makes the edit, and it ships again. The checklist still shows every box ticked from the first pass. Nothing prompts anyone to re-verify, because as far as the system is concerned this work already passed.
So the second version gets less scrutiny than the first, which is precisely backwards. The first version was built carefully with the brief fresh. The second is a quick edit under time pressure, and it is the one that goes out unchecked.
Defects escape during rework far more often than during original work, and rework is exactly when the checklist is at its least useful.
What I built
Two behaviours. Checklists attach automatically when a ticket is created, chosen by work type. And when a ticket moves back into an active state from a completed one, the checklist clears itself, so the second pass has to be verified like the first.
The second behaviour is the unusual one. In several years of looking at how other teams run delivery, I have rarely seen it implemented.
How to build it
1. Derive the checklist from real escapes, not from best practice
Go back through the last twenty things a client sent back, or that broke after delivery. Each recurring cause becomes one checklist item. A list built this way is short and every item has a story behind it, which is why people respect it.
2. Make every item pass or fail
"Check the quality" is not a checklist item, it is a wish. "All links resolve", "client name spelled as in the contract", "exported at the agreed dimensions" are checkable in seconds by someone who did not do the work.
3. Keep it under ten items
Length is the enemy. A twenty-seven item list gets ticked without being read, which is worse than no list because it manufactures false confidence. If you need twenty-seven checks, you need several short lists by work type.
4. Attach on creation, by work type
A rule on ticket creation that looks at the issue type or component and attaches the matching list. Design work, copy work and development work should not share a checklist.
5. Reset on reopen, and this is the important one
A rule that fires on transition from a done status back to an active one, clears the checked state, and posts a short comment saying why. The comment matters: without it people think the system lost their work.
6. Block the transition to done while items are unchecked
Optional, and worth it once the list has earned trust. Introduce it after the reset behaviour has been running for a month, not on day one.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Jira + ScriptRunner or a checklist app | Per-user pricing on top of Jira seats. Checklist apps in the Atlassian marketplace are typically a few dollars per user per month. | Purpose-built, and the reset behaviour usually needs scripting even with a checklist app installed. |
| Jira native automation | Included, but capped at 100 rule executions a month on Free and 1,700 pooled on Standard. | Enough for attach-on-create in a small team. Add reset-on-reopen and you are running two rules per ticket lifecycle. |
| Asana, ClickUp, Monday native rules | Included in paid tiers. | Attach-on-create is straightforward. Clearing checked subtasks on reopen often needs the API rather than the visual rule builder. |
| Apps Script or a small service against the API | Free to run. | Full control over the reset logic. You maintain it, and you need somewhere for it to run on a trigger. |
What it is actually worth
I have no independent study to point at for this specific practice, and I am not going to manufacture one.
What I can tell you is the mechanism, which you can verify against your own history. Pull your last twenty client-reported issues and mark which ones occurred on a first delivery and which on a revision. If a meaningful share sit in the second column, this automation addresses them directly, and you now have a baseline to measure against.
The general context is worth knowing. Service businesses lose margin to rework in a way that rarely appears in reporting, because the hours are worked and simply not billed. Service Performance Insight's 2025 benchmark of professional services firms found billable utilization fell to 68.9 percent, the lowest in five years, with EBITDA dropping from 15.4 to 9.8 percent year on year. Rework is one of the quieter contributors to that gap, and unlike most of the others it is addressable by a rule.
How it breaks
The list grows. Someone adds an item after every incident and within a year it is unusable. Cap it. Adding an item should mean removing one, unless the new one is genuinely load-bearing.
The reset feels like punishment. If people experience the cleared checklist as the system doubting them, adoption dies. The comment explaining why matters, and so does saying out loud that the reset exists because rework is where defects escape, not because anyone is suspected of cutting corners.
It becomes theatre. If nothing ever fails a check, either your work is flawless or nobody is actually looking. Sample a few completed checklists a month and verify one item independently.
How to tell whether it worked
Track defects found before delivery against defects reported by clients, and specifically the share of client-reported issues that occurred on a revision rather than an original. That second number is the one this automation is aimed at, and it should fall.