Skip to main content
Talk to an expert
Work/Again Faster
RescueHealth & wellnessCW-040-RS-HW

Again Faster: rebuilding health and wellness around catalogue depth and account buying.

A 2-month Adobe Commerce (Powered by Magento) rescue for health and wellness, shaped around catalogue depth, catalogue governance, account ordering, technical product information and B2C, D2C and trade-account buying.

Again Faster's operating context made continuity and recovery critical for the live platform, the teams using it and the channels depending on it.

2
Month project
Kickoff to go-live
1
Platform
Adobe Commerce
1
System integration
Custom Order Management (OMS)
3
Commerce models
B2C, D2C and Trade account
Read onWhat was actually wrong, what we did, and what could have gone wrong.
02
The problem

What was actually wrong

Again Faster needed an ecommerce platform that could carry trade account ordering, repeat purchase patterns and operational reporting expected by a Health & wellness business.

This was not a standard ecommerce build. The platform had to handle parts identification, specialist catalogue depth, technical data, account buying, pricing imports, depot stock and the systems behind each order.

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

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

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.

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.

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 Health & wellness teams running B2C, D2C and trade-account 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.

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

Five things, in order.

  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
    Stabilised the live commerce surface and replaced the parts that were failing without resetting customer expectations.
  3. 03
    Stabilised the product data feeding the live platform
    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
    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.
  5. 05
    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.
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

Difficult parts

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

Results

2
Month project
Kickoff to go-live
+76%
Mobile conversion
Improvement recorded after launch
1x
System integration
Custom Order Management (OMS)
+22%
Revenue YOY
Improvement recorded after launch
1x
Platform
Adobe Commerce
+45%
Add to checkout
Improvement recorded after launch
08
Client feedback

In the client's words

As a result of our partnership with iWeb, our customers gain access to a customised user-facing digital experience that provides inspiration and additional information about our products. This UK Magento agency has been a great partner for us.
Max Wilson, Director, Again Faster
09
After launch

Ongoing support

The project did not end when the platform went live.

Support mattered because the health and wellness 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.