TL;DR: A support chat and a selling chat can be the same widget doing inverse jobs — and you can tell which one you installed by what its dashboard rewards. Deflection rate, containment, and average handle time all go up when the chat successfully makes a conversation end. A sale needs the conversation to continue — to an offer, an objection handled, a payment. So a chat graded on support metrics is tuned to close the exact conversations a seller would advance. This is the reframe, a copyable Metric Mirror, and a two-minute test to tell which chat you actually have.
For: ecommerce, SaaS, and service owners whose website chat sees real buying-intent traffic. What you'll get: why the metric fights the sale, a Metric Mirror you can copy, and a self-test that also tells you when to ignore all of this. Last updated: 2026-07-05.
The 60-second version
- Deflection, containment, tickets-resolved and handle-time are all support metrics: they score higher when a conversation ends.
- The mainstream debate — "deflection vs resolution" — is a fight between two support metrics. Both miss the revenue axis entirely.
- The deeper problem is mis-optimization: what you grade a chat on is what it learns to do, and support KPIs point it at ending chats.
- Use the Metric Mirror below to see, for each support number on your dashboard, the revenue number it's hiding — and which way it pushes the conversation.
- Then run the two-minute test: it also tells you when your chat should be a deflector and you should ignore this whole argument.
The dashboard is green and the sales line is flat
Here is the failure that doesn't trip an alarm. Your website chat reports a good week: deflection is up, average handle time is down, containment is holding above target, satisfaction is fine. Every number a support tool is built to show is pointing the right way. And your online sales for the week are flat.
Nothing looks broken because, by the chat's own scorecard, nothing is broken. It answered the questions, closed the tickets, and kept humans out of the queue — which is precisely what it was measured to do. The problem is invisible on that dashboard because the dashboard was never built to show it. A visitor who asks "does this fit a small kitchen?" and gets a crisp, correct answer and then leaves counts as a win: question answered, ticket resolved, no human needed. It is also a sale that didn't happen, and no support metric on earth will ever flag it.
Deflection and resolution are both support metrics
There's a live argument in support circles right now that deflection rate is a bad number — that "deflected" counts a customer who gave up the same as one who got helped, and that teams should measure resolution instead. That's a fair correction, and it's a real debate: vendors and analysts have spent 2026 pushing "resolve, don't deflect."
But look at what's on both sides of it. Deflection and resolution are both asking the same question: did we make this conversation go away without a human? One counts the ending generously, the other counts it strictly. Neither one asks whether the person on the other end was about to buy. You can win the resolution argument, swap your dashboard to first-contact-resolution and re-contact rate, and still have zero visibility into revenue — because you upgraded from one support metric to a better support metric. The axis you're missing isn't accuracy of resolution. It's that resolution and sales are different outcomes, and only one of them pays.
The Metric Mirror
For every support number your chat proudly reports, there is a revenue number it quietly doesn't. Copy this table and hold your own dashboard up to it. The third column is the point: every support metric improves when the conversation gets shorter or ends sooner, the opposite of what a sale needs.
| Support metric (what the chat reports) | Revenue metric it hides | Which way it pushes the conversation |
|---|---|---|
| Deflection rate ↑ | Conversion / offer-made rate | Toward ending (a deflected chat made no offer) |
| Containment rate ↑ (no human touched it) | Escalations to a closer, not just an agent | Toward no handoff — even to someone who'd sell |
| Tickets resolved ↑ | Carts opened, invoices issued | Toward case closed, not deal opened |
| Average handle time ↓ | Time-to-offer, objection handled | Toward short — a sale often needs longer |
| Self-service % ↑ | Assisted-sale % | Toward deflect, away from "let me recommend" |
None of these are wrong for a support team. A help desk should want deflection up and handle time down. The table only bites when the traffic behind those numbers was trying to buy — then every green arrow is pointing away from your revenue.
What you grade the chat on is what it learns to do
A scoreboard is not passive. What you grade a system on becomes the behaviour it optimizes toward, whether it's a support team chasing a quarterly deflection target or an AI agent tuned to resolve and contain. Point either one at "make conversations end cleanly" and it gets good at ending conversations cleanly. That's the trap: the metric actively trains the chat to kill the sale it can't see.
Play it out on one exchange. A visitor says, "I like this, but I'm not sure it's worth the price." To a deflector, that sentence is a resolved objection waiting to happen: acknowledge, reassure, answer, close the ticket — handle time low, satisfaction intact, deflection scored. To a seller, that exact sentence is the opening — the moment to recommend the right tier, address the specific hesitation, and put an invoice in the thread while the intent is hot. Same words, opposite reflex. The deflector's reflex is the one its dashboard rewards, so that's the one it builds.
The price tag grades deflection too
The same bias shows up in the invoice. The per-resolution AI vendors bill for a closed ticket, not a closed sale: Intercom Fin runs about $0.99 per resolution (minimum 50/month, plus ~$29/seat), and Gorgias's AI Agent is roughly $1 per resolution (⚠️ research-dated 2026 — check current rates before you commit). Every one of those meters spins on deflected volume. None of them costs more or less based on whether the visitor bought. Usage-based pricing on the seller side flips the denominator: you pay for the agent's actions, and a "resolved but didn't buy" chat carries no separate line item. It isn't "pay only for sales"; the agent still costs you. But you stop paying a premium for the act of ending a conversation.
The two-minute test: what is your chat actually being asked to do?
Before you change anything, find out what your traffic actually wants — because if it's genuinely support, everything above is the wrong advice for you.
Pull your last 50 chat transcripts and tag each one:
- Support: an existing customer with a problem — "how do I reset this", "where's my order", "it's not working".
- Pre-purchase: someone deciding whether to buy — "does it fit / include X", "how much for Y", "can you deliver by Friday", "what's the difference between these".
Then read the split:
- Mostly support → your deflection dashboard is telling the truth. Keep optimizing it, and do not bolt a closer onto people who came to fix a problem — pushing an offer at a frustrated customer is worse than useless.
- Mostly pre-purchase → you are grading a salesperson on a janitor's KPIs. Your chat's "good week" and your flat sales line are the same story told by two dashboards, and only one of them is about money.
The threshold isn't a percentage anyone can hand you; it's this ratio in your own logs. Most owners already suspect which way it leans — the test just makes it undeniable.
Where a selling chat is the wrong call
This reframe has a hard boundary, and it's worth naming so you don't over-correct.
- If your on-site chat is genuinely support-dominated — a large install base filing tickets, little new-purchase intent on the page — deflection is the correct metric and a selling agent is the wrong tool. Optimize the support chat; don't turn it into a sales floor.
- A mature support desk beats a selling widget at support. If SLA routing, multi-agent tiers, and ticketing are the job, Intercom or Zendesk are simply better at it. A selling agent is a closer on hot traffic, not a help-desk replacement, and the two can run side by side.
- A selling agent needs oversight early. Point it at your real knowledge base, then skim its first days — an autonomous agent will confidently push an offer into a support moment until you correct it. It improves; it isn't "set and forget" on day one.
What "sells" actually requires
If the test says your traffic is buying-intent, the fix isn't a better support metric — it's a chat whose job is the sale. That means an agent that doesn't stop at "answer and log": it recommends, handles the objection in the moment, and completes the payment inside the conversation on your own rails — an autonomous selling AI, not an operator clicking "issue invoice" and not a redirect to someone else's checkout. And because your buyer rarely finishes in one sitting, it should be one selling assistant across your site and your messengers — same knowledge base, same voice, whether they start on the landing page or continue in Telegram, WhatsApp or Instagram. A shared inbox that merely pipes those channels into one window is table-stakes; a single selling brain behind all of them is the part still worth choosing. That is what iSales is built to be. For the full converse-to-paid loop and a capability scorecard, see the pillar: a website chat that sells and takes payment. For the narrower question of who actually issues the invoice, see operator-issued vs autonomous checkout.
FAQ
Isn't "resolution rate" the modern fix for deflection? It's a better support metric, not a revenue one. Resolution asks "did we solve it without a human"; a sale asks "did we make an offer and take the money". You can have a perfect resolution rate on a page full of buyers and still convert none of them. Measure both, and never let the support number stand in for the sales one.
Can I just add a "conversion" goal to my existing support bot? You can bolt on the number, but the bot is still tuned to resolve-and-contain, so it will optimize toward the metric it was built for. Adding a conversion column to a support dashboard doesn't change the reflex underneath it. The reflex is set by what the tool's core job is, not by an extra KPI.
Does a selling chat hurt customer experience? Only if you aim it at the wrong traffic — that's what the two-minute test is for. On buying-intent conversations, a well-grounded agent that recommends and closes is a better experience than "our team will contact you". On support conversations, it's the wrong tool; keep those on a support chat.
How do I take payment in the chat without a compliance headache? The card data should never touch the conversation. Sound flows hand the actual charge to a PCI-compliant processor while the thread only shows the invoice and the confirmation — and your local fiscal-receipt rules still apply regardless of where the button lives.
Next step
Run the two-minute test on your last 50 transcripts first — it tells you whether any of this applies to you. If your traffic is buying-intent and your chat is still graded on deflection, put a selling assistant on the same page and let it run the sale end to end; the first 30 messages are free to try. Start in Telegram: Put an AI salesperson on your site →
Sources & last updated
- "Resolve, don't deflect" support-metric debate — Lorikeet, Decagon deflection-rate glossary
- Intercom Fin pricing (per-resolution/outcome) — fin.ai/pricing
- Gorgias AI Agent per-resolution pricing — Gorgias pricing
- iSales usage pricing and free tier (first 30 messages free) — /en/pricing
Competitor prices checked July 2026 — list prices, subject to change.
