Cimulate implementation cost: B2C Commerce and agentic search

Cimulate built search for retailers that tries to understand what a shopper means rather than matching the words they typed. Salesforce completed the purchase on 3 March 2026. The announcement described Cimulate as providing "an intent-aware context engine purpose-built for retail" and said: "By integrating Cimulate with Agentforce Commerce, Salesforce will enhance how shoppers find, explore, and evaluate products in real time."

Unlike several recent acquisitions, this one turned into something you can point at quickly. On 24 March 2026, Salesforce's Commerce blog introduced "Intent-Aware Search powered by Cimulate" and said: "Cimulate’s CommerceGPT technology will be supported across digital storefronts on Commerce Cloud." Then the July 2026 B2C Commerce release described Agentic Commerce Search, an engine trained on catalogue data, real shopper behaviour and simulated queries, and said of it: "Tightly integrated into B2C Commerce, it optimizes every touchpoint across the buying journey." The release post does not name Cimulate in that passage, but the description, especially the simulated queries, matches what Cimulate was bought for. Confirm with your account executive which name appears on your order form.

So the implementation question is not how to install Cimulate. It is how to switch on, tune and prove agentic search on a B2C Commerce storefront, and what that costs.

#What you pay Salesforce

The Commerce pricing page shows no list prices as at October 2026. Every product on it is marked contact for pricing:

The pricing page does not state the basis on which B2C Commerce is charged, so ask the account executive to put it in writing, including whether any part of the fee is tied to gross merchandise value or order volume. The questions that set the number are: how many sites and brands, how many locales, your expected gross merchandise value, whether Order Management is in scope, and whether Agentic Commerce Search is part of your edition or a separate line.

The Premier Success Plan is the one figure on the page with a published basis: it is priced as a fixed share of net licence fees, so it scales with whatever Commerce contract you sign. Factor it in before comparing totals.

#What a search implementation is made of

1. Search baseline. Export the last few months of site search: top queries, zero-result queries, queries followed by an exit, and conversion by query. This is the evidence for the business case and the yardstick for testing. Without it, "results feel better" is the only test, and it will not survive a peak-trading review.

2. Catalogue attribute work. Intent search reads your product data. If materials, fit, use cases and compatibility live only in images or free-text descriptions, the engine has less to work with. Expect a catalogue clean-up: filling attributes, normalising values, and deciding which fields are searchable. For large catalogues this is the largest package, and it is merchandising work as much as technical work.

3. Rule inventory and retirement. The July release says the engine decodes natural phrasing, long-tail queries and typos without manual synonym lists. That is the promise. In practice, your existing synonyms, redirects, boosts and buries need a review. Some fix vocabulary and can go. Others encode decisions: never show a restricted product to a certain region, always lead with house brands, bury discontinued lines. Those must be kept as merchandiser controls, and the March post says merchandisers keep "all the tools they need to control AI-generated responses". Map every rule to keep or retire.

4. Storefront integration. The work differs by storefront architecture. A Storefront Reference Architecture site and a composable storefront built on the PWA Kit have different integration points. The July release also mentions a new React-based search interface that can be embedded on the storefront and responds to the page and filters a shopper is on. Decide whether you use it or keep your own front end, because that choice moves design and testing effort.

5. Shopper agent and AI channels. The release says Agentic Commerce Search is integrated into Agentforce Shopper Agent. If you run or plan a shopper agent, test search and agent together. If you plan ChatGPT product discovery, the same release describes mapping B2C Commerce fields to OpenAI's catalogue standards with automated daily syncs, and Salesforce said the Agentic Commerce Protocol integration would be generally available in the northern summer of 2026. That is a separate feed with its own field mapping and approvals.

6. Testing. Run a controlled comparison where you can: old search against new on a share of traffic, with conversion, revenue per search and zero-result rate measured. Test the edge cases too: product codes, sizes, brand names, misspellings and regulated products.

7. Cutover and peak-trading timing. Do not switch search engines in the weeks before a major trading period. Plan go-live for a quiet window and keep the old configuration available to restore.

8. Merchandiser training. The job changes from writing rules to steering an engine and reading its results. That needs training and a short playbook. The playbook should cover how to pin or exclude a product, how to read the search reports, what to do when a query returns something embarrassing on a Saturday morning, and who to call when the answer is not obvious. Without it, the team will quietly rebuild the old rules elsewhere, and the saving the project promised will drain away within a few months.

#What drives the effort up or down

Catalogue size and attribute coverage. A few thousand well-attributed products is a short project. Hundreds of thousands of products from many suppliers, each with different attribute habits, is a long one.

Number of sites and locales. Each language needs its own testing. Each site may have its own rules. Multiply accordingly.

Rule debt. A storefront with a handful of synonyms is quick to review. One with thousands of accumulated rules, many undocumented, needs someone to decide which still matter.

Storefront architecture. A heavily customised front end, or a third-party search provider currently wired into templates, adds removal and integration work.

Regulatory constraints. Age-restricted, prescription or region-restricted products need explicit controls that are tested and evidenced.

#Getting quotes you can compare

Give each bidder the same pack: storefront architecture, number of sites and locales, catalogue size, a sample of product records, your current search provider and rule count, and three months of search query data.

Ask each partner how they will measure success and over what traffic split. Ask them to sort a sample of your zero-result queries into causes: missing attribute, vocabulary, genuinely unavailable product, or typo. A partner who can do that on a sample during the sales process understands the work. Ask which rules they would keep and why. Ask for the catalogue clean-up as a separate line, with an estimate of products touched.

Ask Salesforce, separately, whether Agentic Commerce Search is included in your edition, priced as an add-on, or metered, and what happens to your current search provider contract if you switch.

#Costs that are commonly left out

• Catalogue enrichment by merchandisers and suppliers, which is often unbudgeted labour.
• Overlap with your current search provider, if you run both during testing or the contract has notice terms.
• Testing traffic and analytics setup to measure the comparison properly.
• Translation and locale testing for every language you sell in.
• The ChatGPT or other AI-channel feed, which is its own mapping and approval work.
• Premier support, priced as a share of net licence fees, if you need faster response during cutover.
• Sandbox and staging capacity for testing with full catalogue data.
• Post-launch tuning for the first trading cycles.

#What changes in the running cost

A search change alters the ongoing cost of running a storefront as well as the build. On most mature sites, someone spends part of every week maintaining search: adding synonyms when a new trend name appears, writing redirects for campaign terms, fixing a zero-result query a customer complained about. If the engine handles vocabulary and typos itself, some of that effort goes away. That is a real saving, but it is labour, not licence, and it only appears if the merchandising team actually moves its time onto something else.

Other running costs appear in its place. Someone must watch the measures that matter, mainly zero-result rate, search conversion and revenue per search, and investigate when they move. Someone must keep product attributes complete as new ranges arrive, because the engine depends on them and suppliers rarely send clean data. And the July release says the engine can also rank category pages dynamically, using real-time shopper behaviour together with your core business targets. If you turn that on, category pages stop being fixed lists that a merchandiser arranges once a season. That is a change to how trading teams work, and the business targets the engine balances against need an owner who sets and reviews them.

Ask each partner for a view of the steady-state effort after go-live, not only the project cost. A proposal that shows a build price and nothing after it has not thought about the year you will actually be paying for.

#Risks particular to switching search

Search is the part of a storefront where shoppers with the clearest intent arrive, so mistakes are expensive and visible. Four risks are worth naming in the plan.

The first is exact-match searching. Trade customers and repeat buyers often type product codes, part numbers or exact model names. An engine tuned to interpret natural language must still return the exact product first for those queries. Put a set of code searches in the test pack.

The second is brand and supplier commitments. Some placements exist because of a supplier agreement or a brand decision, not because they are the most relevant result. If those commitments live in boost rules, they need an explicit control after the switch.

The third is explainability. When a merchandiser asks why a product appears third, someone needs an answer. Confirm what reporting and controls the merchandising team will have before go-live, and train them on it.

The fourth is timing. A regression found in a quiet month is an inconvenience. The same regression found during a major sale is lost revenue that no licence saving recovers.

#Where the other Cimulate questions live

The licence question on its own is on Cimulate licence cost. How search should be scoped against the storefront you already run is on Cimulate and Agentforce Commerce. The acquisition is covered on what happened to Cimulate, and the fields search may read are on integrating Cimulate with Salesforce.

If you were a Cimulate customer before the acquisition, perhaps on another commerce platform, should I migrate from Cimulate covers the choices. When you are ready to brief a delivery team, hire a Cimulate Salesforce partner lists the tests to set.

For a budget holder the summary is short. B2C Commerce is quote-only, so get the search capability named and priced on the order form. Then put most of the services budget into the catalogue and the rule review, because an intent engine can only find what the product data describes.