Work/Huws Gray Building Supplies & Solutions

ReplatformBuilders & tradeCW-003-RP-BT

Huws Gray Building Supplies & Solutions: rebuilding builders and trade around catalogue depth and account buying.

A 6-month replatform for builders and trade, shaped around catalogue depth, catalogue governance, account ordering, technical product information and B2B, B2C and Trade buying.

Huws Gray Building Supplies & Solutions'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 and Adobe Digital Experience

System integrations

Border Merchant Systems ERP, Salesforce CRM +6 more

Commerce models

B2B, B2C and Trade

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

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.

Huws Gray Building Supplies & Solutions 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.

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 commerce layer had to sit cleanly alongside fulfilment and ERP, without turning every operational dependency into a launch risk.

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

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, B2C and trade-account 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.

The work

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

01
Mapped this step of the work
In their ambition to elevate digital capabilities and deliver an exceptional online experience, huws gray selected iweb as their strategic digital partner. With deep expertise in Adobe Commerce (Powered by Magento) and a track record of supporting large-scale merchants, iWeb was uniquely placed to lead the transformation.
02
Separated this step of the work
Our collaboration with huws gray encompassed the design, development and deployment of a highly scalable e-commerce platform. This platform needed to support complex trade workflows, multi-site branch operations, live stock and pricing visibility, and seamless integration with back-office systems.
03
Connected this step of the work
By working closely with huws gray’s in-house teams, we aligned the digital solution with huws gray’s strategic activity ambitions: to support trade and retail customers more effectively, enable operational efficiency in branch and online channels, and build a foundation for future innovation. By working closely with Huws Gray’s in-house teams, we aligned the digital solution with Huws Gray’s strategic activity ambitions: to support trade and retail customers more effectively, enable operational efficiency in branch and online channels, and build a foundation for future innovation.

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.

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.

Border Merchant Systems 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.

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.

Warehouse Management System (WMS)

Warehouse integration

Supported warehouse and fulfilment processes connected to the commerce operation.

Adobe Digital Experience

Project platform

Supported the digital experience layer within the project platform stack.

Multi-depot Inventory

Stock and availability dependency

Represented stock by operational location so availability stayed useful to buyers and order teams rather than reduced to one total. Availability and fulfilment choices depend on depot-level inventory remaining aligned with commerce. It mattered because stock is only useful when its location, availability and fulfilment meaning match what the customer can rely on.

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.

Multi-branch Inventory

Stock and availability dependency

Multiple Commerce Sales Channels

Connected operational dependency

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

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.

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

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.

Month project

Kickoff to go-live

+55%

Online sales within the first 12 months

Improvement recorded after launch

System integrations

Border Merchant Systems ERP, Warehouse Management System (WMS), Multiple Commerce Sales Channels, Multi-branch Inventory +4

+70%

Growth in active trade account registrations

Increase recorded in the source data

Platforms

Adobe Commerce, Akeneo PIM and Adobe Digital Experience

-30%

Reduction in order fulfilment errors and manual admin tasks

Reduction recorded in the source data

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.

Working with iWeb has been a game-changer for us. They understood the scale and complexity of our business from day one and delivered a platform that aligns with our ambition to serve trade and retail customers seamlessly. The feedback from our branches and customers has been fantastic — it’s set us up for that next level of growth.”

Sam Brocklebank, Director of eCommerce, Huws Gray

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

Surfaces

Surfaces from the live project.

These screens show where the operational work becomes part of the customer, account buyer or internal team experience.

Huws Gray Building Supplies & Solutions — 01 tablet

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 expert Or see all work →