A support ticket has one job: to get a customer’s problem fixed. Either the return gets processed, the refund hits their card, the exchange ships, or it doesn’t. There’s no middle state. Done or not done.
So why do we measure support by tickets created, handled, and closed? We’re counting the wrong thing. We should be counting problems solved. The distinction matters because the entire industry is built around the wrong unit.
The unit of work
Every helpdesk vendor charges you for tickets. Per ticket. Per seat. Per conversation. The moment a customer sends a message, you’re on the clock. The vendor gets paid whether the problem gets solved or not. A deflected ticket still counts. An escalated ticket still counts. A ticket that bounces between three agents before someone figures it out still counts. Volume flows through. Money flows in. The vendor’s revenue is a function of how much support traffic you have, not how efficiently it gets resolved.
That creates a perverse incentive. The ideal customer for a ticket-based vendor is one with high volume and low resolution. You pay more. They earn more. A customer who actually eliminates tickets through better self-service or smarter automation is a churn risk. So the tools aren’t built to eliminate. They’re built to manage. Route. Prioritize. Deflect. Keep the queue moving. The metric is “tickets handled,” not “problems solved.”
I’m not accusing anyone of malice. Incentives shape behavior. If your business model rewards volume, you build for volume.
What deflection actually does
Deflection sounds good. The bot answers the easy questions. FAQ stuff. Policy stuff. “Where’s my order” if we can pull tracking. Maybe 30 or 40 percent of incoming messages never become tickets. Great, right?
Except “never became a ticket” isn’t the same as “problem solved.” Some of those customers got what they needed. Some gave up. Some left a bad review and bought elsewhere next time. Some will email support tomorrow with the same question because the bot’s answer was useless. We don’t measure that. We measure deflection rate and call it success.
The other problem: deflection has a ceiling. The easy stuff deflects first. What’s left is the hard stuff. Returns with exceptions. Multi-item orders where one piece is defective. Customers who are angry and need a human voice. So you deflect the low-hanging fruit and your remaining ticket mix gets harder. Average handle time goes up. Agent burnout goes up. You’ve optimized for “fewer tickets” without actually reducing the work that matters.
Real progress means the work goes away. Not that it gets routed somewhere else.
Resolution requires execution
To actually resolve a return, someone has to do things. Check the order. Verify it’s within the return window. Generate a label. Notify the warehouse. Process the refund. Update inventory. Six or seven discrete actions, each with dependencies. A chatbot can’t do any of this. It can tell you the policy. It can give you a link to a form. The form creates a ticket. A human does the work.
That’s the bottleneck. Information retrieval is solved. LLMs are good at it. Execution is different. Execution means calling APIs. Checking policy logic. Orchestrating a workflow. Handling the case where the order is past 30 days but the customer is a VIP. Or the item was on sale and policy says no returns, but it arrived damaged. Execution requires context and tools. Retrieval requires neither.
An agent that resolves has to be wired into your systems. Shopify. Stripe. ShipStation or whatever you use. The agent doesn’t suggest. It executes. Generate the label. Process the refund. Send the confirmation. The human’s job shifts from doing the steps to approving the outcome. One click. Full context. Move on.
The exchange problem
Two customers message with identical words: “I want to return this.” Customer A hated the product. Doesn’t fit. Quality is bad. They want out. Refund is the right outcome. Customer B ordered the wrong size. They’ve bought from you before. All their past orders were Large. This one was Medium. They’ve browsed the same item in Large twice this week. They don’t want a refund. They want the right size.
A system that only sees the message treats both the same. Policy says returns allowed? Issue the label. Done. Customer A gets a refund. Customer B gets a refund when they would have happily taken an exchange. You just gave away revenue and created a future acquisition cost to win them back.
To distinguish A from B you need data outside the support channel. Order history. Browsing behavior. Sizing patterns. First-party data. Most helpdesks don’t have it. They’re support tools. They see the chat and maybe the order. They don’t see the full customer. So they can’t make the distinction. Safe default: refund. Wrong half the time for the wrong-half segment.
This is why support built on commerce data behaves differently. The agent isn’t guessing. It’s inferring from signal. Wrong size vs. dissatisfied. Exchange vs. refund. The outcome changes. So does the revenue.
Support as a cost center
We’ve accepted that support costs money. Salaries. Tools. Outsourcing. It’s a cost center. You minimize it. You optimize for efficiency. Handle time. First response. Tickets per agent per day.
But support touches customers at the moment they’re most likely to churn. Something went wrong. They’re frustrated. Every refund is revenue walking out the door. Every exchange is revenue retained. Every well-handled complaint can create loyalty. Support could be a revenue channel. We’ve just built the systems and incentives to make it a cost center instead.
When resolution happens without human touch, two things shift. Cost drops because humans aren’t in the loop. Revenue improves because the AI can make exchange vs. refund calls at scale, offer upsells during support conversations, and recover carts when someone asks about shipping. Support stops being purely expense and starts contributing. The shift requires different tools. It also requires different pricing.
Pay for outcomes
What if you paid per resolution instead of per ticket? Resolved equals paid. Escalated equals not paid. Suddenly the vendor’s incentive aligns with yours. They want high resolution rates. They want to handle more without escalating. Their revenue grows when they eliminate work, not when they process it.
That changes the architecture. A vendor paid per ticket will optimize for deflection (fewer tickets to humans) and routing (keep the queue moving). A vendor paid per resolution will optimize for actually solving the problem. Different objective. Different product.
Outcome-based pricing also forces honesty about what “resolution” means. It has to be definable. A return processed. A refund issued. An exchange completed. No fuzzy metrics. Either the customer’s need was met or it wasn’t. That clarity benefits everyone.
What’s left for humans
If 90 percent of support tickets are repetitive (returns, tracking, address changes, policy questions), those are workflows. Humans executing workflows is a waste. The value of a human is judgment. The edge case. The angry customer who needs de-escalation. The VIP who gets an exception. The policy ambiguity that requires a call.
When the repetitive 90 percent gets handled by an agent, the remaining 10 percent gets actual attention. The tickets that land on a human’s desk arrive with full context. Conversation history. Customer lifetime value. Recommended action. The human decides. The system executes. No digging through tabs. No copy-pasting order numbers. One decision. Next ticket.
That’s a better job. The best support agents don’t want to process returns all day. They want to solve hard problems. The structure just never let them.
The structural fix
The fix isn’t better chatbots. Chatbots are information retrieval with a friendly interface. They can’t resolve because they can’t execute. The fix is agents that have tools, policy awareness, and commerce context. Architecture first. Then incentives. Price on outcomes so the vendor profits when you do.
Support doesn’t have to be a cost center. It doesn’t have to be broken. The incentives have been wrong. Once they align, the rest follows.