Refik and Salesforce, read on the same day.

Method

Two sides, two dates, and an empty cell that means something.

The right-hand side of every row was read out of Salesforce’s own pages on 10 October 2026. Three pages were fetched — the service home page, the service pricing page and the service features page, at salesforce.com/service and salesforce.com/service/pricing/ — and all three answered directly, with no redirect to somewhere else. Nothing came from an analyst report, a review site or a reseller. The quotes are theirs, word for word, including the spacing of the prices.

One thing about those prices is worth stating before you read them: the pricing page carries a currency selector, and on the day it was read the selector said US Dollar (USD) in plain words. So the dollar figures below are the figures that page prints in dollars, not a number guessed at from whatever currency a visitor happens to be served. That is also the row we could quote their currency list from.

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 was done at the level of the code: a surface is marked as present when it is written, called, reached, and read by something downstream. It does not say the surface was watched working in a live store on that day.

Their page prints five prices, and five prices are not five versions of one thing. The cheapest, $25, is Starter Suite, which the page describes as a CRM suite covering sales, service, marketing and commerce. The one the page itself calls the CRM for service is Core, at $195. Quoting the cheapest number and leaving the tier name out would be arithmetically true and substantially misleading, so every price cell below says which tier it came from, and both of those tiers get their own row.

An empty cell is a third state and it is on purpose. It does not mean the other side lacks the thing. 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 the table, and the reasons are not interchangeable: some are gaps in what we fetched, one is a gap in our own measurement of ourselves.

Three 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 produces a number that looks like a measurement and is not one. There are no reach figures — no traffic, no search position, no count of stores — because none were read for either side. And there is nothing here about how well either assistant answers a shopper, because that was not measured on either side either.

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, and how much of the company those people belong to. It is the right unit when the work is a body of cases that humans own, hand around and report on, which is exactly what their own wording describes: tools to manage cases and resolve issues. The cost follows the team, and that is a feature when the team is the thing doing the work. A per-conversation price asks 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.

The second difference is scale, and it is real rather than rhetorical. The product on the right-hand side of this table starts at a suite that spans sales, service, marketing and commerce, and climbs to a tier its own page calls the complete service platform; it is bought by companies across every trade and configured by people whose job that is. The product on the left is one widget in one storefront. It reads a single store’s catalogue, stock and policies, has one channel, and knows how to open a ticket in exactly one help desk. Saying that smaller is better would be a sales line, not a measurement. What is true is narrower: one of them is sized for a service organisation, the other is sized for a product page.

That is also why they are not straightforwardly alternatives. A company whose support arrives through several doors, whose cases live for weeks, and whose customer record is read by departments that have nothing to do with the storefront has a service platform problem. A storefront assistant does not solve it, and buying one instead would leave the actual work unowned. 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 buying per-user seats for it means paying for a queue nobody is standing in.

There is a case where both are true at once, and it is common enough to name: a company that already runs a service platform and wants the storefront to stop sending it the easy questions. For that case the handover matters more than either price, and here is the honest state of ours. The server can open a ticket in a help desk, there is exactly one target it knows, that target is not Salesforce, and the screen a merchant would use to choose a target is not built. So a shop running Salesforce cannot wire our handover into it from our panel today. The integrations page lists what is connected and what is not, in the same words.

One last difference that the price cells only hint at: what you are committing to. Their second tier prints that it is billed annually and that a contract is required; the tiers above it print that they are billed annually too. Our yearly plan is also paid for the year, and on that plan the per-conversation charge above the band disappears. Those are different kinds of commitment, made with different people, and the place to settle them is each side’s own terms — not a table on a page written by one of the two.