What was actually wrong
Product information, catalogue structure and supplier feeds were likely sources of operational friction, with editorial and trading teams working around fragmented data.
This was not a standard ecommerce build. The platform had to handle parts identification, specialist catalogue depth, technical data, account buying, pricing imports, depot stock and the systems behind each order.
Trade buyers and account customers needed account-based pricing, repeat ordering and visibility of their own purchase history without friction.
Machinery parts commerce depends on more than product names and images. Buyers need catalogue structure, technical information and product relationships that help them identify the right part with confidence.
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.
Account-led buying carries rules that the storefront alone cannot enforce: pricing scope, account hierarchies, repeat-order patterns.
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.
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 here: account relationships, repeat-buy patterns and the operational context behind each purchase. Purchase history, documents and parent-child account behaviour had to support the journey rather than sit outside it.
- 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. 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.
Platforms and integrations
Difficult parts
Results
In the client's words
When we found iWeb, we instantly saw the potential of what their digital solutions offered. Adobe Commerce and Akeneo PIM both had the structure and design simplicity that our existing solution lacked. They understood our customers, and this was reflected in the efficient customer journey. I can't fault them.”
Ongoing support
The project did not end when the platform went live.
Support mattered because the automotive and parts 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 battery trade portal built around product recommendations, fitment data and repeat ordering.
Battery purchasing supported by stronger mobile journeys and more efficient pricing workflows.
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.