Your first reply time dashboard is green. Median FRT is 14 minutes, the SLA is met on 98% of requests, and the weekly report looks great.
Meanwhile, a customer opened a request on Monday, got a polite "Thanks, we're looking into it" within ten minutes, and is still waiting on Thursday.
Both things are true at the same time. That's the problem with first reply time: it measures the moment your team touched a request, not the moment the customer's problem went away. And because that moment is so easy to produce, it's also the easiest support metric to game, often without anyone meaning to.
This article is for support leads who still report FRT as a headline number. We'll look at how it gets gamed, why the industry is moving toward resolution-based support, and what to measure instead in Jira Service Management.
Five ways first reply time gets gamed
Most of these don't start as cheating. They start as a reasonable shortcut under pressure, then quietly become the team's default.
- The holding reply. "Thanks for reaching out, we'll get back to you shortly." The SLA clock stops. The customer learns nothing new, and the real work hasn't started.
- Auto-replies counted as agent replies. A canned acknowledgment fired by automation, or a macro an agent sends without reading the request, makes FRT look instant across the whole queue.
- Cherry-picking the queue. Agents answer the easy requests first because they can reply in two minutes. The hard ones sit untouched until they are about to breach, then get a holding reply too.
- The clarifying question nobody needed. "Could you send a screenshot?" when the description already had everything. It counts as a first reply, and it moves the wait onto the customer.
- Close fast, reopen later. A request is answered and resolved in one touch, the customer replies "that didn't work," and it reopens. FRT stays perfect. The second and third waits don't show up in it at all.
None of these break a rule. Every one of them makes the report better and the customer experience worse.
Why it happens: the metric rewards the wrong moment
There's an old idea in management known as Goodhart's law: when a measure becomes a target, it stops being a good measure. FRT is a textbook case.
The metric has one stop condition: the first public reply. It doesn't ask whether that reply was useful, whether it moved the request forward, or whether the customer had to come back. So when FRT becomes the number leadership looks at every week, the team optimizes for the cheapest thing that stops the clock.
Take a team with 400 requests a month and an FRT target of 1 hour. If they hit 98%, that sounds like a near-perfect month. But if 60 of those requests reopened, and the median request took 3 days to actually resolve, the 98% tells leadership almost nothing about what customers lived through.
FRT still has a job. A customer who hears nothing for two days will assume they've been ignored, so a fast acknowledgment matters. The mistake is treating it as the outcome rather than as one guardrail on the way to the outcome.
Fast replies are becoming free. Resolutions aren't.
Support is going through a quiet shift. With virtual agents and automation, any team can now send an instant reply to every single request. When everyone can hit a one-minute FRT, a one-minute FRT stops meaning anything.
That's why more and more service teams, and the tools they use, are redefining success around resolution. A conversation that simply ends isn't resolved. A request that times out isn't resolved. A ticket closed today and reopened on Friday isn't resolved either. What counts is a problem that's solved and stays solved.
Read that list again with your human team in mind. A holding reply, a canned macro, a fast close that reopens two days later: these are exactly the things that look like success on an FRT dashboard and feel like failure to the customer.
The lesson is worth borrowing whether or not you use automation at all. If a definition of success would fall apart the moment money depended on it, it shouldn't be your headline support metric either.
What to measure instead: metrics that check each other
The fix isn't to drop FRT and pick a new favorite number. Any single metric can be gamed. What's much harder to game is a small set of metrics that pull in different directions, so improving one at the expense of another shows up immediately.
Here is a set that works for most Jira Service Management teams:
Metric | What it tells you | What it exposes when FRT is gamed |
|---|
Time to resolution | How long the customer waited for the problem to actually go away | Holding replies and cherry-picking: FRT stays fast, resolution stays slow |
Reopen rate | Share of resolved requests that came back | "Close fast, reopen later" |
First-contact resolution | Share of requests solved without back-and-forth | Unnecessary clarifying questions |
Time to next reply | How long customers wait between updates after the first reply | A fast first touch followed by silence |
SLA results by priority | Whether critical requests get the same care as easy ones | Easy requests answered first, hard ones left to breach |
Three principles make this set useful rather than just longer:
- Measure resolution end to end, not first solve. If a request reopens, the clock that matters is the one that runs until it's solved for good. A "first resolution" number can look excellent right before a wave of reopens.
- Pause the clock fairly, but don't let pauses hide work. Time spent waiting for the customer shouldn't count against the team. But if a request sits in "Waiting for customer" after a question nobody needed to ask, that's a process problem worth seeing.
- Keep FRT, demote it. First reply time becomes a guardrail with a sensible target. Resolution time and reopen rate become the numbers you report upward.
A quick way to check whether your current dashboard is gameable: ask what an agent could do in five minutes to make the numbers better without helping a single customer. If the answer is "quite a lot," the metric set needs a counterweight.
Most teams already have the raw data for this in Jira Service Management. The hard part is seeing it together. Native SLA reporting is built around one service project at a time. That works for a single desk, and gets awkward once you want resolution results by priority, by team and against a target in one view.
This is where SLA Time and Report makes life simpler. Support leads see response and resolution results side by side, across projects, instead of rebuilding the picture in a spreadsheet every Friday.
How to make the switch in Jira without rebuilding your reporting
You don't need a reporting overhaul to change what your team optimizes for. You need to change which number people see first. A practical sequence:
- Run one month in parallel. Keep your FRT report as it is and add resolution time next to it, broken down by priority. The gap between the two numbers is usually the most persuasive slide you'll ever show leadership.
- Define "resolved" in writing. Decide which status means the customer's problem is gone, and which statuses pause the clock. If your team can't agree on this in one meeting, that disagreement is the real finding.
- Track reopens explicitly. In Jira, a simple JQL filter on requests that moved from a done status back into progress is enough to start. Review the reopened requests weekly, not just the count.
- Warn before the breach, not after. Resolution goals fail quietly. An alert that fires when a request has used most of its time gives the team a chance to act while it still matters.
- Change what you report upward. Lead with resolution results by priority and reopen rate. Move FRT to a supporting line.
Where FRT misleads the most: cross-team work
A customer gets a fast first reply on the service desk. Then the request is escalated to a developer or an infrastructure team working in another Jira project. Native JSM SLAs stay with the service project, so the linked work item where the actual fix happens has no SLA clock at all. On the dashboard, the request looks handled. In reality, nobody is timing the part the customer is waiting for.
This is the gap SLA Time and Report closes best. One SLA can span several projects and teams, so the resolution clock follows the work to whoever is fixing it. The team holding the request gets warned before the goal is missed, and the support lead reports one honest number instead of a handoff gap.
Measuring resolution across teams with SLA Time and Report
Jira Service Management's built-in SLAs are a solid start for a single service desk. The limits show up as support grows: requests move between teams, SLAs need to cover more than one project, and leadership wants one honest number across all of it. That's usually the moment support leads start fighting their own setup instead of improving service.
SLA Time and Report for Jira is built for that stage. What changes for a support lead:
- The clock follows the work. One SLA can span several projects and teams, so resolution time reflects what the customer actually waited, not just the part that happened on the service desk.
- Problems surface before they become breaches. The team holding the request is warned while there's still time to act, and the channel knows the moment a goal is missed.
- Reports you don't have to rebuild. Response and resolution results by priority, team and target live in one place, so the weekly report stops being a spreadsheet exercise.
- Less configuration to maintain. Instead of duplicating SLA rules project by project, you manage them where they apply, which keeps definitions consistent as teams grow.
If first reply time is still your headline number, it's a good time to see what your resolution results really look like. SLA Time and Report is available for Jira Cloud, Data Center, Isolated Cloud, Atlassian Government Cloud, so whichever environment you’re on, your resolution numbers can finally match what customers experience.
The question worth asking your dashboard
First reply time answers "How quickly did we respond?" Customers are asking a different question: "Is my problem solved, and will it stay solved?"
Now that automation can send a fast reply to anyone, a fast reply on its own proves very little. Keep the quick acknowledgment. Just stop calling it the finish line.
If your SLAs live in Jira, SLA Time and Report makes that shift easier to sustain: resolution goals that follow work across teams, early warnings instead of post-mortems, and reports leadership can read without a spreadsheet in between.
