Most brands struggling with B2C Commerce do not have a platform problem. They have a catalog that cannot be merchandised, a checkout built for desktop, and personalisation running on data that cannot support it. We fix the architecture underneath, then the numbers move.
Trusted by 500+ organizations — including retail, DTC, luxury and hospitality brands running storefronts on Salesforce with Twopir Consulting.
Built for Storefronts That Convert
The platform is rarely the problem. The catalog design, the checkout flow and the integration layer underneath are. Each of these is an architecture decision made at launch and paid for every month afterwards.
Shoppers add to cart and vanish. It is usually a combination of slow pages, fragmented payment options and a guest flow that asks for too much before it gives anything back — and each day it goes unfixed is revenue landing on a competitor's balance sheet.
Merchandisers cannot launch a promotion without an engineering ticket. Variations are set up differently across categories and attributes disagree between regions. The catalog was configured for launch day, and the operational debt compounds with every new product line.
Recommendations are live but the lift is marginal and Predictive Sort does not reflect what people actually buy. The problem is not the AI — the catalog, the event tracking and the customer data model were never designed to feed it.
Integrations pass in staging and fail at peak. Orders drop between the storefront and the ERP, service cannot see status in real time, and inventory does not reconcile until the overnight batch — by which point you have oversold three SKUs.
Your best customer contacts support and the agent has no purchase history; marketing sends a win-back to someone who ordered yesterday. Commerce, service and marketing hold three separate truths about one person, and retention campaigns fire into the dark.
Most traffic is on a phone, Core Web Vitals are failing, and key product pages are slow to first byte. The storefront was designed for desktop and retrofitted. Page speed is not a developer concern here — it shows up in the monthly revenue number.
Salesforce B2C Commerce is an enterprise commerce platform for consumer brands and retailers running high-volume, often multi-site digital storefronts. It covers the whole buying lifecycle — product discovery, catalog browsing, personalised recommendations, checkout and payment, order handoff, and post-purchase communication — and it is built to hold under seasonal load rather than average traffic.
One boundary worth stating early, because it is the most common confusion in this category: B2C Commerce is not the same product as Salesforce B2B Commerce or D2C Commerce. B2C Commerce descends from Demandware and runs its own architecture — cartridges, SFRA, and the Salesforce Commerce API. B2B and D2C Commerce are built on the core Lightning platform and are a genuinely different implementation. A partner who treats them as interchangeable will scope your project wrong, and this page is about B2C.
What Salesforce ships is a commerce engine. What decides whether it converts is the catalog model, the checkout flow and the integration layer underneath it — which is the work Twopir Consulting is engaged to do. Commerce also never stands alone: retention runs through Marketing Cloud, post-purchase support through Service Cloud, and the unified customer profile behind both through Data 360. See Salesforce services for how the layers fit together.
This choice sets your performance ceiling, your build cost and the front-end capability you need to hire for. We make it on your team and your traffic, not on a reflex to recommend the newer option.
| Criteria | SFRA | Composable Storefront | Hybrid |
|---|---|---|---|
| What it is | Salesforce's server-rendered Storefront Reference Architecture, with cartridges. | Headless React front end on PWA Kit, running on Managed Runtime against the Commerce API. | Composable for the pages that need it, SFRA for the rest, on one commerce engine. |
| Mobile performance | Workable, but there is a ceiling you will eventually meet. | Materially better Core Web Vitals and app-quality feel. | Best where it matters most — usually product pages and checkout. |
| Front-end skills needed | Manageable in-house footprint; a smaller specialist market. | Real React capability, in-house or retained, on an ongoing basis. | React for the composable surfaces, plus SFRA maintenance alongside. |
| Time to market | Fastest to a working storefront. | Longer initial build; front-end changes are faster afterwards. | Phased — you ship, then migrate the surfaces that justify it. |
| New platform capability | Supported, but investment is going to composable. | Where new Commerce API and agentic capability lands first. | Available on the composable surfaces as you move them. |
| Our usual advice | Right when speed to launch matters most and no React team exists. | Right when mobile conversion is the constraint and the team can carry it. | Right when SFRA works but one journey is costing you money. |
Three genuinely different jobs. On this product the middle one is the most common — the storefront is live, it works, and conversion never reached the number the business case assumed.
For brands launching or replatforming onto B2C Commerce
A new storefront, or a move from another commerce platform. We map the buying journey and design the catalog model before building anything, because those two decisions determine what the storefront can be asked to do later.
Delivered with configuration and standard cartridges. Custom cartridges, bespoke React components and non-standard integrations are scoped separately — we identify at design time which ones you will need rather than discovering it mid-build.
For live storefronts converting below the business case
Our most common entry point. The site works, merchandisers cannot operate it without engineering, Einstein is producing noise, and checkout loses more carts than it should. We audit and fix the causes rather than redesigning the surface.
A rescue works inside your live storefront, without a trading freeze you did not agree to. Where the catalog model itself cannot support the range you now sell, we say so and scope that rebuild honestly rather than tuning around it.
For teams extending or re-platforming the front end
Custom development for what configuration cannot reach: bespoke cartridges, composable migration, and the integration work that has to be reliable because a failed order sync is a customer service contact.
Every custom cartridge is something you own through every platform release. We argue each one against the standard alternative in writing, because custom code in a storefront is the most expensive thing here to carry over time.
Every capability below is designed around how your customers actually buy and how your team actually operates the storefront — not around the platform's default configuration.
Production storefronts on SFRA or Composable Storefront, built so the people who operate them daily can do it without engineering support — and so mobile performance is a build specification rather than a later remediation.
A catalog structured for the range you will have in three years, not the one you launched with — and structured so merchandisers can run promotions and collections themselves.
Checkout is where the revenue is won or lost. We redesign the flow for conversion — less friction, a real guest path, accelerated payment options, and an experience that holds on a mid-range phone.
Recommendations, Predictive Sort and search relevance implemented on a data model designed to support them. The gap between a recommendation nobody clicks and one that lifts order value is almost always the catalog and the event schema, not the algorithm.
Orders that flow from checkout to fulfilment to tracking without manual intervention, and inventory that is accurate at the moment someone adds to cart rather than after last night's batch.
A written assessment of what is costing you conversion, and the migration work that platform deprecations now force — including moving an integration layer off OCAPI and onto the Commerce API.
A stale inventory feed oversells; a dropped order becomes a support contact. Each integration below states its purpose and which direction the data actually moves.
Inventory positions and pricing in, orders and financial records out. The freshness of the inbound leg is what stops you selling stock you do not have.
ERP ⇄ commerce · bi-directionalThe handoff from a placed order to a picked one, with the status write-back that lets a customer — and a service agent — see where it is.
Order out ⇄ status back · real timeCard, wallet and instalment providers wired with proper error states, because a failed payment that fails silently is indistinguishable from an abandoned cart in your analytics.
Checkout ⇄ provider · authorise and capturePurchase and browse behaviour out to retention journeys — abandoned cart, win-back, replenishment — triggered on what someone actually did rather than a static list.
Commerce → marketing · behavioural triggersOrder history surfaced on the case so an agent opens a conversation already knowing what was bought and where it is — instead of asking the customer to repeat it.
Order history → case view · on loadThe unified profile that lets commerce, marketing and service stop holding three separate truths about one customer — and the grounding personalisation quality ultimately depends on.
Commerce ⇄ unified profileThe middleware layer where retry logic and error visibility matter — a silently failed order sync is the one failure mode that reaches the customer before it reaches you.
Middleware ⇄ orchestrated, with retryRatings on the product page and loyalty balance in the cart — both are conversion surfaces, and both need the write-back that keeps points and reviews attached to the right order.
Platform ⇄ storefront · display and accrueA focused build covering storefront, catalog, checkout, payments and core order integration typically runs 12–16 weeks. A full multi-site, multi-region build with custom SFRA or composable development, Einstein activation and ERP connection runs 20–32 weeks.
Before anything is built we map the journey shoppers actually take — discovery, product page, cart, checkout, post-purchase, return — with your merchandising, marketing and operations teams. The output is a blueprint: site architecture, catalog data model, attribute strategy, search configuration, promotion framework and integration requirements.
Production build on SFRA or Composable Storefront, chosen on your team's capability and your customer experience requirements rather than on which is newer. Performance is in the build specification from day one — Core Web Vitals, image handling, lazy loading and CDN configuration are not a later remediation project.
Einstein recommendations, Predictive Sort and search relevance implemented across the journey — but only after the catalog attribute model and behavioural event schema are designed to feed them. Personalisation on a poorly structured catalog teaches customers to ignore the feature, which is harder to undo than never shipping it.
ERP, order management, warehouse, marketing and service connections built for real-time flow on the Commerce API. After go-live we run a structured optimisation sprint — funnel analysis, checkout testing, Einstein tuning on live behaviour — because launch is the start of the commerce operation, not the end of the engagement.
Two engagements, and the numbers they moved. Each figure is scoped to the storefront it was measured in — these are results from specific builds, not a promise about yours.
Luxury real estate buyers do not behave like standard e-commerce shoppers, and Twopir understood that from the first week. They built a commerce environment where every listing, every inquiry form and every recommendation was designed around a high-consideration buyer journey. Our digital conversion rate for qualified inquiries improved by 40% in the first quarter after launch.
Multi-site B2C Commerce build for a high-consideration buyer journey.
Our previous implementation had Einstein recommendations turned on and producing suggestions that were frankly embarrassing — products customers had already bought, or items with no inventory. Twopir rebuilt the event tracking schema and the catalog attribute model from scratch. Within eight weeks recommendation click-through went from 1.2% to 6.8%.
Einstein activation and commerce rescue on a live storefront.
If one of these reads like your quarter, the first call will be short and specific rather than a platform overview.
Catalog management is slow, personalisation is not delivering, and checkout conversion sits below benchmark. The storefront was built to go live, not to be operated — and the operating cost of that shows up every month.
Several storefronts across markets or brands, each its own implementation with its own technical debt. We architect environments that share catalog infrastructure, personalisation data and order logic while keeping market-specific experiences intact.
A high-consideration journey needs a different architecture — how products are presented, how the checkout behaves, how post-purchase and concierge service connect. See our real estate and hospitality practices.
Multi-currency, multi-language, local payment methods, regional tax and localised promotions — layered onto a platform already trading in your home market, without destabilising it while you do.
A live storefront is the vehicle. Conversion, order value and whether merchandisers can operate it without filing a ticket are the destination — and those are visible months after go-live, not on launch day.
Most partners will build you a storefront. Fewer will tell you the catalog data model is why your personalisation underperforms, and then redesign both. The attribute and event architecture is where a 1% recommendation click-through becomes a useful one.
Composable is genuinely better for mobile performance and genuinely more expensive to own. If the React capability is not in your building and there is no budget to retain it, we will recommend SFRA or a hybrid and explain exactly why.
If launching a promotion needs an engineering ticket, the storefront has failed regardless of how it looks. We design the catalog and promotion framework so the people who operate it daily can, and we test that with them before go-live.
Retention, service and the unified customer profile are not adjacent projects — they are why a repeat purchase happens. Twopir Consulting delivers across Marketing Cloud, Service Cloud and Data 360, so the seams are designed rather than integrated afterwards.
OCAPI is deprecated and new capability is landing on the Commerce API only. Twopir Consulting has delivered Salesforce for 12+ years, and part of that job is telling you which platform clock is running before it becomes an incident.
Salesforce B2C Commerce is an enterprise commerce platform for consumer brands and retailers running high-volume, often multi-site storefronts. It covers the full buying lifecycle — discovery, catalog browsing, personalised recommendations, checkout and payment, order handoff and post-purchase communication. It is a genuinely different product from Salesforce B2B Commerce and D2C Commerce, which is the most common confusion in this category. B2C Commerce descends from Demandware and runs its own architecture of cartridges, the Storefront Reference Architecture and the Salesforce Commerce API; B2B and D2C Commerce are built on the core Lightning platform. A partner who treats them as interchangeable will scope the project wrong, so it is worth confirming early which one a proposal is actually about.
Yes, in marketing terms. The product started life as Demandware, became Salesforce B2C Commerce Cloud after the acquisition, and since Dreamforce 2025 has been marketed as Agentforce Commerce alongside the wider Agentforce rebrand. The underlying technology has not changed name or shape: cartridges, the Storefront Reference Architecture, the Composable Storefront and the Salesforce Commerce API are all still what you actually build on, and documentation still refers to B2C Commerce throughout. In practice you will see all three names in circulation for some time, so it is worth using more than one when searching for documentation or comparing partners.
The honest answer depends less on the platforms than on your team. SFRA is Salesforce's server-rendered storefront framework: faster to launch, lower complexity, a manageable internal footprint, and a performance ceiling you will eventually meet. Composable Storefront is the headless option — a React front end built on PWA Kit, running on Managed Runtime against the Commerce API — which delivers materially better mobile performance and front-end flexibility, and requires real React capability on an ongoing basis. The question that usually settles it is who maintains the front end in eighteen months. If that capability is not in the building and there is no budget to retain it, a well-built SFRA storefront will outperform a composable one nobody can safely change. A hybrid is very often the right middle: migrate the journey that is costing you conversion, and leave the rest alone.
Yes, and it is now a migration with a clock on it rather than a backlog item. The Open Commerce API was deprecated in April 2026, and from 1 September 2026 OCAPI settings are no longer made available for realms provisioned for new customers. Existing implementations continue to receive security updates for a further period under Salesforce's deprecation policy, so nothing breaks overnight — but OCAPI is maintenance-only, and new platform capability including the agentic merchandising work lands on the Salesforce Commerce API alone. Practically that means an OCAPI-based integration layer will slowly cut you off from new features while the migration cost stays roughly constant, so it is better done deliberately than under pressure. Checking which APIs your integrations actually use is the first thing we do in an audit. Separately, Managed Runtime stopped supporting non-HTTPS proxy configurations on 31 August 2026, which is worth confirming if nobody has looked recently.
A focused implementation covering storefront build, catalog setup, checkout configuration, payment integration and core order management connection typically runs 12 to 16 weeks. A full multi-site, multi-region build with custom SFRA or composable development, Einstein activation, marketing integration and ERP connection typically runs 20 to 32 weeks, and complex international deployments with several storefronts, languages and fulfilment networks extend further. The variables that move the range most are catalog complexity, how many fulfilment paths you support, and whether the integration layer needs migrating as part of the work. We define scope, timeline and milestones before any build begins.
Usually yes, and this is our most common commerce engagement. Underperformance almost always traces to the same handful of causes: a checkout flow that asks too much too early, mobile page performance that fails Core Web Vitals, a catalog and attribute model that cannot feed personalisation properly, or an order integration that is unreliable enough that customers notice. We audit the architecture, catalog structure, Einstein configuration, integration health, checkout flow and page performance, then fix the causes rather than redesigning the surface. A full rebuild is warranted only when the catalog model genuinely cannot support the range you now sell — and we will tell you plainly if that is where the assessment lands, because tuning around a structural problem wastes a quarter.
Almost always because the data underneath cannot support it. Recommendations and Predictive Sort learn from your catalog attributes and behavioural event stream, so if products are attributed inconsistently across categories, or the event tracking schema was never designed for it, the models return confident but irrelevant suggestions — recommending something a customer already bought, or an item with no stock. Switching the features on takes an afternoon; making them useful is a catalog and data modelling job. The difference is visible in click-through: a well-structured model produces recommendations customers act on, while a poor one produces a rate low enough that shoppers learn to ignore the feature entirely, which is harder to recover from than never shipping it. We assess that readiness before activation and will say when the right sequence is to fix the catalog first.
We audit the storefront you already have — catalog structure, checkout flow, Einstein configuration, integration health including your API exposure, and Core Web Vitals — and hand back written findings with prioritised recommendations. If a rebuild is not warranted, that is what it will say.
Response within 24 hours · We start with diagnosis, not a sales call · Contact the team
