Skip to main content
Talk to an expert
Work/World of Books
PIM & DataRetail & homeCW-038-PD-RH

World of Books: rebuilding retail and home around catalogue depth.

A 4-month build for retail and home, shaped around catalogue depth, catalogue governance, technical product information, connected operations and B2C and D2C buying.

World of Books operates in retail & home. World of Books's operating scale meant the commerce platform had to support specialist catalogue depth, product information and operational systems without losing customer confidence or continuity.

4
Month project
Kickoff to go-live
2
Platforms
Shopify Plus and Akeneo PIM
2
System integrations
Multiple Commerce Sales Channels and Patchworks iPaaS
2
Commerce models
B2C and D2C
Read onWhat was actually wrong, what we did, and what could have gone wrong.
02
The problem

What was actually wrong

World of Books needed cleaner product data and a more maintainable catalogue so the Retail & home business could trade with confidence.

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.

The commerce layer had to sit cleanly alongside Multiple Commerce Sales Channels and Patchworks iPaaS, without turning every operational dependency into a launch risk.

Self-serve buying has to behave predictably at peak without leaking edge cases into the order pipeline.

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

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

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

Most relevant to Retail & home teams running B2C and D2C 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.

Friction in the buying flow does not show up as a complaint. It shows up as quieter weeks and a slow erosion of intent.

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
    Rebuilt the commerce surface inside the operating business, not as a standalone project.
  3. 03
    Connected the systems that the storefront cannot work without
    The commerce layer had to sit cleanly alongside Multiple Commerce Sales Channels and Patchworks iPaaS without coupling the launch to every system on day one.
  4. 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.
  5. 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.
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.
Shopify Plus
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.
Multiple Commerce Sales Channels
Connected operational dependency
Supported the Multiple Commerce Sales Channels connection within the commerce operation.
Patchworks iPaaS
Connected operational dependency
Supported the Patchworks iPaaS connection within the commerce operation.
06
Risk control

Difficult parts

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

4
Month project
Kickoff to go-live
+65%
Improved product data quality
Improvement recorded after launch
2x
System integrations
Multiple Commerce Sales Channels and Patchworks iPaaS
-16%
Reduction in capital investment
Reduction recorded in the source data
2x
Platforms
Shopify Plus and Akeneo PIM
2x
Commerce models
B2C and D2C
08
Client feedback

In the client's words

Partnering with iWeb for our custom integration of Akeneo PIM has revolutionised our operations at World of Books. Their expertise and seamless execution have streamlined our processes, allowing us to efficiently manage our vast inventory of used books. iWeb's innovative approach has not only enhanced our internal workflows but has also improved the overall experience for our customers, ensuring they find the books they love easily and affordably. Their partnership has been instrumental in our mission to promote sustainability through the reuse and recycling of books.
Remo Gettini, Digital Product Manager, World of Books
09
After launch

Ongoing support

The project did not end when the platform went live.

Support mattered because the retail and home 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.