Skip to content
platform

Portals · by profile

Complex Retail

There is a kind of operation that sells to businesses and to end consumers at the same time, with stores spread across the country, a large catalogue, counter service, field sellers and local stock in every market. From the outside it looks like retail. Underneath it is a business-to-business operation, with customer groups, invoiced credit, tax by purchase purpose and pricing policy that changes by region. It is the profile where an ordinary e-commerce does not fail at the shop window, it fails beneath it.

Complex Retail hero: the region and price configured for each market decide which store serves the customer's address on the B2B2C portal.
Illustrated B2B2C portal: resellers and consumers enter the same portal, the customer group loads at entry and each one sees their own price.
Businesses and consumers at the same address. Segmentation happens at identification: resellers see wholesale, consumers see retail, and nobody releases a price table for each new account.

Where ordinary e-commerce stops serving

An e-commerce is excellent when price is a stored value: one number per product, one stock, one checkout. In this profile price is not a value, it is the result of a function whose inputs are stock origin, logistics, volume, terms, payment method and the identity of the buyer. No shop window solves that with form fields, because the problem is not displaying the price, it is deriving it.

The inverse holds too, and it is part of the positioning: if your operation has fixed pricing, single stock and a simple checkout, there are cheaper options than CWS Platform, and the honest recommendation is to use one of them. This profile exists for those with business-to-business complexity underneath consumer selling.

Comparison between a price stored in a field of ordinary e-commerce and a price derived by rule from stock, freight, volume, terms and buyer.
Price is not a value, it is a function. In ordinary e-commerce the price is a stored value. In this profile it is the result of a rule: stock origin, logistics, volume, terms and who is buying.

The flattened price nobody recorded as a decision

A large share of networks arrived at the same place by a similar route: keeping a different price per branch, crossed with price per customer, per category and per term, became impossible to administer, so the table was levelled. The flattening is a systems workaround, but it is lived as though it were commercial policy, and margin is given away before any negotiation starts.

Its most visible effect is the digital channel's price staying tied to stock origin, so the website starts undercutting the counter of a store in the same network. CWS Platform decouples the two: the customer pays the price of the store nearest the delivery address, even when the product ships from the distribution centre, and tax is still calculated item by item, from the change of state and the purchase purpose (resale, industrialisation or consumption).

Configurable price origin: the product ships from the DC, but the customer pays the price of the store nearest the delivery address, with tax per item.
The website does not undercut the counter. Stock can come from the DC while the price follows the store nearest the customer. The price origin is the network decision, not a side effect of the system.

The three layers of a portal, and how many your project uses

A CWS Platform portal is configured in three layers, one inside the other. The portal layer belongs to the owner: it designs the ecosystem, deciding which stocks exist, which stock serves which customer and which seller serves from which stock, and it sets the general financial rules, the default logistics options, the integrations and the payment methods. The store layer sits below it: these are the invited stocks, from the network itself or from third parties, and each store receives orders, takes part in promotions and configures its own logistics, freight, payment methods and campaigns, within the freedom the portal granted. The warehouse layer sits inside the store, and exists when that store has several stock points.

For a network with distinct markets, the recommendation is for each market to join as a store, because it is the layer with the most functionality and flexibility. The warehouse pays off when the network creates an internal store and runs its own warehouses beneath it: service gets simpler, sellers sell across several stores and there is one campaign for all of them. How many layers come in is a project decision, and that choice is what makes the tenth market cost less than the second: opening a market becomes parameterising a store rather than running a project.

For a manager, what matters is what this nesting preserves. The market's autonomy is real, and it is bounded by a central decision. Decentralising configuration without losing governance is the design, not a welcome side effect of it.

Complex retail portal layers: central rules in the portal, each market as a store, warehouses inside the store and a new market added by configuration.
Opening a market is configuring a store. Each market joins as a store, with its warehouses underneath, and the portal sets how far autonomy goes. That is why the tenth market costs less than the second.

What the platform does, in practice

Price origin, configurable

The price can follow the store nearest the delivery address, even when the item ships from the distribution centre, or follow the stock origin. Both exist, and the website only undercuts the counter of a store in the same network if someone decides it should.

Invoicing, multi-warehouse and tax per item

Who invoices is a configuration: the store, which is the default for a multi-store portal, or the warehouse, recommended when the warehouses share one owner. Price by warehouse, and ST, ICMS and other taxes calculated item by item, from the change of state and the purchase purpose (resale, industrialisation or consumption).

Store pickup tied to the warehouse

Each pickup point is linked to the warehouse that actually holds the item, with its own opening hours and days. When choosing the store the customer sees the distance to their postcode, and only the stores that hold the item for pickup.

Service region per store

Coverage defined per unit, by postcode range, defined to avoid two houses in the same network serving the same address.

Customer group at identification

The customer identifies themselves and loads their group, and with the group the pricing rules and terms that apply there, plus their own credit limit. A reseller sees wholesale, a consumer sees retail, with no manual release per account.

Campaign and banner by customer group

Coupons, promotions and messaging segmented by group and by price tag, decided at store level where central policy allows.

Counter and field on the same engine

In-person service and the field seller run on the same rules as the portal, with each seller's discount limit applying to every concession.

Unified catalogue without flattening the banner

Each banner can operate as its own store on the same portal, with its own assortment and rules, instead of having its commercial difference dissolved into a single catalogue.

The rules live in the Commerce Rules Engine (CDL Workspace) and reach the price through Contextual Pricing (Pricing Engine). Stock across markets comes from Distributed Inventory (Inventory Hub), delivery and pickup from Shipping & Fulfillment (Logistics Engine), credit and tax from the Credit-First B2B Checkout (Checkout & Payments), campaigns by group from Commerce Marketing & Promotions (Marketing Suite), and counter and field from the Assisted Selling Platform (Sales Hub).

Illustrated phone screen for choosing a pickup store: only stores holding the item appear, with distance to the postcode and hours, each tied to its warehouse.
Pickup at the right store. Customers only see the stores that hold the item for pickup, with the distance to their postcode, and each pickup point answers to the warehouse that really holds the stock.

By decision-maker angle

Network owner or CEO

The pain: The same product shows three prices: the portal, the store counter and the marketplace where the company also sells. The customer notices before anyone internally does.

What changes: One policy, with the difference between channels being a declared decision rather than a consequence of systems that do not talk. Price becomes an argument again instead of an embarrassment.

CFO

The pain: The table was flattened because keeping price per branch crossed with price per customer became impossible to administer. The flattening was a workaround, and nobody recorded it as a commercial decision.

What changes: Real granularity becomes administrable again, because the rule lives in the engine and not in the head of whoever administers it. Price by store and by warehouse, by customer group, by term and by campaign coexist without becoming manual work.

Store manager

The pain: Wants a campaign in their own market, terms that match local competition, and a pickup promise the store can keep. Today that depends on someone at head office building an exception.

What changes: The store configures what is theirs, within the ceiling central defined. Campaign, pickup, hours and service region come from that store's reality.

Counter salesperson

The pain: Opens four or five systems to close one complex order, and the system freezes exactly when the store is full.

What changes: One place, decoupled from the system of record, that holds up at peak. Price, stock, credit and tax checked at the same time, with the customer standing at the counter.

Illustrated console of one network store with the market campaign, service region and a discount capped by the ceiling set by central.
Market autonomy, within limits. The store configures its own campaign, region and terms. How far it can go is a decision of the portal layer, and that is what prevents internal price wars.

The variations this profile covers6

One sentence unites them all: the company sells to other businesses and to end consumers at the same time, with stores spread across the country. None of them fits an e-commerce with fixed pricing and single stock.

B2B2C at the same address
Companies and individuals buy on the same portal, and each loads their own customer group on identifying themselves, and with it the pricing rules and terms that apply there. Segmentation happens at entry, without anyone releasing prices for each new account.
Geographically spread stores
Each store has its own stock, price, region and campaign, and the store serving the customer's address appears first. There is one portal, and the operation remains one of many houses.
Counter and field, with the portal underneath
In-store counter service and the field seller use the same price, stock and credit engine the consumer sees on screen. The physical store stops being a channel with its own rules and becomes a mode of the same system.
Extensive, multi-banner catalogue
Tens of thousands of items, several banners and a product record that started out uneven between them. Unifying the catalogue without flattening each banner's commercial differences is the work that decides whether the portal sells.
Local stock and logistics
Store pickup tied to the warehouse that actually holds the item, with its own opening hours and days, and the distance to the customer's postcode shown when choosing the store. The customer only sees the stores that hold the item for pickup.
Regional pricing without internal war
The price origin is a configuration: it can follow the store nearest the delivery address, and then the website does not undercut the counter of a store in the same network. It is the difference between opening a channel and opening an internal competitor.

Three layers, one inside the other, and that is what makes scale fit6

A CWS Platform portal is configured in up to three layers: the portal layer, the store layer and the warehouse layer. Each one operates within the freedom the layer above granted, and how many come in is a project decision. That is why opening the tenth market does not cost what opening the second did.

The portal layer designs the ecosystem
The portal owner decides which stocks exist, which stock serves which customer and which seller serves from which stock, and sets the general financial rules, the default logistics options, the integrations and the payment methods. That configuration flows straight into each store's Seller Center.
The store layer runs the market
Each market joins as a store, from the network itself or from a third party: it receives orders, takes part in promotions and configures logistics, freight, payment methods and campaigns, with its own price and discount ceiling, within the limit the portal granted.
The warehouse layer sits inside the store
When a store has several stock points, they come in as its warehouses, with price by warehouse and pickup tied to the warehouse that holds the item. The warehouse belongs to the store, not to the portal.
The recommendation: the market joins as a store
In most cases the market pays off more as a store, which is the layer with the most functionality and flexibility. The warehouse is the choice when the network creates an internal store and runs its own warehouses: simpler service, sellers selling across several stores and one campaign for all of them.
Credit per store
The credit limit can be tied to the store, and how far it goes is a decision of the central configuration. Whoever carries the market's risk operates within the limit central set.
And central still governs
None of this is autonomy without rails. The market's autonomy is real, and it is bounded by a central decision: what the store may configure, and how far, is decided by the portal layer. Decentralising configuration without losing governance is the design, not a side effect of it.

The rails, in the network's vocabulary

Portal, store and warehouse layersWarehouses and price by warehouseConfigurable price originInvoicing by store or by warehouseStore pickup tied to the warehouseOpening hours and days per storeRegion restriction per storeCustomer groups and pricing rulesBanner and terms by customer groupPrice tags in pricing rulesPrice contracts by customer and regionSeller module at the counter and in the app

And when the stores start operating as sellers?

Then the profile meets the Governed Marketplace, with priority between stores, split and commission by origin.

Governed Marketplace →

In operation

Campneus · tire and automotive service store network · B2C

A Pirelli-certified network of more than 117 stores sells to consumers through a B2C marketplace on CWS Platform technology: regionalized stock and pricing, choice of pickup or delivery store, per-store shipping and a multi-store cart with automatic payment split. The consumer sees one store; each local market keeps its own stock, price and delivery.

Read the Campneus case →

Circuito de Compras · popular retail and wholesale · Brás, São Paulo

A wholesale shopping centre gathering shopkeepers of several origins and serving resellers across Brazil moved its operation to a multi-banner portal on CWS Platform technology, with a white-label app, international payments, service in several languages and an AI agent for product cataloguing and curation. Wholesale and retail, many stores and a large catalogue, in one place.

Read the Circuito de Compras case →

In auto parts distribution, Imdepa runs a self-service B2B portal with 3x more customers activated in 3 years, without growing the team in proportion. Same core, with business-to-business complexity underneath.

Frequently asked questions

I already have an e-commerce. Why would this be different?

Because the problem is not the shop window, it is what sits underneath it. An e-commerce assumes fixed pricing, single stock and a simple checkout, and it solves that case very well. When the same company sells to resellers and to consumers, with dozens of stores, customer groups and tax calculated item by item, the shop window becomes the easy part. If your case is fixed pricing and single stock, cheaper options exist, and we will say so.

Will the website undercut my store counter and cannibalise the network?

That is what happens when the digital channel's price stays tied to stock origin without anyone having chosen it. On CWS Platform the origin of the price is a configuration: it can follow the store nearest the delivery address, even when the product ships from the distribution centre, or follow the stock origin. Both exist, and the network decides which one applies. Tax is still calculated item by item, from the change of state and the purchase purpose (resale, industrialisation or consumption).

Every store wants its own campaign and its own logistics. Doesn't that become chaos?

It does, if autonomy means no rails. Here each market joins as a store on the portal and configures its own logistics, freight, payment methods and campaigns, with its own price and discount ceiling, within the freedom the portal layer granted. The store decides inside the limit, and the limit is a central decision.

How do companies and individuals buy on the same portal without price confusion?

Segmentation happens at identification. On entry the customer loads their customer group, and with the group the pricing rules and terms that apply there, plus their own credit limit. A reseller sees wholesale, a consumer sees retail, and nobody has to release prices for each new account.

And counter service, does it stay on a separate system?

No, and this is usually where the business case closes. The counter and the field seller run on the same price, stock and credit engine the customer sees on screen, through the Assisted Selling Platform (Sales Hub). The physical store stops being a channel with its own rules and becomes a mode of the same system.

Talk to CWS Platform

Want to see your network on a single portal?

Tell us how many stores and warehouses, whether you sell to resellers and consumers at the same address, and how price changes by region today. We come back with a demo in your scenario: customer groups and pricing rules, pickup at the right store, campaigns in the market and tax by purchase purpose.