# PredictSpring implementation cost: Salesforce Point of Sale pricing and rollout PredictSpring now powers Salesforce Point of Sale. Salesforce prices it on request, by value transacted or by POS orders across your stores, and most of the project cost sits in stores, devices, payments and catalogue sync. **Published:** 2026-06-04 **Canonical:** https://synconai.com/predictspring-salesforce-implementation-cost **Author:** SynconAI Architecture Team ## In short Salesforce Point of Sale, the product PredictSpring now powers, is quote-only as at October 2026. Salesforce prices it either on a GMV measure or on POS orders across your stores, and its Commerce price card starts it at 25 stores. The implementation cost is a store rollout: catalogue and pricing sync, payments, devices, offline testing, Order Management for endless aisle, and staff training by wave. ## Sources - **Salesforce Signs Definitive Agreement to Acquire PredictSpring** (retrieved 2024-09-12) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-predictspring/ > Salesforce completed its acquisition of PredictSpring on September 12, 2024. - **Point of Sale** (retrieved 2026-10-11) https://www.salesforce.com/commerce/point-of-sale/ > Salesforce acquired PredictSpring to power its modern Point of Sale solution. - **Point of Sale** (retrieved 2026-10-11) https://www.salesforce.com/commerce/point-of-sale/ > Salesforce updated the name of Retail Cloud to Salesforce Point of Sale. - **Salesforce POS Pricing** (retrieved 2026-10-11) https://www.salesforce.com/retail/cloud-pos/pricing/ > Price by orders across stores. - **Point of Sale** (retrieved 2026-10-11) https://www.salesforce.com/commerce/point-of-sale/ > Gain the hardware flexibility to deploy on either Android or iOS, to fit your brand preferences or specific store configurations. - **Salesforce Signs Definitive Agreement to Acquire PredictSpring** (retrieved 2024-09-12) https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-predictspring/ > PredictSpring is an existing Salesforce ecosystem partner with several strategic retail customers and is already integrated with Commerce Cloud and Service Cloud. ## What to take away - PredictSpring is sold today as Salesforce Point of Sale, the product Salesforce renamed from Retail Cloud. It has no published list price. - Salesforce offers two pricing models, a GMV measure or POS orders across stores, and its Commerce price card starts the product at 25 stores. - The licence is rarely the biggest number. Devices, payment terminals, payment processing, store network and catalogue integration usually decide the budget. - Quote a POS rollout by store wave, with a pilot store, an offline test plan and a rollback for each wave, not as one national go-live. ## The guide 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](https://www.salesforce.com/retail/cloud-pos/pricing/) offers two models and both say "Contact for Pricing". The [Commerce pricing page](https://www.salesforce.com/commerce/pricing/) shows the neighbouring products a POS project usually needs, also on request. | Product | Published price | What sets the price | | --- | --- | --- | | Salesforce Point of Sale, GMV-based | Contact for pricing | Value across stores, metric to be defined | | Salesforce Point of Sale, order-based | Contact for pricing | Number of POS orders across stores | | Commerce price card for POS | Contact for pricing | Listed as starting at 25 stores | | Commerce Cloud B2C Premium | Contact for pricing | Listed with 100 sites and 3,500 price books | | Salesforce Order Management Growth | Contact for pricing | Omni-channel inventory up to 50 locations on this tier | | Salesforce Payments | Contact for pricing | Payment volume, bring your own Adyen account | 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](/predictspring-commerce-cloud). The acquisition story is on [what happened to PredictSpring](/what-happened-to-predictspring). Licence questions, including how a store ramp is structured, are on [PredictSpring licence cost](/predictspring-salesforce-licence-cost). The integration surfaces in detail are on [integrating PredictSpring with Salesforce](/integrating-predictspring-with-salesforce). Whether to move off a legacy till at all is on [should I migrate from PredictSpring](/should-i-migrate-from-predictspring), and how to test a partner is on [hire a PredictSpring Salesforce partner](/hire-predictspring-salesforce-partner). Our [Salesforce consultancy](/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. ## Questions ### Does Salesforce publish a price for Salesforce Point of Sale? No. As at October 2026 both pricing models on the Salesforce POS pricing page say "Contact for Pricing". One is headed GMV-based pricing, the other prices by POS orders across stores, and the Commerce price card lists the product as starting at 25 stores. ### Is PredictSpring the same product as Salesforce Point of Sale? Salesforce says it acquired PredictSpring to power its modern Point of Sale solution, and that it renamed Retail Cloud to Salesforce Point of Sale. Some Salesforce pages still use the Retail Cloud POS label, but they describe the same product. ### Which pricing model suits our stores, GMV or order-based? It depends on your basket profile. High-value, low-volume stores often prefer an order-based model, while many small baskets can make a value-based model easier to forecast. Ask Salesforce to define the value metric in writing first, because its page describes it as gross margin value. ### What usually costs more than the POS licence? Devices, payment terminals, payment processing fees, store network upgrades and integration of catalogue, promotions and inventory. Payment certification and returns across online and store channels are the work packages most likely to stretch the timeline. ### Should we roll the POS out to every store at once? No. Start with a pilot store, prove offline mode, payments, returns and end-of-day reconciliation, then roll out in waves with floor support and a way back for each wave. Ask for a licence ramp that matches the waves. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).