Work/Jaguar Land Rover

ReplatformAutomotive & partsCW-027-RP-AU

Jaguar Land Rover: rebuilding classic vehicle parts commerce around catalogue depth and account buying.

A 2-month replatform for classic vehicle parts commerce, shaped around catalogue depth, catalogue governance, account ordering, technical product information and B2C and D2C buying.

JLR's operating scale meant the commerce platform had to support specialist catalogue depth, product information, operational systems and account buying without losing customer confidence or continuity.

Month project

Kickoff to go-live

Platforms

Adobe Commerce, Akeneo PIM, Adobe Experience Manager, Adobe Analytics +2

System integrations

SAP ERP, Multiple Commerce Sales Channels, Packing, Unipart Logistics +5 +5 more

Commerce models

B2C and D2C

Read onWhat was actually wrong, what we did, and what could have gone wrong.

The problem

What was actually wrong

Jaguar Land Rover needed a commerce platform that supported the Automotive & parts business model and the trading patterns of its customers.

This was not a standard ecommerce build. The platform had to support specialist classic vehicle parts, technical product information, catalogue relationships, account buying, stock, pricing and fulfilment without weakening owner confidence in selecting the right part.

Order flow, stock and customer data crossed several back-office systems, so integration boundaries and operational handoffs likely shaped how the platform was built.

Classic vehicle parts commerce depends on specialist catalogue accuracy. Owners and restorers need product relationships, technical information and vehicle context that help them select the right part while protecting confidence in the marque and the ownership experience.

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.

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.

The risk

What was at stake

Unclear product, pricing or fulfilment information can create friction before an order is placed.

Most relevant to Automotive & parts teams weighing similar platform decisions.

If specialist parts data, technical information, price or availability drift, a classic vehicle owner can lose confidence in the fit and provenance of a part before buying. A wrong selection also puts fulfilment, returns and brand trust under pressure.

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.

The work

Five things, in order.

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.
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.
03
Connected the systems that the storefront cannot work without
The commerce layer had to sit cleanly alongside ERP, tax and fulfilment without coupling the launch to every system on day one.
04
Brought product data into one governed workstream
Product 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.
05
Scoped the rules per audience, not per platform
Account-led ordering and self-serve buying were shaped as distinct journeys on the same foundation. Local catalogue, depot, inventory, delivery and pricing rules had to remain coherent for the buyer context in front of the screen.

Systems

Platforms and integrations

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.

Akeneo PIM / PXM

Product information platform

Provided the product information platform used to structure, enrich and prepare catalogue data for connected channels. Product data work depended on clear boundaries between this platform, upstream data and each receiving channel. It mattered because a mismatch could become visible through product, account, stock or order information.

Adobe Digital Experience

Project platform

Supported the digital experience layer within the project platform stack.

Multiple Commerce Sales Channels

Connected operational dependency

Supported the Multiple Commerce Sales Channels connection within the commerce operation.

SAP ERP

Operational business data system

Provided operational context for account, order, pricing and fulfilment data used by the commerce experience. Commerce depended on an agreed boundary between ERP-held business data and the customer-facing platform. It mattered because a mismatch could become visible through product, account, stock or order information.

Adobe Experience Manager

Experience platform

Supported the experience and content layer within the project platform stack. Its boundary with commerce and connected content flows needed to remain clear. It mattered because a mismatch could become visible through product, account, stock or order information.

Adobe Analytics

Supporting platform layer

Supported the Adobe Analytics connection within the commerce operation.

Salesforce CRM

CRM integration

Connected customer relationship data as part of the operating stack. Customer-facing journeys depended on a clear boundary between CRM context and commerce. It mattered because a mismatch could become visible through product, account, stock or order information.

Adobe Target

Experience optimisation platform

Supported the experience optimisation layer within the project platform stack. Its role depended on a clear boundary with the customer-facing experience. It mattered because a mismatch could become visible through product, account, stock or order information.

Warehouse Management System (WMS)

Warehouse integration

Supported warehouse and fulfilment processes connected to the commerce operation.

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.

Risk control

Difficult parts

ERP dependency

Account, order, pricing and fulfilment data depended on the ERP boundary. A stale or ambiguous hand-off could surface as the wrong account context, order state or delivery expectation. How we held it: Define which operational fields the ERP owns, how commerce consumes them and how failed or delayed exchanges are identified before they affect an order.

Platform maintainability

Commerce and digital experience capabilities sat across more than one platform. Unclear boundaries could make routine change harder and allow overlapping ownership to create inconsistent behaviour. How we held it: Keep platform responsibilities explicit, document the joins and carry those decisions into support so future changes do not reopen settled architecture questions.

Account ordering

B2B and direct buying shared a platform, but account hierarchies, purchase history, documents, pricing and order paths could differ sharply by buyer. How we held it: Model account relationships and permissions explicitly, then test repeat-order and self-serve journeys against the correct customer, price and document context.

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.

Stock and pricing

Availability and price could vary by account, catalogue, depot or inventory source. A flattened view risks presenting a value that is technically current but wrong for the buyer in front of it. How we held it: Preserve the buyer and location context behind stock and pricing, define the source for each value and test how fallbacks behave when an operational update is late.

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.

Outcome

Results

Month project

Kickoff to go-live

+25%

Conversion rate

Improvement recorded after launch

System integrations

SAP ERP, Multiple Commerce Sales Channels, Packing, Unipart Logistics +5

+40%

Faster page load times

Improvement recorded after launch

Platforms

Adobe Commerce, Akeneo PIM, Adobe Experience Manager, Adobe Analytics +2

+36%

Higher customer retention

Improvement recorded after launch

Client feedback

In the client's words

Our experience with the new JLR Classic site has been exceptional. The seamless navigation, faster load times, and enhanced shopping experience have truly elevated our ability to explore and purchase classic Jaguar and Land Rover cars and parts. It feels like the perfect blend of heritage and modern convenience!”

Rebecca Brocton, eCommerce Manager, JLR

After launch

Ongoing support

The project did not end when the platform went live.

Support mattered because the classic vehicle 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.