How to Cut First-Response Time in Half on an Internal Desk

To cut first response time on an internal help desk, remove the waiting before anyone reads a request: give requests one front door, route each to the team that owns it, show every agent a queue sorted by what's due soonest, and make one person responsible for triage at any given hour. Most first-response time is a request sitting unseen, not a person working slowly — so structure, not effort, is what halves it.

First, measure it properly

You can't halve a number you don't trust. Define first response as the time from creation to the first public reply by someone other than the requester. Internal notes don't count; the requester adding details doesn't count; an automatic "we got your request" doesn't count. LetRelay stamps this with a database trigger so it can't be edited after the fact.

Then look at the distribution, not the average: median (p50) and 90th percentile (p90), per category. Your p90 is the number requesters complain about. The query is in help desk metrics that matter.

Finally, split the time into two parts if you can: time until someone opened it and time from opening to replying. In most desks the first part dominates. That's what the playbook attacks.

How to calculate first response time

first response time = first public reply by someone other than the requester - request created

A request created at 09:12 and first answered by an agent at 09:47 has a first response time of 35 minutes. Report the median and the 90th percentile of that number for each category over a month. The one decision to make up front is the clock. In wall-clock time, a request created on Friday at 17:00 and answered on Monday at 09:30 took 64 hours 30 minutes. In business hours, with a working day of 09:00 to 17:30, the same request took one hour (30 minutes on Friday, 30 on Monday). Wall-clock is simpler and harsher; business hours are fairer to the team but need a calendar per team, with holidays and time zones. Pick one, say which, and do not change it halfway through a quarter.

Step 1: One front door

Requests that arrive by direct message, email and hallway conversation are invisible to everyone except the person who received them. If that person is busy, on leave or asleep in another timezone, the request waits.

A single intake — a form or chat intake that creates a request — makes every request visible to the whole team the moment it exists. It's the single biggest structural change, and it costs nothing. When someone messages a request directly, file it for them with a link, and reply there. People switch when they see it's faster.

Step 2: Route to the owning team at intake

A request that lands in a general inbox waits twice: once for someone to notice it, again for the right team to receive it. Route at the front door instead:

• Let the requester pick the team (with plain names: "Laptop or account problem → IT").
• Optionally, suggest a category from the words they type, and let a human confirm.
• Track reassignments. A category that's reassigned often has a routing problem.

The trade-offs are in how to route requests to the right team.

Step 3: A queue sorted by deadline, not by arrival

A first-in-first-out list makes everyone scan. Give each category a first-response target and sort the queue by the nearest deadline, with a visible "due soon" band. The next thing to do is always at the top. How to store and compute the deadline is in the SLA tracking guide.

Step 4: A triage rotation

"Everyone watches the queue" means nobody does. Assign one person per shift (or per half-day) as triage owner. Their job isn't to solve everything — it's to make sure every new request gets:

1. A human acknowledgement with a real next step ("I'll check your access group; expect an answer by 3 pm").
2. The right category and priority.
3. An owner.

Rotate daily so it doesn't burn one person out. For a team spread across timezones, hand triage over with the sun so there's always someone awake.

Step 5: Replies that move things forward

A good first response is not "we're looking into it". It either solves the problem, asks the one question needed to solve it, or sets an honest expectation. Keep short templates for the most common categories — access, equipment, password — that ask for exactly the information you'll need, so the second exchange is the fix.

LetRelay's assistant can draft a first reply from the request text and relevant knowledge-base articles, but an agent sends it. A drafted reply saves typing; a human reading the request is what makes the response real.

Step 6: Answer the repeat questions before they're asked

Look at your last month of requests. A large share is usually the same handful of questions. Write each answer once in a knowledge base and show matching articles while someone is typing a new request. Every request that doesn't need filing reduces the queue that everything else waits in. See ticket deflection with a self-service knowledge base.

Step 7: Notifications that reach the right person once

A new request should notify the team's triage owner, not the whole company channel. A request approaching its first-response deadline should notify the triage owner again, then the team lead. More notifications don't make faster responses; they make muted channels.

What to expect

When requests move from scattered channels to one visible, routed queue with a triage owner, the "time until someone opened it" part shrinks sharply because the request is now visible to someone whose job is to look. We don't publish a universal percentage — your baseline decides that — but measure p50 and p90 for four weeks before and after each step, and you'll see which step did the work.

Across timezones

Distributed teams have a structural first-response problem: a request filed at 6 pm in one office lands while the owning team sleeps. Three things help:

• Follow-the-sun triage. If the team spans regions, hand the triage role over at the end of each region's day, with a two-line note on anything in flight.
• Show deadlines in the viewer's timezone. "Due 14:00" means nothing unless it's the reader's 14:00. LetRelay stores every timestamp in UTC and renders it in each viewer's zone, so the requester in California and the agent in Kathmandu read the same deadline correctly.
• Honest expectations at intake. If nobody on the owning team is working for the next ten hours, say so on the confirmation screen: "IT answers between 9:00 and 18:00 Kathmandu time." An expectation set up front is better than an unexplained silence.

Mistakes that make the number look better and the service worse

• Instant auto-replies counted as responses. The number drops; nothing changed for the requester.
• "Looking into it" replies to stop the clock. It meets the target and teaches requesters that a first response means nothing. A first reply should contain a next step and a time.
• Closing and reopening. Some desks restart clocks on reopen; that hides the original wait. Keep the original created time.
• Excluding "hard" categories. Reporting only on the categories you do well in isn't a first-response time; it's a highlight reel.
• Targets without capacity. If arrivals exceed what the team can acknowledge, faster triage just moves the queue. Show volume next to response time so the staffing conversation can happen.

A four-week plan

Week	Change	Measure
1	Turn on timestamps, no targets shown	Baseline p50/p90 per category
2	One front door + team routing	Reassignment count, p90
3	Deadline-sorted queue + triage rotation	p50/p90, share answered within target
4	Templates + top five knowledge-base articles	Volume of repeat questions, p90

FAQ

What is a good first-response time for internal requests?

It depends on the request type. Set targets from your own measured 80th–90th percentile, shorter for anything that stops someone working. An acknowledgement within a working hour is a common goal for blocking issues.

Does an automatic acknowledgement count as a first response?

No. An auto-reply confirms receipt but tells the requester nothing new. Count only the first public reply from a person other than the requester.

Should first-response time be tracked per agent?

Track it per team and category. Per-agent numbers encourage cherry-picking easy requests and don't account for who took the hard ones.

Can AI reduce first-response time?

It can draft replies and suggest categories so triage is faster, but the structural changes — one intake, routing, a sorted queue and a triage owner — matter more. And the desk must keep working when the AI doesn't; see AI that degrades gracefully.

How do you calculate first response time?

Subtract the time the request was created from the time of the first public reply by someone other than the requester, so a request created at 09:12 and first answered at 09:47 has a first response time of 35 minutes. Report the median and 90th percentile per category. Decide whether the clock runs in wall-clock time or business hours, and state which; the same Friday-evening request can be 64 hours or one hour depending on the choice.

Sources

• Google SRE Book — Service Level Objectives
• Nielsen Norman Group — Response times: the 3 important limits
• Atlassian — Knowledge management