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.
Osprey needed cleaner product data and a more maintainable catalogue so the Retail & home business could trade with confidence.
This was not a standard ecommerce build. The platform had to handle parts identification, specialist catalogue depth, technical data, pricing imports, depot stock and the systems behind each order.
Product information, catalogue structure and supplier feeds were likely sources of operational friction, with editorial and trading teams working around fragmented data.
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.
Self-serve buying has to behave predictably at peak without leaking edge cases into the order pipeline.
A new commerce surface had to land cleanly inside an operating business, not as a standalone project.
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.
Unclear product, pricing or fulfilment information can create friction before an order is placed.
Most relevant to Retail & home teams running B2C and D2C operations and weighing similar platform decisions.
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.
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.
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 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 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.
- 04Scoped the rules per audience, not per platformAccount-led ordering and self-serve buying were shaped as distinct journeys on the same foundation.
- 05Moved 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.
An outstanding Akeneo PIM agency. Our business challenges have always been met with reasoned advice and solutions offered by iWeb. As well as ensuring that their tools and micro-services are compatible with the platform upgrade paths, they have ensured that they are built in the most efficient and effective way.”
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 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.
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 purchase rewards PIM project built around product data, catalogue enrichment and partner scale.
Rewards catalogue management supported by faster enrichment and more efficient product workflows.
A homewares PIM project built around catalogue enrichment and retail product data.
Homewares trading supported by cleaner product data, catalogue enrichment and connected ecommerce.
A discount retail PIM project built around product data, governance and channel readiness.
Retail product teams supported by faster catalogue preparation and more controlled product data.