Can AI Actually Handle Retail Customer Service in 2026?

Your store gets the same eleven questions every day. Is this in stock, do you deliver to my area, how much is shipping, can I pay on delivery, where is my order. You answer them at nine in the morning and again at eleven at night, and somewhere in there a customer who was ready to buy got bored and left. So the question is not really whether a machine can answer those eleven questions. It is whether it can answer them without costing you the relationship, and what you will be billed for when it does.

Yes, for the questions that have exactly one correct answer, and in a retail store that is most of your volume. Stock, price, delivery, payment methods, hours, returns policy and order status all come from a written policy or from live store data, so a machine can answer them accurately and instantly. It should refuse everything where the right answer depends on what you are willing to do for this particular customer: refunds, goodwill, complaints you caused, negotiation, wholesale. The harder decision is not capability, it is the billing unit. Ten platforms will sell you the same outcome and charge you in five different units, and at retail volumes the unit decides your bill far more than the price does.

The eleven questions, and what each one needs

Capability is not one question, it is eleven. Most of what a retail store gets asked is deterministic, which is the word that matters here. A deterministic question has one correct answer that exists somewhere already, in a policy document or in your store database. A judgment question does not.

The second column is the one people skip, and it is where automation projects actually fail. An answer is only as good as the thing it is reading from.

Rows one to nine are roughly where the volume is in a typical store. That is the honest case for automating retail service: not that a machine is clever, but that most of what you are being asked is lookup work you are doing by hand.

Row eight deserves a flag. Order status is answerable only if the courier data is actually good, and in this region it often is not. We went through where that breaks in answering where is my order on WhatsApp.

Rows ten and eleven are not a limitation to engineer around. They are the part you keep. A machine that guesses at a refund decision produces an outcome you have to undo and a customer who stops believing anything you say.

The ten platforms, compared on what they bill you for

plumcut sells in this category, so treat this as a comparison published by a participant. Everything below is taken from each vendor's own pricing or documentation pages, checked on 13 September 2026, and judged on the same criterion. Prices move, so pull the current number from the linked page before you budget. The structure is the durable part.

The criterion is the one that decides your invoice at volume: what does the meter count?

Two observations that are worth more than any single price.

Most of the market now bills you for closed support tickets. Resolution pricing is the current consensus, and it is genuinely fairer than the old per seat model, because you pay when the thing works. But look at what the meter counts. A resolution is a support conversation that ended without a human. Intercom counts it when the customer confirms the answer helped or leaves without asking more. Zendesk counts a request handled with no escalation. That number can only ever measure work you avoided. There is no row in it for a sale.

Siena publicly argues against the model the rest of the category adopted, on the grounds that paying only for fully resolved cases gives the vendor a reason to avoid hard conversations. You do not have to agree with a vendor's argument about its own pricing to notice that it is a real question, and that it is asked from inside the category.

Why the unit matters more than the price at retail volume

Run it with round numbers. These are illustrative, not measured.

A store handling 1,000 automated conversations a month at 0.99 US dollars per resolution pays about 990 US dollars. Traffic triples in a good season and the same store pays about 2,970. Nothing improved. The store simply got busier, which is the thing you were trying to achieve.

Contact-based pricing has the same shape with a different trigger. You grow your customer base, which is the goal, and the meter reads your growth back to you as cost.

A fixed fee in bands inverts that. Busy months inside your band cost nothing extra, and the top band is a ceiling. That is how plumcut prices, and it is a deliberate answer to this exact problem: the fee is set by what the solution does rather than by how busy it gets, and the metered costs that genuinely do scale, Meta messaging and AI usage, are billed to you at cost on your own accounts with nothing added.

Neither model is universally correct. Per resolution pricing is better if your volume is low, spiky, or you want to pay nothing in a quiet month. A fixed band is better if you are growing and want the invoice to stop being a function of your success. Pick the one that matches which of those you are.

How you actually connect it to your shop

"Can it integrate" gets a yes from every vendor, so ask the sharper version: integrate with what, and how deep.

Shopify, WooCommerce and BigCommerce are well covered across the category. The apps exist, the order lookups work, and setup is measured in hours.

Salla and Zid, the store platforms a lot of Gulf retailers actually run on, are a different story. Both publish merchant APIs and both support WhatsApp integration through their own app stores. Neither appeared on the Gorgias, Zendesk, Intercom, Siena or Tidio integration listings when we checked them on 13 September 2026. A store on Salla or Zid is usually looking at a custom connection rather than installing an app, which changes the project from a purchase into a build.

That gap is not an accident. It is what happens when the category is built for a market that is not this one, and it is the practical reason a done for you setup often beats a self serve tool here. How plumcut works covers what connecting to your existing stack looks like when someone else does it.

Depth matters as much as coverage. A tool that reads order status but cannot read live stock will answer "where is my order" and guess at "is this in stock", and the second answer is the one that produces an order you cannot fill.

Where something else fits better than plum

Stated plainly, because a comparison that never says this is an advert.

If you are a low volume shop with spiky, unpredictable traffic and you want to pay nothing in a quiet month, per resolution pricing suits you better than any fixed fee, and Tidio's per conversation model is the gentlest entry point in the table.

If you are already running a mature support operation on Zendesk or Gorgias with a trained team, ticket history and macros, adding their own automation on top is less disruptive than replacing the stack.

If you want to configure and own the system yourself rather than have someone run it, self serve tooling is the right shape and plumcut is the wrong one, because it is a managed service by design.

And if you are not sure you have enough repetition to justify any of this, the honest answer might be to wait. We wrote the case for waiting in when your business is ready for AI customer service.

What to do this week

1. Write down every question a customer asked you in the last seven days. Do not summarise them, copy them.
2. Mark each one deterministic or judgment. Count the split. That ratio is the real size of your automation opportunity, and it takes an hour to find.
3. For every deterministic question, write down the source of the correct answer. Anything you cannot point at is not automatable yet, whatever you buy.
4. Then, and only then, compare vendors. Start with the billing unit, project it at three times your current volume, and compare the numbers you get at that volume rather than today's.