Skip to main content
Talk to an expert
Work/Just Kampers
ReplatformAutomotive & partsCW-076-RP-AU

Just Kampers: rebuilding machinery parts commerce around operational buying.

A 7-month Adobe Commerce (Powered by Magento) replatform for machinery parts commerce, shaped around product information and catalogue governance, connected operations and B2C buying.

Just Kampers operates in automotive & parts. Just Kampers's operating scale meant the commerce platform had to support product information and operational systems without losing customer confidence or continuity.

7
Month project
Kickoff to go-live
1
Platform
Adobe Commerce
1
Commerce models
B2C
4
Services
Replatform, Build, Support and PIM & Data. Rehearsed launch with senior technical oversight.
Read onWhat was actually wrong, what we did, and what could have gone wrong.
02
The problem

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.

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.

03
The risk

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.

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.

04
The work

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.

  1. 01
    Mapped the buying journey before the interface
    Started with how customers actually order on this site, then let the journey shape the interface decisions, not the other way round.
  2. 02
    Rebuilt the commerce foundation around how the business operates
    Rebuilt the commerce foundation around the operational logic the business already depended on, without resetting what already worked.
  3. 03
    Brought product data into one governed workstream
    Product information, enrichment and catalogue structure were treated as a delivery workstream that enabled the commerce change.
  4. 04
    Moved the project into support with the operating context intact
    Handover preserved the operational decisions made during build, so support could keep moving the platform forward without re-learning the business.
05
Systems

Systems, one operational truth.

The customer-facing platform was one part of the operating system. The project also depended on operational data, product information, inventory and communication systems, with clear boundaries for what each one supported and what customers could rely on.
Adobe Commerce (Powered by Magento)
Customer-facing commerce platform
Provided the customer-facing commerce platform for catalogue, account and ordering journeys. The platform could only present information it received from the operational and product systems around it. It mattered because a mismatch could become visible through product, account, stock or order information.
Custom Order Management (OMS)
Order management integration
Connected order management as part of the operational flow around commerce. Order journeys depended on a clear handoff between the customer-facing platform and order processing. It mattered because a mismatch could become visible through product, account, stock or order information.
06
Risk control

Where this could have gone wrong.

Difficult parts of a project need to be named early. That gives the team a shared view of the risks, the decisions needed, and the areas that cannot be left vague.
Product information
Catalogue structure, technical content and operational product data could move at different cadences. Drift risks putting incomplete, inconsistent or misleading information in front of a buyer choosing a specific item. How we held it: Separate ownership for product content, technical data, stock and price, then make each storefront dependency visible and reviewable through the product journey.
Timeline
The recorded project length set a fixed delivery context for a broad platform and integration scope. How we held it: Sequence decisions around the highest operational dependencies and flag any scope trade-off for editorial review rather than claiming an undocumented method.
Support ownership
After launch, unclear ownership across parts data, pricing imports, inventory feeds and account behaviour could make operational faults slower to understand and resolve. How we held it: Carry the system boundaries, data ownership and recovery decisions into support so the team inherits the operating model as well as the platform.
07
Outcome

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.

7
Month project
Kickoff to go-live
+41%
Add-to-cart increase
Increase recorded after launch
1x
System integration
Custom Order Management (OMS)
+22%
Speed of time to market
Improvement recorded after launch
1x
Platform
Adobe Commerce
+30%
IT adoption
Improvement recorded after launch
08
In their words

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.

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.
Stephen Gosling, Marketing Director, Just Kampers
09
After launch

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 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.

Next step

A project that looks like this one?

Send us the brief. You'll get a written response from a senior expert, usually within two working days.
Talk to an expertOr see all work →