PredictSpring implementation cost: Salesforce Point of Sale pricing and rollout

Point of sale projects fail in a different way from CRM projects. A CRM defect slows a team down. A till defect stops a queue of customers on a Saturday morning, in front of staff who did not choose the system. That is why a PredictSpring cost estimate has to start with stores and devices, not with licences.

The acquisition itself is simple to state: "Salesforce completed its acquisition of PredictSpring on September 12, 2024." Salesforce's product page now says what it became: "Salesforce acquired PredictSpring to power its modern Point of Sale solution." The same page records the naming change: "Salesforce updated the name of Retail Cloud to Salesforce Point of Sale." So the product you buy is Salesforce Point of Sale, and the price list still uses the Retail Cloud POS label in places. Treat them as one product.

#What PredictSpring was, and why that shapes the cost

PredictSpring was not a back-office tool. It was a mobile point of sale for store associates, with clienteling, endless aisle, store fulfilment and store operations around it. The announcement also made a point that matters for integration effort: "PredictSpring is an existing Salesforce ecosystem partner with several strategic retail customers and is already integrated with Commerce Cloud and Service Cloud."

That pre-existing integration is good news if you already run B2C Commerce and Service Cloud. Your product catalogue, prices, promotions, customer profiles and service cases already live in systems the POS was built to read. If your online store runs on another platform, or your catalogue lives only in an ERP, the integration line grows quickly, because the POS needs the same products, prices and stock that your stores sell.

#What Salesforce publishes about the price

As at October 2026, Salesforce publishes no list price for Salesforce Point of Sale. Its Salesforce POS pricing page offers two models and both say "Contact for Pricing". The Commerce pricing page shows the neighbouring products a POS project usually needs, also on request.

Read the GMV line carefully. The pricing page headlines it as "GMV-Based Pricing" and then describes it as pricing by gross margin value across stores. Gross merchandise value and gross margin are very different numbers for a retailer. Ask your account executive to define the metric in the order form, including whether returns, tax and gift cards count, before you compare it with the order-based model.

The order-based model is described in one line: "Price by orders across stores." That suits retailers with high basket values and modest transaction counts. A convenience-style business with many small baskets may find a value-based model easier to forecast. Model both with last year's store data before you choose.

#What sets the price in a POS negotiation

Because there is no list price, the commercial outcome depends on facts you control. Bring them to the first meeting:

• store count, and how many stores join in each year of the term
• annual store sales, or annual store transaction count, depending on the model
• devices per store at peak trading, since this drives the hardware budget even if it does not drive the licence
• which modules you need on day one: mobile POS, clienteling, endless aisle, inventory, store fulfilment
• whether you already license B2C Commerce, Order Management and Service Cloud, and on which editions
• the countries you trade in, because tax, fiscal receipt rules and payment methods vary

Retailers often negotiate a store ramp: a licence that grows as stores go live, rather than paying for the full estate from the first month. If your rollout is in waves, ask for the ramp to match the waves in writing.

#The work packages of a store rollout

A credible implementation quote for Salesforce Point of Sale is made of packages you can test in one store before you commit the next fifty.

Store discovery. Walk two or three stores of different formats. Record the checkout flows, returns, exchanges, layby or holds, gift cards, staff discounts, price overrides, end-of-day reconciliation and the peripherals in use. Store managers know where the old system is being worked around, and those workarounds are scope.

Catalogue, pricing and promotions. The POS must sell the same item at the same price as the website and the shelf ticket. Map the source of truth for products, prices and promotions, usually B2C Commerce, an ERP or a pricing engine, and the sync frequency. Promotions are usually the hardest part to match exactly.

Customer and clienteling. Decide which customer profile the associate sees, where it comes from, and what consent rules apply to using purchase history in store.

Inventory and endless aisle. Endless aisle depends on accurate stock across stores and warehouses. This usually means Order Management, an inventory service or an ERP feed, plus rules for ship-from-store and click and collect.

Payments. Choose the payment provider and terminals, certify them with the POS, and test refunds, partial refunds, split tenders and offline card handling. Payment certification can take weeks and is outside the software partner's control.

Devices and peripherals. Salesforce's page says you can "Gain the hardware flexibility to deploy on either Android or iOS, to fit your brand preferences or specific store configurations." That flexibility still needs a decision, a device management plan, receipt printers, scanners and cash drawers that work with the chosen platform, and spares.

Offline mode. Every store loses its network eventually. Test what the till does offline, how long it can trade, what it can and cannot refund, and how transactions sync when the link returns.

Finance and ERP posting. Daily sales, tenders, tax and returns must post to the general ledger. Reconciliation rules are usually where finance signs off, or does not.

Training and store rollout. Train by store, on the device, close to go-live. Plan a pilot store, then waves, with floor support for the first trading days and a way back for each wave.

#What drives effort up or down

Effort drops when your catalogue and promotions already live in B2C Commerce, when Order Management already holds inventory, and when one payment provider covers every market. It rises with each extra country, each legacy loyalty scheme, each promotion type the old till handled with custom code, and each store format with different processes.

Returns deserve special attention. A retailer that accepts online returns in store, and in-store purchases back by post, needs the POS, Order Management and the ERP to agree on one order record. That is often the single most complex integration in the project.

Peak trading also shapes the plan. Most retailers freeze store changes for weeks around their biggest sales periods. A rollout that would cross that freeze either stops or starts later, and both change the services cost.

#Data migration: what moves off the old till

A POS data migration quote is smaller than a CRM migration in volume and larger in consequence. Most transaction history can stay in the old system or the data warehouse for reporting. What cannot stay behind is anything a customer can walk in and ask about tomorrow.

That list is short and unforgiving. Open gift card and store credit balances. Layby or held orders with deposits paid. Open special orders and repairs. Loyalty points, if the POS was the system of record for them. Customer profiles that associates rely on for clienteling, with the consent flags that allow their use. Each of these needs a reconciled count before and after the move, signed by finance or the loyalty owner, and a plan for the trading day of cutover, when the old and new tills may both take money.

Ask bidders to price each of these objects as its own line, with the reconciliation report they will hand over. A quote that says "data migration included" without listing gift cards and laybys has not looked at your stores.

#A phased plan that keeps the cost visible

The cleanest way to control a POS budget is to make each phase earn the next one.

Phase zero, the data pack. Store formats, volumes, devices, payment provider, catalogue source and the open-balance objects above. This is what Salesforce and every partner should price from.

Phase one, the pilot store. One store, ideally a mid-sized format with a manager who will tell you the truth. Prove checkout, returns, payments, offline trading and end-of-day posting through at least one busy weekend.

Phase two, the first wave. A handful of stores across formats, with floor support and a rollback rehearsed. Measure queue time, refund errors and reconciliation breaks, not just go-live dates.

Phase three, the estate. Larger waves on a fixed cadence, outside peak trading freezes, with the licence ramp following the stores.

Phase four, the extras. Clienteling, endless aisle and ship-from-store are often where the business case lives, but they depend on clean inventory and customer data. Price them after the till is stable, when you know what the data really looks like.

#Getting comparable quotes

Give every bidder the same store data and ask for prices in the same shape:

• cost per work package, and cost per store wave after the pilot
• the payment provider and terminals they assume, and who handles certification
• their offline test plan, in writing
• which integrations they will build, which they assume already exist, and who owns middleware such as MuleSoft if you use it
• floor support days per wave, and who provides them

Ask each bidder to name one store-level risk they would test first. Partners who have shipped retail POS will usually name returns, promotions or payments without being prompted.

Finally, ask who stands behind the store on day two. A POS partner that disappears after go-live leaves your help desk fielding till faults it was never trained for. Price support for the first trading month separately, with named contacts and response times that match your trading hours, including weekends.

#Costs that are usually left out

• Devices, terminals and peripherals, including spares and a replacement cycle.
• Payment processing fees, which are charged on transactions and sit outside the Salesforce licence.
• Store network upgrades where stores still trade on a single consumer-grade link.
• Mobile device management licences for the tablets or phones.
• Neighbouring licences: Order Management, B2C Commerce or Data 360 credits, if the business case relies on them.
• Licence overlap with the current POS during a multi-wave rollout, which can run for many months.
• Store labour for training, parallel running and stocktakes before cutover.
• Fiscal and tax compliance work in countries with certified receipt or e-invoicing rules.

The pattern across that list is simple: most of it is bought from someone other than Salesforce or your implementation partner. Give each item an owner in the business case, a supplier, and a date by which its price must be known, so the steering group sees the whole cost of a store going live rather than the software line alone.

#Where the other PredictSpring questions live

How the POS fits B2C Commerce and Order Management is on PredictSpring and Commerce Cloud. The acquisition story is on what happened to PredictSpring. Licence questions, including how a store ramp is structured, are on PredictSpring licence cost. The integration surfaces in detail are on integrating PredictSpring with Salesforce. Whether to move off a legacy till at all is on should I migrate from PredictSpring, and how to test a partner is on hire a PredictSpring Salesforce partner.

Our Salesforce consultancy team can help you build the store data pack before you ask Salesforce or any partner for a number, so the quotes you receive are priced on the same facts.