What was actually wrong
British Heart Foundation needed an ecommerce platform that could carry trade account ordering, repeat purchase patterns and operational reporting expected by a Retail & home business.
This was not a brochure storefront. Buyers arriving for a specific item needed enough product information and context to identify it with confidence, while stock, account pricing and purchase history had to support the same buying decision.
Order flow, stock and customer data crossed several back-office systems, so integration boundaries and operational handoffs likely shaped how the platform was built.
Trade buyers and account customers needed account-based pricing, repeat ordering and visibility of their own purchase history without friction.
Stock was not one flat number. Depot location, availability and fulfilment context had to remain meaningful so customers and order teams could rely on what the platform showed.
Business customers also needed the platform to reflect how they buy: parent and child account relationships, repeat purchase, order history, account documents and the correct pricing and stock context.
The commerce layer had to sit cleanly alongside ERP, without turning every operational dependency into a launch risk.
The platform change also depended on product information being structured, enriched and governed well enough to support the catalogue. Product data was a major workstream within the wider commerce delivery, not a separate outcome claim.
What was at stake
When account-based pricing, repeat ordering and purchase-history visibility slip, trade and account customers lose confidence in the site and push work back onto sales and support.
Most relevant to Retail & home teams running B2C, D2C and trade-account operations and weighing similar platform decisions.
If catalogue and operational data drift, buyers can lose confidence in product information, pricing, stock and purchase history. That can delay or abandon an order, while internal teams absorb the uncertainty through manual checking and customer service.
For repeat buyers and trade accounts, uncertainty creates friction every time an order is placed again. Wrong-part risk, unclear account terms and a harder repeat-order path can frustrate buyers and move the burden back to account teams and support.
Friction in the buying flow does not show up as a complaint. It shows up as quieter weeks and a slow erosion of intent.
Five things, in order.
- 01Mapped the buying journey before the interfaceStarted with how customers actually order on this site, then let the journey shape the interface decisions, not the other way round.
- 02Rebuilt the commerce foundation around how the business operatesRebuilt the commerce foundation around the operational logic the business already depended on, without resetting what already worked.
- 03Connected the systems that the storefront cannot work withoutThe commerce layer had to sit cleanly alongside ERP without coupling the launch to every system on day one.
- 04Brought product data into one governed workstreamProduct information, enrichment and catalogue structure were treated as a delivery workstream that enabled the commerce change.
- 05Scoped the rules per audience, not per platformAccount-led ordering and self-serve buying were shaped as distinct journeys on the same foundation. Local catalogue, depot, inventory, delivery and pricing rules had to remain coherent for the buyer context in front of the screen.
Platforms and integrations
Difficult parts
Results
In the client's words
Due to the complexity of our products it threw many obstacles in iWeb's way and all were dealt with in a sensible period of time and all were overcome. The team are fantastic, very easy to work with and really good at what they do.”
Ongoing support
The project did not end when the platform went live.
Support mattered because the retail and home still depended on parts data, pricing imports, account behaviour, inventory feeds, integrations and customer-facing information after launch.
Keeping the build decisions and system ownership visible gave the support team a clearer basis for tracing issues and maintaining the connected trading system after launch.








