Comparison
Refik and Yuma, read on the same day.
One is billed for tickets it fully resolves, and it is installed on top of the help desk a shop already runs. The other is billed for conversations, and it only exists inside a Shopify storefront, before a ticket exists at all. That is the whole comparison, and the rows below are the evidence for it — each one dated, each one from a page you can open yourself.
Method
Two sides, two dates, and an empty cell that means something.
The right-hand side of every row was read out of Yuma’s own pages on 10 October 2026 — the pricing page, the home page and the integrations page, nothing else. No analyst report, no review site, no vendor deck. The quotes are theirs, word for word, including the spacing their pricing table prints.
The left-hand side was read out of our own source code on 4 October 2026, and the plan figures come from the pricing page in this same directory, which fails its build if a price in the code changes without the page changing with it. That reading has a written limit we are not going to hide: it was done at the level of source code — written, called, reachable, and read by something — and not against a live store. So every Refik cell says the code produces this, not a shopper saw this.
An empty cell is a third state and it is on purpose. It does not mean “they do not have it”, and it does not mean “we do not have it”. It means we did not read it on that day, so printing a dash there would turn a gap in our reading into a claim about a product. Every empty cell in the table is named underneath, with the reason it stayed empty.
Two things are missing from this page by design. There is no verdict row and no score: a resolved ticket and a conversation are not the same unit, and dividing one price by the other would produce a number that looks like a measurement and is not one. And there is nothing here about how well either assistant answers a shopper, because we did not measure that on either side — not theirs, and not ours.
One more thing was left out on purpose, and it is worth saying out loud because it would have been easy to use. Their pricing page carries its own comparison table, with claims about what other providers charge. Those rows were not copied into our fact base and they are not on this page. A vendor’s claim about a competitor is not a fact from that competitor’s own page, and the standard we hold ourselves to on this site is that a row about someone else has to come from that someone else.
The rows
What each side charges for, and where it sits.
Read the first two rows together. They are the reason the rest of the table looks the way it does: one price moves with how many tickets get closed without a person, the other moves with how many shoppers started talking. A shop with twelve thousand tickets a year and a shop with three hundred storefront conversations a month are not the same shop, and they do not land on the same side of that line.
Yuma read from yuma.ai/pricing, yuma.ai and yuma.ai/integrations; Refik read from this repository and the pricing page.
| What the row measures | Refik | Yuma |
|---|---|---|
| What you are billed for | ||
| The billing unit | Conversations in a billing period, resolved or not. Three bands: 300, 1,000 and 3,000. | “Outcome-based pricing You only pay when Yuma fully resolves a ticket If a human touches the ticket, it doesn't count against your plan.” |
| Entry tier, list price in USD | Starter, $39 a month or $390 a year, for the whole shop, with 300 conversations in the band. | “Starter … $14,400 /yr ~ $1.20 per resolution 12,000 resolutions / year” |
| Upper tiers, list price in USD | Growth and Premium: $99 and $249 a month; $990 and $2,490 a year; 1,000 and 3,000 conversations in the band. | “$40,000 /yr ~ $0.83 per resolution ~ 48,000 resolutions / year” and “$90,000 /yr ~ $0.75 per resolution ~ 120,000 resolutions / year” |
| What happens past the top tier | “Past 120,000 resolutions a year your rate keeps dropping toward the $0.55 floor” | |
| Charges on top of the subscription | On monthly billing, $0.15, $0.12 or $0.10 for a conversation above the band, by plan. On yearly billing, none. | “Monthly plan: $1.50 over-quota ticket” |
| One-time implementation fee | “Implementation fee $0 (first 30 days free)” | |
| Free trial | 14 days on every plan, with a conversation allowance scaled to the plan. There is no free tier underneath it. | |
| Where it sits | ||
| What it is installed into | A Shopify theme and a Shopify app, and nothing else. The catalogue, the policies and the order lookups all come from one store’s Admin API, and there is no second commerce platform in the code. | Their first setup step connects Yuma to the help desk a shop already runs — they name five of them — and to the Shopify store, and ends “Live in hours, not weeks.” The five names were read and measured, but this page only names Yuma; see the note below. |
| What it reads from the shop | Products and variants on a first full pull plus an update queue and an hourly refresh; the shop’s own return, shipping and privacy policies, offered to the merchant as a draft rather than applied silently; and order lookups on request. | “Connect Shopify to Yuma AI so routine ecommerce support starts running itself. Yuma reads live product, order, inventory…” |
| Channels a shopper can use | The web storefront, and only that. WhatsApp, Instagram, Messenger, email and SMS are not built, and that is written on the integrations page rather than left to be discovered after payment. | Their own description of what the agents automate names “support, sales, social, and chat”. A channel-by-channel list was not among the three pages read. |
| Handing a question to a person | Partly built, and the limit is written in the code. The server can open a ticket in exactly one help desk, with a live call, an encrypted key, an hourly job and a guard against sending the same thing twice. The screen a merchant would use to pick a different target is not built, and the one help desk it does support cannot be named on this page. | |
| How each side frames itself | ||
| Who it says it is built for | One Shopify store at a time, with an industry pack chosen for the trade it sells in. A merchant account can hold several stores and switch between them; there is no combined view across them. | “Built for Modern ecommerce & DTC (purpose-built)” |
| How each side describes itself | A shopping assistant on the storefront: it recommends, it looks up an order, it answers from the catalogue and the policies, and it hands a hard question to a person. It is told never to say a refund is approved. | “Automate ecommerce support, sales, social, and chat with AI agents that resolve tickets, grow revenue, and keep response times low without scaling headcount.” |
- Past the top tier, our cell is empty. Our three bands stop at 3,000 conversations and the only thing published above a band is the per-conversation charge in the row above it. Whether there is a rate for a shop far past the top band is not written anywhere we read on 4 October, so the cell stays empty instead of inventing a floor to match theirs.
- Implementation fee, our cell is empty. Our pricing page prints plan prices and a trial length; it does not carry an implementation-fee line either way, and we did not read one in the code. Writing “none” there would be a guess about billing, which is the one place a guess is expensive.
- Free trial, their cell is empty. The three pages read that day did not state a trial length or a trial at all. That is a gap in our reading, not a statement about their product.
- Handing a question to a person, their cell is empty. The only sentence we read that touches human involvement is the billing one in the first row — a ticket a human touches does not count against the plan. How a question reaches that human, and what the agent does while it waits, was not among the pages read.
- One row was measured and cannot be fully printed here. Their setup step names five help desks by name. Those names were read, dated and recorded in our fact base, but this page carries one competitor’s name and one only, so they are measured but not nameable here. The row above says what the measurement means — that this product is installed on top of a help desk a shop already has — without naming the five.
- Their own comparison table is not here. Their pricing page makes claims about what other providers charge. Those rows were deliberately kept out of the fact base this page is built from, because a claim about a competitor is not a measurement of that competitor.
- Search and traffic numbers were not measured on either side. Our fact base records that explicitly for this competitor, so there is no row for it rather than a row with a number nobody checked.
- Neither side’s answer quality is here. Not theirs, not ours. Measuring it would need the same shoppers asking the same questions of both, on a real catalogue, and that has not been done.
The difference that matters
A resolved ticket and a conversation are not the same thing to buy.
Their unit is a ticket the assistant closed on its own. Theirs is the stricter promise of the two, and we should say so plainly: if a person steps in, their own pricing sentence says it does not count against the plan. Our unit is a conversation, and a conversation counts whether the assistant answered well, answered badly, or gave up and opened a handover. On that one axis their meter is kinder to the buyer than ours, and pretending otherwise would be the easiest lie on this page.
What our unit buys instead is a smaller bill at a smaller size. Their entry tier is twelve thousand resolutions across a year for fourteen thousand four hundred dollars. Ours is three hundred conversations in a month for thirty-nine. Those are not competing offers for one shop; they are offers for two different shops. A storefront that produces a dozen questions a day has no way to consume twelve thousand resolutions, and a support operation closing a thousand tickets a month would burn through our top band in days.
The second difference is where the thing sits, and it decides more than the price does. Their first step is to connect to the help desk a shop already runs. That is a sentence about the shape of the buyer: there is a ticket queue, it has volume, and the job is to answer tickets without adding people. Our first step is to put a block in a Shopify theme. There is no queue in the picture, because the questions we are built for arrive before an order exists — which of these two suits me, is this in stock in my size, where is the order I placed on Friday, can I send this back. Those arrive on a product page and are answered from one shop’s catalogue and one shop’s policies.
That is also why the two are not really substitutes. If a shop has a ticket queue, a storefront assistant does not drain it; it only keeps some of it from forming. If a shop has no ticket queue, something that installs on top of a help desk has nothing to install onto. The case where both are true at once is real and common — a shop with a help desk in place that wants the storefront to stop sending it the easy questions — and for that case the handover matters more than either price. Here is the honest state of ours, repeated from the table because it is the thing a buyer would discover late otherwise: one help desk is wired, the picker for choosing another is not built, and the integrations page lists what is connected and what is not in the same words.
Who each one fits
Where we would tell you to buy the other one.
The other one fits you if you already run a help desk and the tickets in it are the expensive part. If your year is counted in tens of thousands of tickets, if most of them are the same handful of questions arriving after the sale, and if the decision in front of you is whether to add people, then you are shopping for something that closes tickets inside the queue you already have. We do not have a queue, we do not have a per-resolution meter, and buying us for that job would leave the queue exactly where it was.
We fit you if the questions that cost you money arrive before the order exists, and if there is one Shopify store. A shopper on a product page who cannot tell two variants apart does not open a ticket; they leave. That is the gap we are built for, and it is answered from the catalogue, the stock and the written policies of that one shop, in the storefront, at the moment the question is being asked. The price follows the number of shoppers who asked, which is a number a small shop can look at and recognise.
Neither of us fits you if what you actually need is a person. Both products put a human at the end of the path. Ours does it by opening a handover and telling the shopper a person will pick it up, and it is instructed never to approve a refund on its own. If there is nobody to pick it up, no assistant on either side of this table fixes that — and an assistant billed on resolutions will simply stop charging you for the tickets it could not close, which is fairer, and still not an answer for the shopper waiting.
Neither of us is measured against the other on quality, and that is the last honest thing on this page. The table above compares what each side charges for, what it is installed into, and what it reads. It does not compare how good the answers are, because nobody ran that test, and a comparison page that quietly implied it had would be worth less than no comparison page at all.