What Can an AI Customer Service Agent Resolve on Its Own? Ticket Types Ranked

An AI customer service agent can resolve, without a person, the tickets that end in a lookup or a small, reversible action inside your systems: order status, policy and how-to questions, returns that meet your rules, and simple account changes. It should hand over billing disputes, large refunds, complaints and anything involving safety or fraud. This post ranks seven common ticket types by how well they suit automation and shows what each one needs.

The ranking is our judgment from building the AI customer support agent for an online retailer, not a benchmark. Your ticket mix will differ, so use the method to rank your own. For the full design of a support agent, read our AI customer support agent guide.

How do you decide which tickets an agent can resolve?

Ask four questions about each ticket type. The answers decide how much freedom the agent gets.

1. Is it read-only? Looking up an order changes nothing. Creating a return or changing an address does.
2. Can the action be undone? A reissued password link can be ignored. A refund sent to a card is hard to pull back.
3. Is money involved? Credits, refunds and billing fixes need limits that a person sets.
4. Does the agent need to know who is asking? Anything that reveals or changes personal data needs identity checks first.

OpenAI's practical guide to building agents gives the same logic in its own words. It suggests rating each tool low, medium or high risk based on factors such as read-only versus write access, reversibility, required permissions and financial impact, then using the rating to decide when to add a check or escalate to a human. It also lists high-risk actions that should trigger human oversight, including canceling orders, authorizing large refunds and making payments.

	Automation fit	What the agent needs
1. Order status (WISMO)	Very high	Read access to store and carrier
2. Policy and how-to questions	High	Approved knowledge sources only
3. Returns within policy	High	Eligibility rules, label creation, value limit
4. Simple account changes	Medium to high	Identity check, narrow write access
5. Billing questions and small credits	Medium	Billing read access, credit limit, approvals
6. Technical troubleshooting	Medium	Docs, diagnostics, clear escalation to tier 2
7. Complaints, cancellations, fraud, safety	Low	A person, with a summary prepared by the agent

Source: BufferSol judgment, based on our e-commerce support agent

BufferSol Technologies · buffersoltech.com

The seven ticket types, ranked

1. Order status: very high fit

"Where is my order?" is the best first job. It is read-only, frequent and predictable. The agent identifies the customer, finds the order, checks live carrier status and answers with the latest event and delivery date. Delays, lost parcels and "delivered but not received" claims are where it stops and hands over. We cover the situations one by one in our guide to WISMO automation, and the matching done-for-you order status automation shows what a ready-made version does.

2. Policy and how-to questions: high fit

Shipping times, warranty terms, sizing, setup steps. The agent answers from your knowledge base, and the risk is accuracy, not action. That risk is real. In Moffatt v. Air Canada (2024 BCCRT 149), a British Columbia tribunal found the airline responsible for wrong information its chatbot gave about bereavement fares. McCarthy Tetrault's summary quotes the tribunal: "It makes no difference whether the information comes from a static page or a chatbot."

So the agent should answer policy questions only from approved, current documents, quote the source it used, and say so when it does not know. Someone must own those documents, because an outdated page now produces outdated answers at scale.

3. Returns and exchanges within policy: high fit

Returns are the first ticket type that needs write actions: check eligibility against order date and item, create the return, send the label, update the order and ticket. Because the rules are written down, the agent can apply them consistently. The limit is value: refunds above a set amount, repeat returners and unusual cases go to a person with a summary and a suggested reply. Our post on returns automation with AI covers the rules and the legal side, and the done-for-you returns automation is the packaged form.

4. Simple account changes: medium to high fit

Updating an email, changing a delivery address before dispatch, pausing a subscription, sending a password reset link. These are small and mostly reversible, but they touch personal data, so the agent must verify the customer first, for example by matching the email on the account and confirming something only the owner knows. Changing login details is a favorite move for anyone trying to take over an account, so those changes should go through the same verified flow your website uses, not through free text in a chat.

5. Billing questions and small credits: medium fit

"Why was I charged twice?" involves money and trust. The agent can read the invoice and payment history, explain the charges and tell the customer what will happen next. Issuing a credit or correcting a charge should sit behind a limit, with approval above it. If you operate in financial services, the stakes are higher: the CFPB's report on chatbots in consumer finance says chatbots must comply with the same consumer financial laws as the processes they replace and must accurately identify when a customer is raising a dispute. A bot that treats a dispute as a routine question creates a compliance problem, not a resolved ticket.

6. Technical troubleshooting: medium fit

Fit varies with your product. For well-documented problems, such as connection steps or error codes, the agent can walk the customer through a fix and confirm it worked. For anything needing access to logs, environments or code, it should gather the details (version, error text, steps taken), attach them to the ticket and route it to the right tier. A well-prepared handover is itself a time saver, even when the agent cannot solve the problem.

7. Complaints, cancellations, fraud and safety: low fit

Keep people in charge of these:

• Formal complaints and legal threats
• Cancellations where a retention decision matters
• Chargebacks and suspected fraud
• Safety issues and vulnerable customers
• Anyone who asks for a person

The agent's job here is to recognize the case early, stop, and pass it on with the conversation, the account facts and a suggested reply. The CFPB report describes what happens otherwise: customers stuck in loops with no way out to a human, which it calls "doom loops." Make "talk to a person" available at every step.

What does a safe resolution look like end to end?

1. 011. Read and classifyIdentify the ticket type, language and urgency from the message and the account history.
2. 022. VerifyConfirm who is asking before sharing or changing personal data.
3. 033. Gather factsLook up the order, invoice or account through read-only tools.
4. 044. Check the rulesCompare the case with your policy and limits, enforced in code, not in the prompt.
5. 055. Act or hand overTake the small action within limits, or pass the case to a person with a summary.
6. 066. Reply and logAnswer in your tone, record every tool call on the ticket and follow up if promised.

Source: BufferSol AI customer support agent

BufferSol Technologies · buffersoltech.com

Step four matters most. Customers write free text, and some will try to talk the agent into exceptions. OWASP calls the underlying problem excessive agency and recommends minimizing the tools an agent has, minimizing the permissions of each tool, requiring human approval for high-impact actions and enforcing authorization in the downstream system rather than letting the model decide whether an action is allowed. In practice: the refund tool refuses amounts above the limit, whatever the conversation says.

How do you measure what the agent resolved?

Do not trust a "resolved" count alone. Intercom's documentation for Fin resolutions shows why: it counts a resolution when the customer confirms the answer was satisfactory, or when they leave without asking for more help. The second case is an assumption. A customer who gives up looks the same as one who is satisfied.

Check resolution against evidence instead:

• The action happened in the system of record: the return exists, the address changed.
• No repeat contact about the same issue within a few days, on any channel.
• Sampled review: your support lead reads a weekly sample of agent-handled conversations by ticket type.
• Handovers by type: a type that hands over most of the time is not ready for more freedom.

Our post on AI customer service that resolves rather than deflects goes deeper on measurement.

Where do you start?

Start with the types at the top of the ranking and widen as the numbers allow.

1. Export a month of tickets and tag each with one of the seven types above.
2. Mark each type with the four questions: read-only, reversible, money, identity.
3. Pick the one or two types with the highest volume and the lowest risk. For most online stores that is order status and returns.
4. Write the policy, limits and handover rules with your support lead, using what your best human agents already do.
5. Run the agent in draft mode first, where it proposes replies and a person sends them, then switch types to automatic one at a time as the review shows it is right.

Keep the human route simple. Our post on human-in-the-loop AI agents shows how to design approvals that do not slow the work down.

Tell customers they are talking to an AI. In the EU, the AI Act sets transparency duties for AI systems that interact with people, and the European Commission lists these as taking effect in August 2026.

What would BufferSol build in 30 days?

The support agent we built for an online retailer is connected to the store, the helpdesk and the shipping provider. It looks up orders, creates returns and labels within the rules, answers product questions from the catalog, and escalates edge cases to a person with a summary and suggested reply. Refunds above a threshold always go to a person.

For your business, a working agent on your real tickets inside 30 days looks like this:

• Week 1: ticket review, ranking and policy rules agreed, access to the helpdesk and systems set up.
• Weeks 2 to 3: a prototype handling the top one or two ticket types in draft mode, with every tool call logged.
• Week 4: a live pilot on a first slice of tickets, with weekly review of resolutions and handovers.

Wider rollout of every ticket type follows over the next weeks, as the review data supports it. If you would rather have the whole thing built and run for you, the done-for-you ticket triage and resolution automation is the packaged route, and our AI agent development team builds custom agents inside your helpdesk. If you are still deciding between buying a product and building, our comparison of AI customer service software and a custom agent lays out the trade-offs.