Orderspace — account review
Wild Hearth Bakery · April 2026 · Internal
Problem
The Orderspace account has grown organically without a consistent structure. Categories mix product types with customer-access rules and pipeline workarounds. Products that differ only by size, shape, or preparation are listed as entirely separate records — no relationships, no shared identity. The result: 12 categories with unclear purpose and 102 product records for what is effectively a much smaller catalogue.
Process
Four linked reviews, each looking at the same account from a different angle:
Category Review
Audited all 12 categories against their actual purpose — product type, customer access, or utility workaround. Cross-referenced against existing customer groups in the account.
Variant Review
Mapped all 102 products to identify families — groups of products that differ only by a dimension Orderspace can model natively (Size, Shape, Preparation, etc.).
Product Codes
Scouted product IDs, SKUs, product codes, and existing roll-up mappings. The core codes are mostly sound; the reporting and production mappings need watching during implementation.
Customer Groups
Scouted the 55 customer groups against current customers, delivery-schedule naming, access categories, and recent orders for customer-specific product categories.
The findings can be read separately, but implementation should be coordinated. Category, variant, product-code, and customer-group changes touch the same products from different sides.
Solution
Four top-level categories with four sub-categories replace the current flat list. On the product side, 63 products consolidate into 15 families using Orderspace's native variant model — the orderable item count stays exactly the same.
Dependencies
The structure can be agreed before every mapping detail is solved, but the changes should not be treated as four unrelated jobs. The safe order is: decide the target catalogue shape, check product codes and group visibility for the affected products, then make the Orderspace changes family by family.
| Before changing… | Check… |
|---|---|
| Access-style categories | Which products are genuinely restricted to a customer group, and which are shared products sitting in a historically messy category. |
| Separate products into variants | That each orderable variant keeps the right SKU, parent roll-up, price-list behaviour, and customer visibility. |
| Utility / internal products | Whether they are operational workarounds, reporting placeholders, or products that still need to remain orderable. |
Implementation principle
Do the clean-up in small product families, not as a single account-wide rewrite. For each family: confirm category, visibility group, SKU/roll-up, price-list behaviour, and recent customer usage before making the change.