Comparison
Refik and Help Scout, read on the same day.
One is priced per user, per month, and the people who answer are the thing you are paying for. The other is billed per conversation and only exists inside a Shopify storefront, where nobody is meant to be on the other end 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 Help Scout’s own pages on 10 October 2026. Three of their pages were fetched that day — home, pricing and features — and each answered with HTTP 200 and no redirect; the rows below quote two of them. No analyst report, no review site, no vendor deck. The quotes are theirs, word for word, including one that our record cuts off mid-word: the cell reproduces the cut rather than finishing the sentence on their behalf.
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 limit worth stating plainly: it says the code produces a surface, not that the surface has been watched working in a live shop. Those are two different sentences and only the first one was measured.
An empty cell is a third state and it is on purpose. It does not mean “they 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 their product. Where a cell is empty, the reason is written underneath, named row by row. Every empty cell on this page happens to fall on their side, and that is a fact about the reading rather than about the product: we read all of our own source, and we read three of their pages.
Two things are missing from this page by design. There is no verdict row and no score: a per-user price and a per-conversation price are not the same unit, and dividing one 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 that was not measured on either side.
Two more are missing for duller reasons, and both are ours. Their pricing page states an annual discount as a percentage; no page on this site prints a percentage figure, so the row below describes the switch and leaves the number where we read it. And nothing about search traffic, keywords or domain authority appears here for either side, because the tools that would have measured it were not connected on the day the reading was done. That is an unmeasured column, not an empty one, so it is not in the table at all.
The rows
What each side charges for, and where it runs.
Read the first two rows together. They are the reason the rest of the table looks the way it does: a per-user price scales with how many people answer, a per-conversation price scales with how many shoppers ask. A shop with one owner and a busy storefront and a shop with six people on a rota and a quiet storefront will come out on opposite sides of that line. The last three rows are limits on our side, printed here rather than left for the second month.
Help Scout read from www.helpscout.com/pricing/ and www.helpscout.com; Refik read from this repository and the pricing page.
| What the row measures | Refik | Help Scout |
|---|---|---|
| What you are billed for | ||
| The billing unit | Conversations in a billing period. Three bands: 300, 1,000 and 3,000, and the band belongs to the shop rather than to a person. | Per user, per month. The unit is written into every tier label on the pricing page, for instance “Standard $ 25 per user/mo”. |
| Entry tier, list price in USD | Starter, $39 a month or $390 a year, for the whole shop however many people open the console. | “Standard $ 25 per user/mo”. |
| Upper tiers, list price in USD | $99 and $249 a month; $990 and $2,490 a year. | “Plus Popular $ 45 per user/mo” and “Pro $ 75 per user/mo”. |
| Paying for a year instead of a month | $390, $990 and $2,490 a year against $39, $99 and $249 a month — ten months of the monthly price, the same arithmetic on all three tiers. | The pricing page carries a monthly-or-annual switch and the switch itself states an annual discount. The figure is a percentage, and no page on this site prints one, so it is not reproduced here. |
| Charges on top of the subscription | On monthly billing, $0.15, $0.12 or $0.10 for a conversation above the band, capped at one band’s worth. On yearly billing, none. | “AI Answers Add-on $ 0.75 / resolution Scale capacity with an AI assistant that instantly resolves customer reques…” |
| A free tier | None. The cheapest way in is the trial, and after the trial it is Starter. | “The Free plan includes 5 users, 1 Inbox, and 1 Docs site.” |
| A free trial | 14 days on every plan, with a conversation allowance scaled to the plan. | “3-month free trial Try AI Answers at no cost so you can see its impact on response time.” |
| Where it runs | ||
| Platforms it connects to | Shopify only. The catalogue, the policies and the order lookups all come from one store’s Admin API, and there is no second platform in the code. | On the three pages read that day, “Shopify” appeared no times. The same reader found their own name on all three, so it was not blind — and an integration directory was outside the three pages, so this is a reading of those pages and not of the product. |
| 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. | |
| How each side describes itself | A shopping assistant on the storefront: it recommends, it looks up an order, and it hands a hard question to a person. | “Help Scout delivers all the powerful, intuitive features you need to deliver exceptional support at a fraction of the cost of other customer service platforms.” (the home page’s meta description) |
| Limits we can state about ourselves | ||
| A ticket in your help desk | One help-desk vendor is supported and it is named inside the app, on the screen where you connect it. It is not this one, and the screen for choosing a different target is not built — so a shop on this help desk cannot wire the handover up from our panel today. Where no ticket opens, the handover waits in the Refik inbox exactly as it would with the connection switched off. | |
| Where the answers come from | Your Shopify catalogue, your stock and your store policies, plus hand-written question-and-answer records with a cap of three hundred. There is no URL crawl, no document upload and no ingestion of your own pages or blog. | |
| Response-time targets | Response time is measured and printed as a median and a ninetieth percentile, next to the share of conversations it was measured on. There is no service-level policy behind it: no target time, no threshold, no breach alert. | |
- Channels, their cell is empty. Their channel list was not among the three pages read. Ours is written out because a missing channel is the kind of thing a shop finds out after it has paid.
- A ticket in your help desk, their cell is empty. Whether and how they accept a ticket from an outside app was not among the pages read. The sentence in our column is about our side only: it says what our server can do today, and what it cannot.
- Where the answers come from, their cell is empty. Their knowledge-base feature set was not among the pages read. The only trace of it in our record is the words “1 Docs site” inside the free-plan sentence quoted above, and a line on a price list is not a description of a feature.
- Response-time targets, their cell is empty. Not read. The row is in the table because the gap it names is ours, and a shop weighing the two should meet that gap before it pays rather than in the second month.
- The two trials are not the same scope. Theirs is written against an add-on; ours against the whole plan. They sit side by side because both are what you get before paying, not because they cover the same thing.
- The annual discount figure is not printed. Their pricing page states it as a percentage. No page on this site prints a percentage figure, so the row describes the switch and leaves the number where it was read.
- One of their quotes is cut off. Our record of the add-on sentence stops mid-word and the cell reproduces the cut. Finishing it would mean printing a sentence they did not write.
- 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 per-user price and a per-conversation price answer different questions.
A per-user price asks how many people you need on the other end. It is the right unit when the work is a queue that humans pick up, because then the cost follows the team: add a part-timer for the holidays and the bill moves with them, which is honest and also predictable. A per-conversation price asks something else entirely — how many shoppers started talking. It is the right unit when nobody is meant to pick anything up, when the assistant answers and a person only appears for the questions it refuses to guess at.
That is also why the two are not really alternatives for the same job. A shop whose support arrives through several doors and gets answered by several people has a help desk problem, and a storefront assistant does not solve it: there is no shared queue here, no assignment, no reporting across channels. A shop whose owner is the only person answering, and whose pain is the same nine questions arriving before anyone decides to buy, has a storefront problem — and paying per user for it means paying for a rota of one.
The pricing rows point at the same split from a different angle. On their side, an assistant that resolves a request is an add-on billed by the resolution, sitting on top of the per-user subscription; on ours, the assistant is the whole product and the only thing metered is the conversation. Neither arrangement is cleverer than the other. They are answers to different questions, and the question a shop should ask first is which of the two it is actually paying to fix.
There is a case where both are true at once, and it is common: a shop with a help desk already in place that wants the storefront to stop sending it the easy questions. For that case the handover matters more than the price, and the honest state of ours is in the table. The server can open a ticket in exactly one help-desk vendor, it is not this one, and the settings screen for choosing a target is not built — so today the handover from our side lands in the Refik inbox and stays there until somebody opens it. We are not going to describe moving your existing history across, because nothing in the code does that. 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.
A help desk fits you if support arrives through more than one door — email, a social inbox, a phone line — and more than one person answers it. If you need a shared queue, assignment between people, reporting across channels, or a published help centre your shoppers can search for themselves, that is a help desk’s job and not ours. Our channel list is one channel long, our knowledge records are typed in by hand and capped, and we are not going to pretend either of those is a feature.
We fit you if the questions that cost you money arrive before the order exists: which of these two is right for me, is this in stock in my size, where is the order I placed on Friday, can I send this back. Those are storefront questions, they arrive on a product page while a shopper still has a card in their hand, and answering them needs the catalogue, the stock and the policies of one shop rather than a ticket queue. A price that counts those conversations is the price that follows the thing you are buying.
Both can be true if you already run a help desk and want fewer easy tickets reaching it. Read the handover row before you decide: the connection to this particular help desk is not built, so for now the two would run side by side rather than wired together, and the easy questions would stop at the storefront rather than arrive tagged in your queue.
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 told never to say a refund is approved. If there is nobody to pick it up, no assistant on either side of this table fixes that.