What was actually wrong
Order flow, stock and customer data crossed several back-office systems, so integration boundaries and operational handoffs likely shaped how the platform was built.
Self-serve buying has to behave predictably at peak without leaking edge cases into the order pipeline.
The work had to replace the commerce foundation while preserving the operational logic customers already depended on.
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
If parts data, technical information, price or depot availability drift, a customer can lose confidence before adding an item to the basket, choose the wrong part, or move the question back to customer service for manual checking.
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.
Once a buying habit moves elsewhere it is expensive to win back. The consequence of inaction is not dramatic; it is cumulative.
Four 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.
- 03Brought product data into one governed workstreamProduct information, enrichment and catalogue structure were treated as a delivery workstream that enabled the commerce change.
- 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.
Platforms and integrations
Difficult parts
Results
In the client's words
The team of skilled professionals at this agency consistently exceeds our expectations, making it an excellent agency to work with. As a result of working with iWeb, we have been able to transform our business and plan our business for the future. It has been an absolute pleasure working with iWeb to define and build our digital blueprint.”
Ongoing support
The project did not end when the platform went live.
Support mattered because the machinery parts commerce 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.
Projects with a similar shape
A car care commerce platform rebuilt around product discovery, seasonal demand and checkout flow.
Car care retail supported by stronger seasonal sales, checkout activity and reduced returns.
A precision tooling platform rebuilt around product recommendations, ordering and catalogue control.
Tooling sales supported by stronger add-to-cart activity, recommendations and team productivity.
JLR accessories D2C: Adobe Commerce and Akeneo PIM.
A direct-to-consumer accessories commerce experience for Jaguar Land Rover, wired to Adobe Commerce, Akeneo PIM and SAP ERP so accessory catalogues, fitment data and retail journeys stay connected.