# First response time benchmark: what good actually looks like in 2026 > Realistic FRT ranges by channel, the three measurement mistakes that quietly inflate every benchmark, and how AI deflection has split the metric into two distributions most dashboards still report as one. - **Published:** July 2, 2026 - **Category:** Support - **Author:** Udit Goenka - **URL:** https://communicate.so/blog/first-response-time-benchmark --- > **TL;DR:** Live chat medians run about 90 seconds, email averages 12 hours 10 minutes across a 1,000-company SuperOffice study, and AI-handled first response now lands under 5 seconds while human escalations still take 15 to 30 minutes. Most FRT numbers are wrong because they measure business hours only, count auto-replies as responses, or blend AI and human speed into one misleading average. --- Ask ten support leaders what a good first response time is and you get ten different numbers, most of them guessed. Someone read "under a minute" on a vendor landing page once and it became gospel. Someone else is comparing their email first response time against a competitor's chat FRT and wondering why the number looks bad. Almost nobody is measuring the same thing the same way, which makes most "we're fast" claims meaningless the moment you ask a follow-up question. This is the companion piece to [cutting first response time to seconds, not hours](/blog/cut-first-response-time). That post covered how to get faster. This one covers the number itself: what counts as good by channel, why the standard ways of measuring first response time quietly lie to you, and how AI-handled replies have split the metric into two very different distributions that most dashboards still report as one. ## What first response time measures First response time is the gap between a customer's first message and the first substantive reply from your team. Not a receipt confirmation. Not an autoresponder that says "we got your message." The first reply that engages with what the customer asked, that's the real first response time. That distinction matters more than it sounds like it should, because a lot of FRT reporting quietly counts the wrong event. If your helpdesk fires an automated "we've received your ticket, someone will be with you shortly" and logs that as the first response, your FRT number looks fantastic and means nothing. The customer is still waiting. They just got a form letter telling them to keep waiting. Real first response time starts the clock when the customer sends their message and stops it when a human or an AI agent sends a reply that addresses the question, even partially. If your AI agent answers a billing question outright, that's the first response and it's also probably the last one needed. If your AI agent asks a clarifying question before it can help, that still counts, because the customer got engagement, not silence. Get this definition wrong and every benchmark comparison downstream becomes noise. ## Benchmark numbers by channel ![Comparison chart showing first response time benchmark ranges for live chat, email, social, and B2B support channels](https://communicate.so/blog/first-response-time-benchmark-frt-benchmark-by-channel.png) Numbers vary a lot depending on who ran the study, what industry mix they sampled, and whether AI is doing first-touch work. Treat everything below as a range, not a target to hit exactly, and always attribute the source when you cite a number internally so nobody mistakes house math for an industry standard. ### Live chat Live chat sets the highest bar because customers open a chat window expecting someone (or something) to be there already. According to the [Tidio Customer Service Benchmark Report](https://www.tidio.com/blog/live-chat-statistics/), the median live chat first response time across industries lands around 1 minute 35 seconds. The overall average sits closer to 2 minutes once slower outliers are folded in. SaaS companies in that sample skewed faster, averaging about 1 minute 22 seconds, while ecommerce ran a bit slower at roughly 1 minute 48 seconds. The best ecommerce brands in the same research responded in 12 to 30 seconds, which is the number people usually mean when they say "instant." A separate industry analysis found customer satisfaction peaking around 84.7% CSAT when the chat reply lands within 5 to 10 seconds of the customer's opening message. Below that window, satisfaction holds roughly steady. Above about two minutes, it starts dropping fast, because the customer has already switched tabs and stopped paying attention. Practical read: if your live chat first response time sits under 90 seconds, you're at or above median. Under 30 seconds and you're in the range customers describe as instant. Anything past 5 minutes on a channel customers chose specifically because it's supposed to be immediate will show up in your CSAT scores whether or not anyone files a complaint about it. ### Email Email is where the gap between what companies think they're doing and what they're doing gets embarrassing. A widely cited [SuperOffice study of 1,000 companies](https://www.superoffice.com/blog/response-times/) found the average email response time sits at 12 hours 10 minutes, and that's the average, not the tail. Most companies responding to a support email are making the customer wait half a day for a first reply, often longer once you exclude the fastest performers pulling the mean down. Higher-performing ecommerce teams do better, landing in a 4 to 6 hour range for first response. Cross-industry, the realistic median sits somewhere around 7 to 12 hours. Reasonable targets to hold your team to: under 2 hours for a standard support email, under 30 minutes for anything flagged priority or tied to an active outage. Queue design, not laziness, explains why email drags so far behind chat. Chat is synchronous by nature, someone has to be watching the window. Email gets triaged, sits in an inbox, and waits for whoever's turn it is to work the queue. Treat email like a batch job worked twice a day, and a 12-hour average is the predictable output of that process, not a mystery. ### Social and messaging Social support (X, Instagram DMs, Facebook Messenger) sits in an odd middle zone. Customers expect it to behave like chat, immediate, because the app feels immediate. Companies mostly treat it like email, checked periodically by whoever's on social duty that day. Recommended targets put social first response time under 60 minutes, and most customer expectation surveys back that up, with the majority of users expecting a reply within an hour on public social channels. Actual performance runs behind that expectation, with average social FRT commonly landing in the 4 to 5 hour range, well past what the channel implicitly promises. That gap, between what the medium signals and what companies deliver, is the single biggest reputational risk in social support. A public complaint sitting unanswered for four hours is a slow reply everyone else can see, not a private delay only the customer notices. ### B2B support tickets B2B support runs on different physics than consumer chat and email. Tickets often require research, cross-team routing, or account context before a meaningful first reply is possible, so B2B benchmark reports generally set FRT expectations in hours rather than minutes for anything beyond a simple question. A first response within 1 to 4 business hours reads as solid performance for B2B software support; same-day response (within 8 business hours) is the more common baseline across the market. The catch with B2B is that "business hours" as a measurement window can hide a lot of real customer pain, which brings us to the measurement problem itself. ## Why most FRT numbers are measured wrong ![Infographic illustrating three common first response time measurement mistakes and their honest corrections](https://communicate.so/blog/first-response-time-benchmark-frt-measurement-pitfalls.png) Three specific mistakes account for almost every inflated or misleading FRT claim you'll see in a deck. ### Mistake one: business-hours-only clocks Measuring FRT only during business hours excludes nights, weekends, and holidays from the calculation. It's a legitimate way to evaluate whether your staffed hours are being used well. It is not a measure of what the customer experienced. If a customer emails at 9pm Friday and your business-hours clock starts running again at 9am Monday, your dashboard might show a clean 45-minute FRT. The customer waited 60 hours. Both numbers are true. Only one of them describes reality from the customer's side. If you sell (or claim) 24/7 support, business-hours FRT is close to useless as a customer-facing metric. Keep it as an internal staffing efficiency number if you want, but report calendar-time FRT anywhere the number gets compared to customer expectations, competitor claims, or your own marketing copy. ### Mistake two: counting auto-acknowledgments as the first response Covered above, but worth repeating because it's the single most common way companies accidentally lie to themselves. "We've received your message" is not a response. It's a receipt. If your helpdesk software defaults to counting it as FRT, that default is wrong and worth fixing before you trust any number the tool reports. The tell is usually a suspiciously fast, suspiciously uniform first response time average. If every ticket shows a first response under 10 seconds regardless of complexity or time of day, you're probably measuring an autoresponder, not a human or AI engaging with the question. ### Mistake three: reporting the average instead of the distribution This is the one that does the most damage, because it looks like careful measurement while hiding the exact thing leadership needs to see. Average first response time gets dragged around by outliers in both directions. A handful of instant AI-handled replies can pull your average down to something that looks excellent, while a long tail of escalated tickets that sat for six hours barely moves the mean at all if your volume is high enough. You end up reporting "average FRT: 4 minutes" while 10% of your customers waited over four hours, and nobody in the room knows it because the average absorbed the damage. The fix is percentile reporting. Track median (p50) alongside p90, and ideally p95. A low median with a high p90 tells you something specific and actionable: most customers are fine, but a meaningful slice is getting badly underserved, usually because those tickets are the ones that need escalation, specialized knowledge, or a human who's currently busy. That's a real operational signal, and an average alone would have buried it. Report first response time per channel too, never blended. Blending chat and email FRT into one number is like averaging a sprint time with a marathon time and calling it your "running benchmark." The channels have different customer expectations and different operational realities. A blended number flatters whichever channel has more volume and hides problems in the other. ## How AI deflection reshapes the FRT distribution ![Chart showing how AI deflection splits first response time into a fast instant floor and a slower human escalation tail](https://communicate.so/blog/first-response-time-benchmark-frt-distribution-split.png) Here's where the last two or three years of support tooling changed the shape of this metric, not just the average value. Before AI-handled first response was common, FRT distributions looked roughly like a single hump: most tickets clustered somewhere around the team's typical handling speed, with a tail stretching out for hard cases. Improving FRT meant making that whole hump shift left, hiring more agents, tightening shift coverage, simplifying macros. An [AI support agent](/ai-agents) trained on your docs, help center, and PDFs answers inbound messages the instant they arrive, in parallel, regardless of volume or time of day. That's a structurally different distribution, not just a marginally faster human. The bot holds a flat sub-few-second first response for every question it's equipped to answer, and routes the rest to a human with context attached. [Freshworks' 2025 customer experience benchmark](https://www.freshworks.com/theworks/customer-experience/freshworks-20205-cx-benchmark-thriving-with-ai/) found AI-assisted first response time dropping from a previous average of over 6 hours down to under 4 minutes across the accounts studied. "AI is not just a technology shift, but a fundamental change in how customers interact with you and how your customer service agents do their work," said Venki Subramanian, Freshworks SVP of product management for customer experience. That kind of shift only comes from changing the shape of the distribution, not from making individual agents type faster. The honest way to describe what happens: your FRT distribution splits into two populations. A near-instant floor made up of every question the AI agent can answer outright from your [data sources](/data-sources), typically the majority of inbound volume for a team running mature deflection. And a human tail made up of escalations, ambiguous requests, and anything that needs judgment, account-specific context, or a policy exception. Reporting a single blended average across that split distribution is actively misleading, more so than in the pre-AI world. Say your AI handles 65% of inbound at under 5 seconds and your human team handles the remaining 35% at a median of 22 minutes. The blended average first response time will look great, something like 8 minutes, and will tell you nothing true about either population. Leadership reads "8 minutes" and assumes typical performance is 8 minutes. It isn't. Nobody's typical experience is 8 minutes, it's either instant or it's 22 minutes, and those are two completely different customer experiences that deserve two completely different lines on the dashboard. Track them separately: AI-handled first response time (should be seconds, close to flat regardless of volume) and human-escalated FRT (should be measured against realistic human-team targets, not compared against the AI floor). If your human-tail FRT is creeping up because your team assumes "the bot's got it" and deprioritizes queue monitoring, that's a real problem the blended average will hide from you for months. In short: every message routes to the AI first; questions it can answer land an instant reply logged as AI FRT, while anything needing judgment goes to a human queue. If a human is already viewing that conversation a presence lock holds it in human mode, otherwise it waits in the queue at a B2B SaaS median of 15 to 30 minutes, and either way the human reply gets logged as human FRT. ## Deflection rate: the number that explains your FRT shift Deflection rate, the share of inbound support volume an AI agent or self-service tool resolves without a human ever touching it, is the variable that decides how much of your FRT distribution sits on the instant floor versus the human tail. Real deflection numbers vary widely by company and by how aggressively the AI is scoped. Published [Forethought case data](https://forethought.ai/case-studies/forma-uses-forethought-ai) shows financial platform Forma increasing deflection from 30% to 39% over several months by refining how their AI handled routine inquiries, while [Grammarly's deflection rate jumped from 60% to 87%](https://forethought.ai/case-studies/grammarly-achieves-87-deflection-and-4-2-csat-early-with-forethought) within ten days of moving to a more agentic setup. That's a big spread, and it should make you skeptical of any vendor quoting a single flat "we deflect X%" number without context on ticket mix and knowledge base maturity. The cost angle explains why this matters beyond FRT. [Industry cost analysis](https://thestacc.com/blog/ai-customer-service-cost-savings/) puts AI-handled ticket cost in the $0.50 to $1.05 range, against $8 to $12 for a human-handled ticket, roughly a 12x to 24x difference. That gap is roughly an order of magnitude, and it's the reason deflection rate gets so much attention. Deflection is the biggest cost lever in the whole support operation, ahead of headcount planning, which is why [cost](/blog/ai-customer-support-cost) and speed tend to move together once AI is doing real first-touch work. One caution worth taking seriously: not all deflection is equal. Reports from early 2025 found a meaningful share of companies running non-agentic, script-based bots seeing flat or worsening cost-per-resolution even after "deflecting" volume, because the deflected tickets still needed human rework downstream. A ticket the bot marks resolved but the customer reopens two hours later with the same question hasn't been deflected. It's been delayed and double-handled, which is worse for FRT and CSAT than routing it to a human immediately. If you're evaluating deflection numbers, ask what happens to tickets after the bot claims resolution, not just what the initial containment percentage says. ## Why response caching matters for the AI floor The instant-floor half of your FRT distribution depends on the AI agent being fast at scale, not just fast in a demo. Response and prompt caching, keeping the model's understanding of your documentation warm rather than reprocessing it from scratch on every query, is a big part of why that instant reply stays cheap and consistent even during volume spikes. Without caching, a support spike (a product incident, a pricing change announcement, a viral mention) can push AI response latency up right when speed matters most. With it, the floor holds regardless of how many customers message at once, because the model isn't re-reading your entire knowledge base on every single request. This is a technical detail that shows up as a business outcome: teams evaluating [AI agents](/ai-agents) for support should ask specifically how the vendor handles response consistency under load, not just how fast the demo looks with one tester in the room. ## Escalation and the human tail, measured honestly ![Workflow diagram showing a customer message routing to either an instant AI reply or a human escalation queue with shared context](https://communicate.so/blog/first-response-time-benchmark-frt-workflow-ai-human-handoff.png) The human-tail half of your distribution needs its own honest benchmark, separate from whatever the AI floor is doing. Escalation happens for a specific set of reasons: the AI doesn't have the answer in its knowledge base, the question requires account-specific judgment, the customer is upset and needs a human tone, or a policy exception is on the table. Leading AI support implementations aim to keep escalation rates under roughly 15% of total volume, alongside tracking answer accuracy (targeting 85% or higher) on the tickets the AI does handle. Push escalation too low by making the AI overconfident and you get wrong answers reaching customers. Push it too high and you've built an expensive routing layer instead of a support agent. Once a ticket escalates, [Shared Inbox](/shared-inbox) design decides what happens to FRT from there. If AI and humans work the same conversation thread with full transcript visibility, the human agent picking up an escalation isn't starting cold, they're reading what the customer already told the AI and picking up the thread. That cuts effective human FRT because the agent doesn't need a clarifying round trip just to catch up. Presence-based takeover, where the conversation locks to human mode automatically the moment an agent opens it, and releases back to AI when the agent steps away, keeps that handoff from creating a gap where nobody's watching the thread. If you're benchmarking your own human-tail FRT and it's running long, check whether escalations are landing in a queue that gets checked periodically versus a shared thread that surfaces the moment a human is available. That single design choice tends to explain more variance than headcount does. For more on how the mechanism reduces the visible cost of handoffs, see [how Shared Inbox keeps AI and humans in sync](/blog/shared-inbox-ai-and-humans) and the deeper handoff mechanics in [how AI-human handoff works in support](/blog/ai-human-handoff-support). Set your human-tail target relative to what similar-sized teams in your industry hit for escalated tickets specifically, not relative to your AI floor. A reasonable working target for a small-to-mid support team is a median human FRT under 15 to 30 minutes for escalations during staffed hours, with a p90 that doesn't blow past an hour. If your escalated median is creeping toward the old pre-AI email numbers (multiple hours), the AI layer is masking a staffing or triage problem rather than solving it. ## How to benchmark your own team, step by step Building a real benchmark for your team beats importing someone else's number, because your channel mix, ticket complexity, and staffing model don't match anyone else's exactly. Here's the sequence that produces a number worth trusting. **Pull calendar-time FRT per channel for the last 90 days.** Not business hours only, not blended across channels. Separate chat, email, and social or messaging into their own numbers. Ninety days smooths out short-term noise from a bad week or a product incident without going so far back that it includes a support setup you've since changed. **Split AI-handled from human-handled within each channel.** If your [Analytics](/analytics) setup can tag which replies came from the AI agent versus a human teammate, do that split before calculating anything else. This is the step most teams skip, and it's the one that makes every other number meaningful. **Calculate median and p90 for each of the four resulting buckets.** AI-chat, human-chat, AI-email (if applicable), human-email. Four numbers, not one. The median tells you typical experience, the p90 tells you how bad the worst-served 10% of customers have it. **Exclude auto-acknowledgments explicitly.** Check your helpdesk or [Embed Widgets](/embed-widgets) configuration for whether the "received your message" auto-reply is being logged as the first response event. If it is, fix the measurement before trusting the output. **Compare against realistic ranges, not vendor marketing.** Use the channel ranges earlier in this post as a starting point: live chat median under 90 seconds is solid, email median under 4 to 6 hours for standard priority is competitive, social under 60 minutes matches customer expectations. Compare your numbers against those ranges, and against your own trend over the last two or three quarters, which usually matters more than any external comparison. **Re-run the benchmark quarterly, not once.** FRT drifts. Knowledge base gaps grow as your product changes, staffing changes with headcount, and ticket mix shifts with your customer base. A benchmark run once and never revisited is a snapshot, not a metric. | Channel | Realistic median (mixed AI/human) | Strong performance | What drags it down | | --- | --- | --- | --- | | Live chat | ~90 seconds | Under 30 seconds | Understaffed peak hours, no AI first-touch | | Email | 4 to 12 hours | Under 2 hours | Batch-worked inbox, no priority triage | | Social/messaging | 1 to 5 hours | Under 60 minutes | Treated like email instead of like chat | | B2B tickets | 1 to 8 business hours | Under 1 business hour | Manual routing, no context on handoff | | AI-handled (any channel) | Seconds | Under 5 seconds | Cold-cache latency, thin knowledge base | | Human escalation tail | 15 to 30 minutes | Under 15 minutes | Queue-based instead of presence-based routing | ## Setting a target that isn't a vanity metric "Instant replies" as a headline claim is true for exactly one slice of your FRT distribution, the AI-handled slice, and only if your knowledge base covers the questions customers are asking. Marketing that number as your overall FRT without the human-tail context sets an expectation you can't uniformly deliver on, and a customer who lands in the escalation queue after seeing "instant support" promised somewhere will notice the gap immediately and resent it more than if you'd never made the claim. A target worth setting looks like two numbers, reported honestly: an AI-floor target (seconds, driven by knowledge base coverage and caching, not much else to tune) and a human-tail target (minutes, driven by staffing, presence-based routing, and escalation quality). Both numbers should improve over time, but they improve for different reasons and respond to different levers. Conflating them into one "our average FRT is X" headline is the exact measurement mistake this whole piece has been arguing against. If you're setting this up from scratch, [pricing](/pricing) for AI-handled support scales differently than headcount does, since the AI floor doesn't get more expensive per additional instant reply the way adding another human agent does per additional escalation handled. That's worth factoring into how aggressively you invest in knowledge base coverage (feeding the AI agent more of your documentation directly widens the instant floor) versus how aggressively you staff for the human tail. communicate.so runs on this exact split. The AI agent answers from your docs the instant a message lands, escalations land in a [Shared Inbox](/shared-inbox) a human is already watching, and [Analytics](/analytics) reports AI-handled and human-handled FRT as two separate lines instead of one blended number that hides the human tail. Activation is a one-time $1 charge that includes 100 test credits, cheap enough to run the benchmark work in this post against your own account before committing to anything bigger. | Capability | AI-handled reply | Human-handled reply | | --- | --- | --- | | Available nights and weekends | ✓ | ✗ | | Handles account-specific judgment calls | ✗ | ✓ | | Cost per reply stays flat as volume spikes | ✓ | ✗ | | Reads full shared thread before responding | ✓ | ✓ | | Needs presence-based takeover to avoid double replies | ✗ | ✓ | | Reported as its own line in FRT analytics | ✓ | ✓ | For teams just getting a first AI agent live, [launching your first AI support agent in an afternoon](/blog/launch-your-first-ai-agent) covers the setup mechanics that determine how wide your instant floor ends up being on day one, along with [security](/security) considerations worth checking before that agent touches real customer conversations. Once it's live, the benchmark work in this post is what tells you whether it's working, not just whether it launched. Deeper implementation steps live in [how to implement an AI support agent](/blog/ai-support-agent-implementation), and general context on the product lives on the [homepage](/), the [blog](/blog), and the [support category](/blog/category/support). ## Frequently asked questions ### What is a good first response time for live chat? Under 90 seconds is at or above the current cross-industry median, based on the Tidio Customer Service Benchmark Report. Under 30 seconds matches what customers describe as instant, and top ecommerce performers land in the 12 to 30 second range. ### What is a good first response time for email support? Under 2 hours for standard-priority email is competitive against a cross-industry average that sits closer to 12 hours (SuperOffice, 1,000-company study). Under 30 minutes is a reasonable target for priority accounts or outage-related tickets. ### Should I measure FRT in business hours or calendar time? Report calendar time anywhere the number is customer-facing or compared to a marketing claim. Business-hours FRT can still be useful internally as a staffing efficiency metric, but it hides real wait time for anything submitted outside staffed hours. ### Does an automated acknowledgment message count as the first response? No. Only a reply that engages with the customer's actual question, from a human or an AI agent, counts. An automated "we received your message" receipt should never be logged as FRT in your reporting. ### Why should I look at median and p90 instead of just the average? Average FRT gets skewed by outliers in both directions and can hide a meaningful slice of badly-served customers behind a flattering headline number. Median shows typical experience; p90 shows how bad the worst 10% of wait times get. ### How does an AI support agent change first response time? It creates a near-instant floor for the share of inbound volume it can answer directly from your documentation, while escalated questions still route to a human on a separate, slower timeline. The two populations should be reported separately, not blended into one average. ### What's a realistic AI deflection rate? Published case data ranges widely, from [Forma's move from 30% to 39%](https://forethought.ai/case-studies/forma-uses-forethought-ai) over several months to [Grammarly's jump from 60% to 87%](https://forethought.ai/case-studies/grammarly-achieves-87-deflection-and-4-2-csat-early-with-forethought) within ten days after adopting a more agentic setup. Your knowledge base coverage and ticket complexity determine where you land more than any industry average does. ### Is a higher deflection rate always better? No. Some deflection numbers count a ticket as resolved even when the customer reopens it shortly after with the same unresolved question. Check what happens after the bot marks something resolved before trusting a deflection percentage at face value. ### What's a good escalation rate for AI-handled support? Leading implementations aim to keep escalations under roughly 15% of total volume while holding AI answer accuracy at 85% or higher on the tickets it does handle directly. ### How fast should a human agent respond after an AI escalation? A median under 15 to 30 minutes during staffed hours is a reasonable working target, with a p90 that stays under an hour. If your escalation FRT resembles pre-AI email response times, the routing or presence-detection setup likely needs attention rather than the AI agent itself. ### Does Shared Inbox affect first response time? Yes. When AI and humans work the same conversation thread with a full shared transcript, an agent picking up an escalation doesn't need a clarifying round trip to catch up, which shortens effective human FRT. Presence-based takeover also prevents escalated conversations from sitting unwatched in a queue. ### What is response and prompt caching, and why does it matter for FRT? Caching keeps the AI agent's understanding of your documentation warm instead of reprocessing it from scratch on every query. It's a major reason instant replies stay both fast and affordable at volume, especially during traffic spikes when latency would otherwise creep up right when speed matters most. ### How often should I re-benchmark my FRT? Quarterly, at minimum. Knowledge base gaps grow as your product changes, staffing shifts with headcount, and ticket mix shifts with your customer base, so a one-time benchmark goes stale faster than most teams expect. ### Should FRT be reported per channel or blended across channels? Always per channel. Chat, email, and social carry different customer expectations and different operational realities. A blended number flatters whichever channel has the most volume and hides problems in the others. ### What FRT should I put in marketing copy? Be specific about which population the number describes. "Instant AI replies for common questions, human follow-up within X minutes for everything else" is honest and specific. A single blended "instant support" claim sets an expectation your escalation queue can't uniformly meet. ### Does company size change what a good FRT looks like? Yes, mostly through staffing capacity rather than any built-in difference in customer expectations. Smaller teams often lean more heavily on AI-handled first response to hit competitive numbers, since they can't staff live coverage across every hour the way a larger team can. ### What's the difference between first response time and resolution time? FRT measures how long until the first substantive reply. Resolution time measures how long until the customer's issue is solved, which can take multiple exchanges after a fast first response. A team can have excellent FRT and mediocre resolution time if the first reply is fast but doesn't move the ticket forward. ### Can I compare my FRT against a competitor's public claim? Only if you know how they're measuring it, which you usually don't. A competitor claiming "instant support" is very likely describing their AI-handled floor, not their blended or human-tail number. Treat public FRT claims as directional at best. ### What tools help track FRT correctly? Look for [analytics](/analytics) reporting that separates AI-handled from human-handled replies by default, supports calendar-time as well as business-hours views, and reports percentiles alongside averages. If a tool only shows you a single blended average FRT, you're missing the data you need to act on this benchmark. ### Does communicate.so cost more than hiring another support agent? No. AI-handled tickets typically run $0.50 to $1.05 each against $8 to $12 for a human-handled ticket, and activation on communicate.so is a one-time $1 charge that includes 100 test credits (see [pricing](/pricing)). That makes it cheap to measure your own FRT split before deciding how much of the human tail to staff for.