What was actually wrong.
Most commerce problems are not just front-end problems. They sit between how customers buy, how teams work, and how the systems behind the business behave.
Sterlingbuild needed an ecommerce platform that could carry trade account ordering, repeat purchase patterns and operational reporting expected by a Builders & trade 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.
Product information, catalogue structure and supplier feeds were likely sources of operational friction, with editorial and trading teams working around fragmented data.
Trade buyers and account customers needed account-based pricing, repeat ordering and visibility of their own purchase history without friction.
Account-led buying carries rules that the storefront alone cannot enforce: pricing scope, account hierarchies, repeat-order patterns.
A new commerce surface had to land cleanly inside an operating business, not as a standalone project.
The difficult part was not the storefront alone. Account rules, stock, pricing, order history, fulfilment and product data all had to line up behind the buying journey.
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 happens if it isn't fixed.
When those gaps are left alone, the website becomes the place where operational problems show up. That can mean unclear data, pricing questions, repeated support queries and customers who cannot complete the job they came to do.
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 Builders & trade teams running B2B 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.
Trade accounts do not give second chances. A bad first experience pushes the order to a competitor and the relationship rarely comes back.
Four things, in order.
Delivery is not just a list of features. The order matters, because the wrong sequence can turn technical dependencies into business risk.
- 01Mapped the buying journey before the interfaceStarted with how customers actually order here: account relationships, repeat-buy patterns and the operational context behind each purchase.
- 02Rebuilt the commerce foundation around how the business operatesRebuilt the commerce surface inside the operating business, not as a standalone project.
- 03Brought product data into one governed workstreamProduct information, enrichment and catalogue structure were treated as a delivery workstream that enabled the commerce change. Technical data and downloads had to remain connected to the product context buyers used to identify the right item.
- 04Moved the project into support with the operating context intactHandover preserved the operational decisions made during build, so support could keep moving the platform forward without re-learning the business.
Systems, one operational truth.
Where this could have gone wrong.
Measurable, not adjectival.
The useful proof is not a bigger adjective. It is the project shape, the systems involved, the trading model supported and, where available, the numbers recorded from the work.
What the client said.
A client quote should support the case study, not carry it. The project story still needs to stay grounded in the work that was delivered.
Overall, iWeb helped transform Sterlingbuild into a PIM-minded organisation in which every team member understands the value of a PIM system and where the system itself contributes to the success of the organisation.”
What moved into support.
A project like this does not stop mattering at launch. The same catalogue, account, integration and trading logic has to keep working once real customers and internal teams are using it.
The project did not end when the platform went live.
Support mattered because the builders and trade 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.
Surfaces from the live project.
These screens show where the operational work becomes part of the customer, account buyer or internal team experience.
Projects with a similar shape.
A timber merchant PWA rebuilt around branch trading, stock visibility and trade ordering.
Timber merchant operations supported by stronger catalogue scale, adoption and page speed activity.
A builders' merchant platform built around online sales, trade accounts and order value.
Trade commerce supported by stronger online sales, active account activity and higher average order value.
A builders' merchant platform rebuilt around search, engagement and trade customer ordering.
Merchant trading supported by stronger search activity, engagement and faster routes to market.