Artificial intelligence customer care replaces the tickets where the answer already sits in a system and the fix is an action, not a decision. It does not replace the person who has to judge a damaged goods dispute or calm down an escalated customer. The split between the two is not a percentage someone can quote you on a call, it is a property of your ticket queue, and you can measure it in an afternoon.
Most explanations of this stop at "AI handles the simple stuff." That is not specific enough to plan around. This article draws the actual line: what makes a ticket automatable, what makes one resistant to automation, and how to count your own split before you spend money on any tool.
What artificial intelligence customer care means inside a real ticket queue
Artificial intelligence customer care is not a chat widget that answers questions in a friendly tone. It is two separate jobs done automatically: classifying an incoming ticket by what the customer actually needs, and then resolving it by taking the action that closes it, not just replying to it.
A chatbot that tells a customer "your order usually ships in 3 to 5 days" has answered a question. A system that looks up the actual order, sees it shipped yesterday, and sends the tracking number back inside the same ticket has resolved it. That difference, reply versus resolution, is the whole subject of this article.
AI customer experience improves when the resolution rate goes up, not when the response time goes down. A fast, wrong, or vague reply just generates a second ticket. The categorization framework below is what determines whether a given ticket type belongs in the automated pile or the human pile, and it holds regardless of which platform or model sits behind the system.
The three things that decide whether a ticket can be automated
Every ticket in a queue can be scored against three questions. Get clear answers to these three and you know, without guessing, whether artificial intelligence customer care can close it alone.
Where does the answer live. If the answer sits in a structured system, an order management platform, a fulfillment tool, a subscription billing system, the AI can query it directly. If the answer only exists in a person's judgment or a photo someone needs to look at, it cannot.
Is the fix a system action or a judgment call. Updating a shipping address before a warehouse picks the order is an API call. Deciding whether a customer's story about a missing package is credible enough to warrant a free reshipment is a judgment call. Actions can be automated. Judgment calls cannot, not safely.
How much financial or reputational risk is attached. A discount code that fails at checkout costs nothing to fix automatically. A refund request worth $600 outside the stated policy carries risk if the automation gets it wrong. The higher the risk, the higher the bar for letting a system decide alone.
A ticket that scores well on all three, structured data, deterministic action, low risk, is a candidate for full automation. A ticket that fails even one of the three needs a person somewhere in the loop.
Tickets AI resolves without a human touching them
These are the categories that consistently pass all three tests, across ecommerce queues of very different sizes.
- Order status and tracking. The order number maps to a record in the fulfillment system with a carrier, a tracking number, and a status. The AI pulls it and replies with the real number, not a canned estimate.
- Address changes before fulfillment. If the order has not been picked yet, updating the shipping address is a write to the order record. If it has already shipped, this becomes a judgment call about whether to intercept the package, and it moves to the human pile.
- Subscription pause or cancel. The subscription platform already has a pause and cancel endpoint. The AI ticket handler calls it and confirms the change back to the customer in the same message.
- Discount code errors. A code that is expired, misapplied, or excluded from a product is a lookup against the promotions table, followed by either applying the correct code or explaining the exclusion with the actual rule.
- Return label generation within policy. If the order is within the return window and the item qualifies, generating a label is a call to the returns system. Outside the window or against a policy exception, it needs a person.
Every one of these has the same shape: the customer is asking about something the business already knows the answer to, somewhere in a system it already owns.
Why those tickets are easy: the data is structured and the action is deterministic
The AI is not reasoning about what to do, it is doing a lookup and then an API call, against fields and endpoints that already exist in the order management, subscription, and promotions systems.
Because the outcome is deterministic, given the same order state, the same action happens every time, there is no discretion for the AI to get wrong. Contrast this with a ticket where two humans on the same support team might reasonably make different calls. That second kind of ticket cannot be handed to a deterministic system without someone deciding, in advance, exactly which cases get which outcome, which is a policy project, not an AI project.
This is also why "add AI to the helpdesk" often disappoints. If the AI only has access to the ticket text and not the order and fulfillment data behind it, every one of these deterministic tickets still requires a person to go look something up in a second tab. The automation only works once the AI can reach the source of truth directly.
Tickets that still land on a person
- Damaged goods disputes needing photo judgment. Someone has to look at the photo and decide if the damage is consistent with shipping, a manufacturing defect, or misuse, and whether the claim is credible.
- Refund requests outside policy. The stated policy says no, but the customer has a case: a late gift, a documented allergic reaction, a repeat customer worth keeping happy. That is a discretionary call weighing money against the relationship.
- Angry customers escalating tone. Once a customer is not asking a question but venting, the job is de-escalation, not information retrieval. That is a human skill.
- Multi-order account problems. A customer with six orders across two accounts and a billing dispute spanning three months does not have a single structured record to query. Someone has to reconstruct the picture.
- Chargebacks. These involve a bank, evidence submission, and a deadline, with real money at stake on a wrong move. This stays with a person, usually with finance involved.
Why handoff tickets resist automation
Each of these fails at least one leg of the three-part framework, and most fail two.
There is no single structured source of truth. A damaged goods claim depends on a photo, the shipping carrier's handling record, and the customer's account history, three different signals that need to be weighed against each other, not looked up.
The call is discretionary with money or brand reputation attached. A refund decision outside policy is a bet on customer lifetime value versus the cost of an exception. That is a business judgment, and getting it systematically wrong at volume either burns cash or burns customers.
The cost of a wrong automated answer exceeds the cost of a short delay. A chargeback response filed incorrectly can cost the full order value plus a fee. Waiting four extra hours for a person to review it costs almost nothing by comparison. Wherever that asymmetry holds, the ticket should wait for a human rather than get an instant, possibly wrong, automated answer.
What the split actually looks like in ticket volume
The real split depends on what you sell, how often things go wrong in fulfillment, and how generous your return policy is. A subscription box business will see a heavier share of pause and cancel tickets than a business selling one-time high value items, which will see more damaged goods and dispute tickets instead.
The way to find your real number is to pull last month's tickets and tag each one against the three-part framework: where does the answer live, is the fix an action or a judgment call, what is the risk if it is wrong. Once every ticket has a tag, count them. The automatable share is whatever percentage passed all three tests, not a number borrowed from a vendor's homepage.
This exercise usually surprises people in one of two directions. Some queues have far more structured, low-risk lookup tickets than the team assumed, because the volume of "where is my order" and "I want to cancel" drowns out the memorable, hard cases. Other queues are genuinely dominated by judgment calls because the product or policy invites disputes, and automation will only ever touch a modest slice of the volume.
Auditing your own queue before you buy anything
Do this before evaluating any AI customer care tool, not after.
- Pull 200 recent tickets. Use whatever helpdesk or inbox you already run, export the last 200 closed tickets with their category tags if you have them, or the raw subject lines if you do not.
- Tag each one against the three-part framework. For each ticket, write down where the answer lived, whether the fix was an action or a judgment call, and the rough dollar risk if a wrong answer had gone out.
- Count minutes spent per category. Time-stamp when the agent opened the ticket and when they closed it, even roughly. This tells you where the labor is actually going, which is often not the category with the most tickets.
- Separate volume from time cost. A category with 40 tickets a month at two minutes each costs less agent time than a category with 15 tickets at twenty minutes each. Automation candidates should be judged on time saved, not just ticket count.
- Total the automatable share. Add up the tickets that passed all three tests in step two. That is your real number, specific to your queue, not an industry average.
Only after this exercise do you know what you are actually buying when you evaluate a system, and what volume of tickets any alternative to Gorgias or Zendesk would need to handle to be worth the switch.
Why this only works as part of a connected system, not a bolt-on
Every automatable ticket in this article depended on the AI having live access to an order, a fulfillment status, or a subscription record. None of that works if the AI only sees the text of the ticket. A standalone chatbot bolted onto a helpdesk can format a nice-sounding reply, but it cannot check whether an order has shipped, because it was never given a door into that system.
Getting from "nice reply" to "resolved ticket" means wiring the resolution engine directly into the order management platform, the fulfillment tool, and the subscription or billing system, so it can both read the current state and write the fix, an address update, a cancellation, a label. That is systems integration work, not a chatbot subscription.
This is also where the underlying tradeoff shows up: renting per-seat helpdesk software with an AI add-on bolted on top charges you whether the AI resolves anything or not, while a system built to own the resolution end to end is judged on the ticket volume it actually clears. If you want to see the mechanics of ecommerce support automation applied to a queue like yours, ticket type by ticket type, that is where to look next.
Common questions
Does artificial intelligence customer care replace the support team entirely?
No, it removes the repetitive lookup tickets and leaves the judgment calls, so the team shrinks its queue rather than disappearing.
What percentage of tickets can AI actually resolve?
It depends on your ticket mix, which is why you tag your own last 200 tickets against the three-part framework instead of trusting a generic number.
Is this the same as a chatbot on the website?
No, a chatbot answers questions with text while this resolves the ticket by taking the action in your order and fulfillment systems.
How is this different from turning on automation inside Gorgias or Zendesk?
Helpdesk automation triggers canned replies inside their platform, while a built system connects directly to your order data and owns the resolution, not just the reply.
If you want to see where your own queue splits, work out what manual ticket handling is costing you before you tag a single ticket by hand.
Find out what the manual work is costing you
One call, we map where the time goes and what a system would replace.
