Skip to main content
Talk to an expert
Work/Sterlingbuild
PIM & DataBuilders & tradeCW-092-PD-BT

Sterlingbuild: rebuilding builders and trade around catalogue depth.

A 2-month build for builders and trade, shaped around catalogue depth, catalogue governance, technical product information, connected operations and B2B buying.

Sterlingbuild is the largest independent retailer of roof windows in the UK and the country's number one VELUX stockist. Sterlingbuild's operating scale meant the commerce platform had to support specialist catalogue depth, product information and operational systems without losing customer confidence or continuity.

2
Month project
Kickoff to go-live
2
Platforms
Kentico Xperience Commerce and Akeneo PIM
1
System integration
Microsoft Dynamics 365 Business Central
1
Commerce models
B2B
Read onWhat was actually wrong, what we did, and what could have gone wrong.
02
The problem

What was actually wrong

Sterlingbuild needed an ecommerce platform that could carry trade account ordering, repeat purchase patterns and operational reporting expected by a Builders & trade business.

This was not a brochure storefront. Buyers arriving for a specific item needed enough product information and context to identify it with confidence, while stock, account pricing and purchase history had to support the same buying decision.

Product information, catalogue structure and supplier feeds were likely sources of operational friction, with editorial and trading teams working around fragmented data.

Trade buyers and account customers needed account-based pricing, repeat ordering and visibility of their own purchase history without friction.

Account-led buying carries rules that the storefront alone cannot enforce: pricing scope, account hierarchies, repeat-order patterns.

A new commerce surface had to land cleanly inside an operating business, not as a standalone project.

The difficult part was not the storefront alone. Account rules, stock, pricing, order history, fulfilment and product data all had to line up behind the buying journey.

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

Most relevant to Builders & trade teams running B2B operations and weighing similar platform decisions.

If catalogue and operational data drift, buyers can lose confidence in product information, pricing, stock and purchase history. That can delay or abandon an order, while internal teams absorb the uncertainty through manual checking and customer service.

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.

Trade accounts do not give second chances. A bad first experience pushes the order to a competitor and the relationship rarely comes back.

04
The work

Four things, in order.

  1. 01
    Mapped the buying journey before the interface
    Started with how customers actually order here: account relationships, repeat-buy patterns and the operational context behind each purchase.
  2. 02
    Rebuilt the commerce foundation around how the business operates
    Rebuilt the commerce surface inside the operating business, not as a standalone project.
  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. Technical data and downloads had to remain connected to the product context buyers used to identify the right item.
  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

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.
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.
Kentico Xperience Commerce
Project platform
Supported the Kentico Xperience Commerce connection within the commerce operation.
Microsoft Dynamics 365 Business Central
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.
06
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.
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

Results

2
Month project
Kickoff to go-live
+100%
Data management tasks put in the hands of experts
Improvement recorded after launch
1x
System integration
Microsoft Dynamics 365 Business Central
+150%
Improved automation & governance
Improvement recorded after launch
2x
Platforms
Kentico Xperience Commerce and Akeneo PIM
3x
Times stronger supplier and brand relationships
Improvement recorded after launch
08
Client feedback

In the client's words

Overall, iWeb helped transform Sterlingbuild into a PIM-minded organisation in which every team member understands the value of a PIM system and where the system itself contributes to the success of the organisation.
Dominic West, Commercial Director, Sterlingbuild
09
After launch

Ongoing support

The project did not end when the platform went live.

Support mattered because the builders and trade 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.