Solved in Jira, still unresolved for the customer: The SLA problem hidden between “Done” and “Confir

[#1]

A frequent point of confusion in Jira arises after a ticket is closed.

This confusion is not due to a breached SLA, missing assignee, or overloaded queue. Instead, it occurs when all indicators show success – the issue is marked Done, the SLA is met, and reports are positive – yet the customer cannot proceed.

This gap is often overlooked because Jira records progress, the team sees completion, and SLA reports indicate success. However, the customer still faces an unresolved issue.

👀 Why “Done” can be a risky SLA stop condition

In many Jira and JSM workflows, SLA timers stop when the issue reaches a final status: Resolved, Done, Closed, Completed. From a configuration point of view, this looks logical. The team worked on the request, provided a fix or answer, and moved the ticket to the end of the workflow.

However, service delivery is not always straightforward.

A developer may merge a fix, but the customer still cannot complete the workflow. A support agent may provide instructions, but the user may not understand what to do next. A QA team may confirm the bug in a test environment, while the customer still sees the issue in production.

In Jira, these scenarios may appear as “resolved.” For the customer, they are often not resolved.

This is where SLA reporting can be overly optimistic. Reports indicate targets are met, but the customer experience shows the issue persists. Over time, this leads to a disconnect: support managers see strong SLA compliance, while customers continue to escalate, reopen tickets, or create duplicates.

The team is not intentionally misrepresenting SLA performance. More often, the workflow measures the wrong finish line.

🧩 Technical resolution vs. service resolution

One of the easiest ways to understand this gap is to separate three moments that are often mixed together in Jira.

Stage	What it usually means	Risk if treated as final
Work completed	The agent, developer, or support team has done their part	The solution may not be tested in the user’s context
Issue resolved	The team believes the answer, workaround, or fix is enough	The customer may still be blocked
Resolution confirmed	The customer, requester, QA, or service owner confirms that the result works	This is harder to measure, but much closer to real service delivery

The problem starts when the SLA stops at the first or second stage, while the actual service promise belongs to the third one.

This matters especially for teams that handle product bugs, access issues, integrations, finance operations, security requests, and internal service desks. In these workflows, “we replied” and “the user can continue working” are not the same thing.

A password reset may be solved when the user successfully logs in. A bug may be solved when the customer confirms the scenario works. A data issue may be solved when the report is corrected and validated by the business owner. A workaround may restore service, but it does not always remove the root cause.

If Jira does not make this difference visible, the team may keep measuring speed while losing sight of resolution quality.

⚙️ Build a confirmation stage into the workflow

The practical fix is not to make every ticket slower. The practical fix is to stop treating Done as one universal ending for every type of work.

For many teams, a better workflow may look like this:

In Progress → Fix Provided / Answer Sent → Waiting for Customer Confirmation → Confirmed / Closed

This creates a controlled space where the team has completed the work, but the issue is not yet treated as fully confirmed. It also gives managers a much better view of what happens after the first resolution attempt.

For example, if an issue stays in Waiting for Customer Confirmation for two days, that may be normal. The customer needs time to test. But if many high-priority tickets move from this status back to In Progress, that is a signal.

Maybe agents are closing too early. Maybe the resolution comments are unclear. Maybe QA validation is missing. Maybe the product has a recurring defect that support keeps treating as separate tickets.

A simple audit query can already show the pattern:

project = SUPPORT

AND status = "Waiting for Customer Confirmation"

AND updated <= -2d

ORDER BY updated ASC

This view helps separate “work is done on our side” from “the customer confirmed the result.” It also gives Jira admins a better workflow design question: should the SLA stop when the team provides a fix, or when the fix is confirmed?

For simple requests, stopping at Fix Provided may be enough. For incidents, bugs, access blockers, and customer-impacting requests, confirmation is often a better finish line.

📊 Track reopened tickets as a quality signal

eopened tickets are often dismissed as workflow noise. For example, someone may reply to an old email thread, a customer may report the fix did not work, or a manager may question why the ticket was closed. The issue then returns to In Progress, and the team proceeds.

However, reopened tickets are clear indicators that the resolution process requires attention.

It is important to distinguish between types of ticket reopening. A “thank you” reply differs from “the issue is still broken.” A new request within an old ticket is not the same as an incomplete fix. A customer reopening a ticket after 30 days may indicate a new incident, while reopening after 30 minutes often suggests the resolution was not properly validated.

This is why it can be useful to add at least two fields to Jira:

Reopen reason
Reopen count

The reopen reason can be simple at first: incomplete fix, unclear instruction, new request, duplicate follow-up, customer not available, workaround failed, internal QA rejected.

A useful JQL view could look like this:

project = SUPPORT

AND status CHANGED FROM Done TO "In Progress" AFTER -30d

ORDER BY updated DESC

Or, if you use a custom field:

project = SUPPORT

AND "Reopen Count" > 0

AND resolved >= -30d

ORDER BY "Reopen Count" DESC

Once you have this data, the conversation changes. Instead of saying “agents should be more careful,” you can see which request types reopen most often, which priorities are affected, and whether the same components or teams appear again and again.

That is where service delivery improves. Not from blaming one person, but from seeing the repeated pattern.

🧪 Add validation rules for high-risk work types

Not every ticket requires customer confirmation. For example, if a standard access change is requested and the system confirms the permission was granted, waiting for manual confirmation may introduce unnecessary delay.

However, certain work types should not move to Done without proper validation.

Product bugs typically require QA or customer validation. Integration issues may need confirmation that data synchronization is restored. Incidents may require evidence that the affected service is stable, not just temporarily available. Security requests may need a clear audit trail before closure.

Jira workflow conditions, validators, required fields, and automation can support this process. Before moving a high-risk ticket to Done, require a resolution category, confirmation field, root cause note, QA check, or customer-facing resolution summary.

A practical rule could be:

If Request type = Bug
Then Resolution summary, Root cause, and QA validation must be completed before Done

For support teams working with dev or QA, this prevents one common problem: support closes the customer-facing issue because the development task is finished, but nobody checks whether the customer outcome is actually restored.

That small gap is where many “met SLA, unhappy customer” cases live.

⏱️ Make SLA measurement match the real promise

Before changing SLA configuration, it is important to ask a critical question:

What exactly do we promise when we say “resolution”?

For some teams, resolution means the first useful answer. For others, it means a workaround. For some enterprise customers, it means a permanent fix confirmed by the requester. For internal operations, it may mean that the employee can complete the blocked task again.

The SLA should align with that commitment.

A mature Jira setup may have more than one SLA goal for the same request type:

SLA goal	What it helps measure
Time to First Response	How quickly the team acknowledges the request
Time to Workaround	How quickly the user gets a temporary path forward
Time to Confirmed Resolution	How long it takes to reach a validated outcome
Time in Waiting for Customer	How much time depends on requester input

This is where SLA Time and Report for Jira can be useful, not as a “better timer,” but as a way to model the real workflow more accurately.

For example, instead of stopping the main SLA when the issue reaches Done, a team can configure SLA conditions around statuses and custom fields: start when the request enters support, pause while waiting for customer information, and stop only when the issue reaches Confirmed or when a custom field like: Status = Confirmed

If the customer rejects the resolution, reset or multi-cycle logic can help track the next cycle without hiding the fact that the first resolution attempt did not hold. This helps reporting stay honest: not only “was the timer green,” but “how many cycles did it take before the customer outcome was actually achieved?”

🔎 A 45-minute audit for Jira admins and support leads

A large transformation project is not required to identify this gap. Begin with a small sample.

Select 20–30 tickets from the past month where the SLA was met and the status is Done or Closed. Review what occurred after the resolution date: Did the customer reply again? Was the issue reopened? Did a related bug appear? Was there a negative CSAT comment? Did the resolution comment clearly explain the fix and next steps for the customer?

A basic audit view could be:

project = SUPPORT

AND resolved >= startOfMonth(-1)

AND resolved < startOfMonth()

AND status in (Done, Closed)

ORDER BY resolved DESC

Then create a second view for possible failed resolutions:

project = SUPPORT

AND status CHANGED FROM Done TO "In Progress" AFTER startOfMonth(-1)

ORDER BY updated DESC

When reviewing these tickets, focus on identifying patterns rather than individual errors. For example, most reopened tickets may originate from a specific request type, customers may reopen tickets due to brief resolution comments, tickets may close automatically after inactivity while the customer still needs to test, or the SLA target may be suitable for simple issues but encourage premature closure of complex ones.

This audit often reveals that while the SLA configuration may be technically correct, the workflow does not ensure the desired customer outcome.

🛠️ How this can be covered with SLA Time and Report in a real Jira setup

A practical setup in SLA Time and Report could look like this.

The team keeps a standard Time to First Response SLA that stops after the first public response. This protects the customer from being ignored and gives support managers a clear view of initial responsiveness.

Then the team adds a separate Confirmed Resolution SLA. This SLA starts when the ticket enters active support, pauses when the team is waiting for customer details, and stops only when the ticket reaches a confirmed final status or when a validation custom field is set. For bugs or incidents, the stop condition can be connected to QA validation, customer confirmation, or a more controlled workflow status.

If the issue is reopened, the SLA does not have to become a reporting mess. With reset conditions and multi-cycle tracking, teams can measure repeated resolution attempts more clearly. A reopened ticket can be treated differently depending on why it reopened: incomplete fix, new request, customer delay, or internal QA rejection.

The reporting side is just as important. In the SLA Grid Report and charts, the team can review SLA performance by assignee, priority, request type, service, or other criteria. If tickets with a specific reopen reason also show weak SLA performance, that is a real improvement area. If SLA is met but reopen rate is high, that is also a signal: the team is fast, but not accurate enough.

The goal is not to complicate Jira. The goal is to make the hidden part of service delivery visible: whether the customer actually got the result they needed. SLA Time and Report can support this by helping teams configure more accurate SLA conditions, track repeated resolution cycles, and reduce manual work in reporting.

---

Final thoughts

A green SLA report is valuable, but it should not be the sole indicator of good service. If tickets are closed quickly yet frequently reopened, the team is not improving service delivery, but merely moving work across statuses.

The real question is where your SLA should stop: Done, Confirmed, Validated, or Restored.

SLA Time and Report for Jira helps teams configure SLA conditions around these real workflow stages, track repeated resolution cycles, and see the patterns in reports.

If this sounds familiar, check what happens after your tickets move to Done. Do reopened tickets tell a different story?