Selling on five channels is easy. Having one version of the truth isn't.
Store, website, marketplaces and internal sales each end up with their own catalogue, stock figure and customer record. Pwas keeps one model and lets every channel be a reading of it.
Omnichannel doesn't fail on sales. It fails on synchronisation.
The website has its catalogue, the marketplace wants one with different fields, the store has its point of sale and the ERP holds the accounting truth. Between these four worlds run nightly syncs that almost work: an item that sells out but stays buyable online for eight hours, a promotional price that reaches the marketplace a day late, a customer who exists three times under three records. Every discrepancy creates manual work, returns and angry customers — and the classic fix, adding another sync, makes the problem worse rather than solving it.
illustrative scenario
Black Friday at a retailer with eleven stores and two marketplaces.
Friday, 7am. Promotions went live at midnight. At 9:20 the e-commerce manager notices that a heavily discounted item is still buyable online, but sold out in stores two hours ago. Orders already taken: one hundred and twenty. Stock sync runs every forty-five minutes, and on a normal day that's fine: today it isn't, and the cost of the error is one hundred and twenty customers who have to be told no on the day they bought the most.
At 11am the second problem: on the marketplace a product shows at full price, because the feed accepts one update a day and the promotion was decided on Thursday evening. At 3pm the third: a customer who bought online and wants to exchange in store appears to the shop staff as a complete stranger, because the website's customer record and the POS's are two separate archives.
What changes with Pwas
The premise is that none of these is an e-commerce platform problem. They're all the same problem: multiple copies of the same information exist and someone has to keep them aligned. So the work starts from defining what product, variant, stock, price, customer and order really mean for this business — and which rules govern them: a price can be list, promotional or channel-specific; stock is per location and has a portion reservable online; a customer is one person even if they bought in three different ways.
From that description come the internal screens, the visibility rules and — this is the point — the interfaces the channels use. Website, POS and marketplaces no longer receive periodic copies: they read and write against the same model, each seeing its own slice. When the till records a sale, the stock figure the website reads has already changed, because it's the same stock figure.
The same Black Friday, a year later
At 9:20 the item sold out in stores isn't buyable online, because there's no forty-five-minute window in which the two worlds can diverge. The promotion decided on Thursday evening is live across every channel, because it's a rule on the product, not a file to export. The customer walking into the store with a return is recognised at the till, with her online purchase history in front of the assistant — and the exchange takes two minutes instead of ten.
When the third marketplace opens
Six months later management decides to sell on another marketplace, which demands fields no other channel uses: its own product classification, two extra measurements and a shorter description. Conventionally this means a new integration project and, often, a new parallel catalogue to maintain.
Here you add the fields to the product model, declare they apply only to that channel, and describe how the marketplace wants to receive the data. The catalogue management screens show the new fields by themselves. Whoever loads products doesn't learn a second tool. The catalogue stays one.
the comparison
What happens today, what happens afterwards.
The situations that repeat at every promotion, every season change and every peak.
Today
Every channel has its own copy of the truth
Stock syncs every so many minutes, and at peak that window costs sales and returns.
A price change means remembering every channel it has to be replicated on.
The same customer exists several times, with separate histories across web, POS and ERP.
Product information is enriched in one place and re-exported elsewhere, with losses.
Store staff can't see online orders and can't handle exchanges or returns.
Opening a new channel means opening a new integration project.
With Pwas
There is one model, and channels are readings of it
Stock and availability are one figure: the till and the website read the same number.
A price or promotion is a rule on the product, live everywhere at the same instant.
The customer is one person, with a full history visible to whoever has permission.
Product information sits in one place, with channel-specific fields declared as such.
Stores see and handle online orders: click and collect, exchanges and returns become routine.
A new channel is a new reading of the same model, not a second catalogue.
how you get there
The path, concretely.
Without switching off the website and without stopping sales at any stage.
01
We map the channels and where they lie
We look at where information diverges today: which fields exist on only one channel, which syncs fail, which manual corrections someone makes every morning. Recurring manual corrections are the map of the structural defects.
02
We define product, price, stock and customer
One model, with channel variants declared as such. This is the phase where commercial decisions get made, not technical ones: what "available" means, who can reserve stock, when a customer is the same customer.
03
We start from one channel and one category
We pick a scope where mistakes are cheap and run the full flow: product loading, price, stock, order, return. The point is to validate the model on real data before touching critical channels.
04
We connect the other channels
Website, POS and marketplaces are attached to the single model one at a time, replacing the periodic syncs. Every channel that joins reduces manual work instead of adding to it.
05
Automation and self-sufficiency
We switch on the automatic checks — mismatches, products without images, prices below margin — and train whoever will manage catalogue and rules without going through the supplier.
an example flow
One catalogue, one customer, every channel.
The product is described once and published to every channel with the attributes each one requires; stock reconciled and orders routed to the right place.
what changes structurally
Properties of the system, not promised outcomes.
Characteristics of how it works, verifiable in a demo on your own data.
1
catalogue for every channel
Fields needed by only one channel are declared as such: they stay in the same model instead of spawning a second catalogue to maintain.
0
stock misalignment windows
Till, website and marketplaces read the same availability: there's no interval between two syncs in which channels can diverge.
1
customer identity across touchpoints
The same customer in store, online and in customer service, with history visible to whoever has permission — not three records to deduplicate.
same day
the time for a new field or rule
An attribute a channel requires or a new pricing rule is a configuration change, not an application release.
These are platform properties, not results measured at specific customers. The impact on your P&L depends on volumes and scope, and we estimate it together before starting.
in depth
The questions commercial directors and e-commerce managers ask us.
"Do I have to throw away my e-commerce platform?"
Almost never. A mature e-commerce platform does things well that would be absurd to rewrite: storefront, basket, checkout, payments, catalogue SEO, campaigns. The problem usually isn't the storefront.
The problem is that the platform has inevitably also become the place where a copy of the catalogue, prices, stock and customers lives — a role it wasn't built for and that puts it in competition with the ERP. That's where the syncs come from, and from the syncs the misalignments.
In most projects Pwas takes the layer underneath: it holds the single model and exposes it to the e-commerce platform, the POS and the marketplaces. The storefront stays where it is and keeps doing its job, but stops being a second source of truth. If you later decide to change platform, the catalogue doesn't move: it's already outside.
"My real problem is store staff. They'll never use a complicated system."
A sensible worry, and the answer is a design constraint before it's a technical choice: in store, every operation must take a few taps and must not interrupt the conversation with the customer in front of you.
In practice that means the assistant doesn't "use a business system": they scan an item code and immediately see whether another store has it; they open a customer's online order by scanning her confirmation code; they accept a return with two confirmations and the system handles the rest — stock receipt, credit note, history update.
Complexity belongs where it's needed: in the screens of whoever manages catalogue, pricing and buying. Putting it in store is the most reliable way to kill the project, and it isn't a training issue: in store, the time belongs to the customer.
"I have 40,000 SKUs. How do I avoid drowning in catalogue work?"
On large catalogues the effort isn't entering a product: it's keeping thousands of records consistent when they were filled in by different people at different times under rules nobody wrote down.
Two mechanisms change the game. First, completeness rules are declared: if a record in this category needs two measurements, three images and a product classification, the system knows it and flags what's missing by itself, before the product reaches the wrong channel. Second, enrichment can be assisted: from a supplier's PDF datasheet, attributes and descriptions are extracted already structured, for a person to verify and approve instead of retyping.
The result that matters isn't "the catalogue does itself" — it doesn't. It's that people's work moves from typing to checking, which is where their expertise is worth something.
"What do I do with AI, apart from the chatbot I don't want?"
In most retail businesses the generic website chatbot has the worst value-to-noise ratio of any feature. There are, however, three uses that pay for themselves.
Catalogue enrichment: reading supplier datasheets, price lists and images to propose ready-made attributes, descriptions and classifications for approval. Internal operational questions: "which promoted SKUs are below three units in at least five stores?" is a question that today needs a report and tomorrow needs a sentence. Repetitive after-sales handling: draft replies to return or order-status requests, pre-filled with real data, that a person checks before sending.
The rule that makes all of this acceptable in a serious business is always the same: the agent doesn't act outside what is declared. Every action touching prices, orders or customer records goes through a plan verified against the real permissions of whoever asked, can require human confirmation and leaves a reconstructable trace. A model doesn't cut a price because it seemed reasonable.
quick check
Do you recognise your situation?
Probably yes
You sell across several channels and at least one sync causes recurring problems.
The same customer exists several times in different systems and nobody can unify them.
Store staff can't handle orders, exchanges or returns that started online.
Opening a new marketplace costs you months and a second catalogue to maintain.
You have complex pricing or promotion rules that live in files and manual procedures.
You have an ERP that's staying and an e-commerce platform you'd like to be able to change.
Probably not
You sell on one channel, with few SKUs and no physical stores.
Your e-commerce platform already handles catalogue, stock and unified customers well.
You're looking for a theme or a storefront restyle.
You have no intention of revisiting how product records are created and maintained.
frequently asked
Retail and e-commerce: the specific questions.
Does it connect to the e-commerce platform I already use?
Yes, and this is the most common scenario. Pwas exposes catalogue, prices, stock, customers and orders through interfaces the platform consumes, replacing periodic syncs with direct reads. Storefront, checkout and campaigns stay where they are. The same applies to marketplaces and to POS systems that allow a data connection.
How do you handle stock between the central warehouse and stores?
Stock is per location and can carry quotas reserved for different channels, according to rules you set: for example a portion of store stock not bookable online, or a minimum threshold below which a store stops feeding digital sales. These are declared, readable conditions that whoever manages buying can discuss and have changed without a development cycle.
Does it handle click and collect, exchanges and cross-channel returns?
Yes, and it's one of the most frequent reasons omnichannel retailers come to us. Because order, customer and stock are the same model for every channel, an order created online and collected in store doesn't need a dedicated integration: it's the same order with one extra status change. The same goes for an in-store return of an online purchase, with stock receipt and credit note linked.
What effect does this have on our site's SEO?
No negative effect, and in many cases an improvement. The storefront and its URLs remain managed by your platform; what changes is the quality and completeness of the data feeding it — fuller records, consistent attributes, correct availability — which are among the factors that genuinely affect product page ranking and shopping feed performance.
Does it hold up under Black Friday-type peaks?
Capacity is sized during the project against your peak volumes, not your averages, and the architecture allows resources to be increased on the parts under pressure without redesigning the system. On top of that, removing periodic syncs eliminates precisely the mechanism that generates the costliest misalignments at peak. Load testing is part of the path before go-live.
How long to the first channel in production?
For a narrow scope — one product category and one channel, with the full cycle from catalogue to return — the order of magnitude is a few weeks. The other channels take less, because the model is already validated and what gets added is their specific reading of it.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.