PredictSpring: what a point-of-sale quote should list

A retail lead attaches a website sitemap to a brief titled PredictSpring data migration to Salesforce. The sitemap is the shop a customer uses from a sofa. PredictSpring is the till a colleague uses in a store. The two books can share a customer and a product code. They do not share a transaction. A quote that prices them as one rebuild has merged a counter and a storefront because both can sell a shirt.

PredictSpring is retail point-of-sale software built in the cloud. The announcement completed a purchase. It did not hand you a new website, and it did not retire the commerce product you already operate. If that product is B2C Commerce, it remains the storefront it already is. This page prices the till. The line you can date is this one. "Salesforce completed its acquisition of PredictSpring on September 12, 2024."

#Start from a receipt, not a sitemap

Pick one store you would trust to pilot. Write a single sale the way the colleague at the counter would tell it. The customer is in the shop. They have a product in hand. They pay with a tender you already accept, named by you: card, cash, gift card, or a tender your finance team has already approved. The receipt prints or is sent. Stock for that product moves. If the network drops halfway through, someone in the store already knows what they do. That someone is part of the scope.

A sitemap has none of those facts. It has pages. Pages are a merchandising and a storefront concern. Put the sitemap back in the folder for the storefront quote. On this brief, replace it with the receipt. If you cannot describe the receipt without opening the website, you are still scoping the wrong system.

Write the receipt as fields, not as a picture of a screen. Store. Register or device, in whatever unit you actually deploy. Colleague. Date and time. Lines, with the product code you already use. Tender. Tax the way your finance team already calculates it. A return reference if the sale is a return. The customer identifier if you attach one, and the rule for when you do not. A partner can price a mapping from those fields. A partner cannot price a feeling that the till should feel like the website.

Returns at the counter are their own path. A customer brings a product back with a receipt, without a receipt, or with a web order number. Those three arrivals are three rules. The first looks up a sale you made in store. The second needs a policy your stores already apply, written down. The third crosses into the storefront's order, which is why it must be named as a boundary and not quietly absorbed. If the third is common, it is still a boundary. The till may record that a web return was accepted. The storefront order remains the storefront's record unless you have a separate decision, on the storefront quote, to change that.

#What the quote has to name

Stores in the pilot, and stores you are leaving until later. Count them yourself. This page will not guess how many doors you have. For each pilot store, the devices the colleague uses and whether any of them must work when the shop's network fails. The tenders. The inventory system that must hear about the sale, named by you. The product codes, and who masters them. The tax rules you already run, including a rule that differs by region if that is your business. The hours the store is open, because a cutover at 10 in the morning is a different risk from a cutover after close.

Staff access belongs on the list. Who can discount, and by what authority. Who can open a drawer. Who can void. Those are controls you already live with. A migration that flattens them into one login so the pilot is easy has removed the control. Name the roles. A partner should be able to repeat them back without inventing a new job title.

Customer attachment is optional until you say it is not. Some sales are anonymous. Some carry a loyalty identifier you already issue. Some should match a record you hold in a commerce or a service org. Write which of those you need on day one. Matching every anonymous sale to a person is a different project, with privacy work your counsel should see. Do not let a point-of-sale quote assume that match because a diagram had a customer in the middle.

The commerce org, if you have one, is a named neighbour. Write its name. Write that it is out of this statement of work except for the specific events you truly need to cross, such as a web-order return accepted in store. One crossing is a line. "Integrate commerce" is a second programme.

#What cost means before anyone prices it

Cost is the list you finish before you ask for a number. Licences you already hold for commerce, service, and any retail product on the contract. Leave the prices in the contract. This page has none. Then the work: mapping the receipt, connecting the inventory system you named, connecting payments to the provider you already use, configuring the roles, rehearsing the offline case, training the pilot stores, and sitting with the stores for the first trading days.

Internal hours are a cost. A store manager has to say whether the offline rule you wrote is the one they already use. A finance partner has to agree the tender list. An inventory owner has to agree which movement is a sale and which is a transfer. If those people are absent from the brief, the quote will assume their answers. Assumptions at the counter become shrink, queueing, or a tender you do not actually settle.

Out of scope, on the same page: a new website, a new catalogue, a search rebuild, a replatform of the storefront, a loyalty scheme you have not designed, a payment provider you have not chosen. Each can be a real project. Each gets its own quote. Folding them under PredictSpring makes the fee large and the acceptance test a matter of opinion. Opinion is a poor way to accept a till.

Hardware is a cost only if you are changing hardware. If the devices stay, say they stay, and say who images them. If you need new devices, that is a procurement line with a lead time, not a configuration line. A partner who bundles unspecified hardware into a professional-services fee has mixed two budgets. Split them before you compare proposals.

#Offline is a store problem, not a slogan

Shops lose connectivity. Your colleagues already have a habit for it. Write the habit down before anyone designs a sync. What they may still sell. What they must refuse. How a sale made offline is identified when the network returns, so you do not create it twice. Who is told if the sync fails after close. A design that assumes the shop is always online will be priced as if it were true, and the first wet Tuesday will prove it is not.

The acceptance test for offline is a rehearsal in the pilot store, with the network actually off, not a checkbox on a plan. Time that rehearsal. It is part of the quote. So is the hour after, when the sales reappear and finance looks at them. If you cannot staff that hour, you are not ready to pilot, and the quote should say so rather than hide the gap in a phase called hypercare.

Inventory follows the same discipline. A sale, a return, and a transfer are different events. The system you named must receive the event you mean. A quote that says "stock will update" has not said which stock, in which location, on which delay. Write the location model you already use. If two stores share a back room, say so. If the website sells from the same pile as the shop, that crossing is the boundary again. Name it. Do not imply it.

#Migration services, stated as events

Migration for a till is a map of events and identifiers. Product codes that must match. Tender codes that must match. Store and register identifiers that must remain stable so yesterday's receipt can be found tomorrow. Historical receipts, if you are keeping them, and where they will live. A file of old receipts is an archive. A live transaction is the new path. Price them apart.

Customers and orders from the website are not a till migration. If a web order must be picked up in store, write that flow as its own line, with the storefront remaining the owner of the order until the handoff you define. The handoff has a status both sides can see. It has a person in the store who can complete it. It has a failure when the product is not on the shelf. That failure is a queue, not a silent retry. Silent retries are how a customer is told twice that the product is ready.

Staff moves are in scope when people change stores. A login that worked in one shop and should not work in another is a rule you already understand. Write it. A quote that copies every user into every store so the pilot weekend is calm has chosen convenience over the control. You will live with that choice after the partner has gone.

Payment settlement stays with the provider you named. The till records that a tender was taken. Settlement, chargebacks, and the fee on the card are finance processes you already run. A Salesforce quote that offers to replace your acquirer has left the brief. Send that line back. You may change acquirer one day. You will not decide it in the margin of a point-of-sale implementation.

#The hiring test

People search for the best predictspring Salesforce integration agency and for a consultant to hire. The adjective is not a test. The test is one receipt. Give the partner the pilot store, the tenders, and the inventory system name. Give them nothing else. Ask which record the receipt becomes. Ask what happens when the network fails. Ask which parts of the website they will not touch. Ask which licence they need to see on your contract before they estimate. Ask who in your store accepts the first trading day.

A pass talks about a transaction, a location, a role, and a boundary. The partner asks how many stores are in the pilot, because you might have forgotten to say. The partner separates a counter return from a web return. The partner refuses to price a storefront rebuild on the same line. The partner does not describe a screen they have not opened in your org.

A fail prices "commerce" as one number. It treats the sitemap as the backlog. It promises the till will cover the website. It calls itself the best agency. It adds hardware, loyalty, and search because the word retail appeared in the title. You can still talk. You should not sign.

Run the test on a second case: a web order picked up in store. The partner should slow down and draw the boundary. If they say the till now owns the order, they have changed the storefront's system of record without a decision from you. That is the moment to stop the price.

#The first trading days

Cut over one store, after close, with the way back written down. The way back is the old till still able to take a sale, or a decision you have already made that there is no old till and the store can pause. Both are acceptable. An unstated third option, in which nobody knows, is not. Tell the colleagues what to do when a receipt looks wrong. Give them a person to call who is awake while the store is open.

For those days, read the exceptions, not a dashboard of sales. Voids. Offline sales that synced twice, or not at all. Tenders the provider did not recognise. Inventory movements that landed in the wrong location. A handful of these is a pilot doing its job. A pattern is a rule you missed. Fix the rule before you add a second store. Adding stores multiplies the rule. It does not debug it.

Search and product discovery are a third scope, even when they sit next to commerce in a roadmap. Cimulate and Agentforce Commerce search is that quote. Leave zero-result queries off the till estimate. A shop colleague cannot fix a website search by taking a payment.

#The other searches

The project quote is on predictspring implementation cost. That page does not print a figure. Who bought the company is on what happened to predictspring. The connector is on integrating predictspring with Salesforce. Whether to move is on should I migrate from predictspring. The customer fee is on predictspring licence cost. Who to hire is on hiring for predictspring. This page does not rank an agency.