01
Off-platform processes
Critical approvals and order tracking ran through Slack, email, and spreadsheets. No visibility, no single source of truth.

Mula is a B2B SaaS platform that helps companies streamline their merchandise operations. The mission was to prepare the company for European expansion.
Role
Product Design Lead
Company
Mula
Timeline
2022–2023
Team
Design, CS, Sales, Supply Chain, Warehouse
Mula had been growing steadily without funding through a period of high demand for branded merchandise. By mid-2022 a competitor had acquired a 25% stake with an option to complete the purchase, valuing the company at €40 million. The European expansion had a timeline. Thirty people and a platform that had grown faster than the processes supporting it.
Two fronts needed work before scale was viable: operations, and the customer experience. Operations first. Expansion without a stable operational foundation would have multiplied the failures customers were already seeing (late deliveries, missed deadlines, broken handoffs) across every new market we entered. This case is the story of that first phase.
Stakeholder interviews in my first weeks revealed that no two teams described the order lifecycle the same way. Inconsistent answers about the same process mean one thing: no single source of truth. I mapped the full order lifecycle across all five teams involved.

What came back wasn't fixable at the surface. Critical processes were running off-platform. Spreadsheets and Slack threads were compensating for gaps. This led to broken handoffs, unclear ownership, and operational failures that customers felt directly: delayed ETAs, missed deadlines, and, eventually, churn. At the current volume, the workarounds were manageable. At the next, they would compound.
01
Critical approvals and order tracking ran through Slack, email, and spreadsheets. No visibility, no single source of truth.
02
More than one person was considered responsible for the same step. In practice, nobody owned it.
03
Production specifications created manually. Order status maintained by hand across five teams. Every change meant rework.
Ownership was clarified during the mapping itself. Walking the broken steps with each team surfaced where responsibilities were unclear, and a single owner was assigned per process.
Production specifications were the manual process that touched every order. Different suppliers handled different product types and required different specifications. Designers maintained the templates by hand in Photoshop, rebuilding spec sheets per supplier per order. It worked at the current volume. It wouldn't at the next.
The decision was to stop accommodating each supplier's preferences and design one scalable format, agreed with the producers we worked with.
The intervention was closing the platform's configuration gaps so the specifications sheet could generate from platform data instead of being assembled in Photoshop.
34%
Order monitoring had three structural gaps: no consolidated view of the lifecycle, no early warning when a milestone was running late, and no preserved baseline for performance.
01
When something went wrong, CS and Sales reconstructed history from Design briefs, HubSpot, Slack threads, and spreadsheet comments. No single record existed.
02
The platform showed green until the ETA had already passed. No team could tell at a glance whether their part of the order needed steering.
03
The platform stored only the current ETA, never the original. Every update moved the goalposts. There was no way to distinguish client-caused delays from operational failures.
To compensate for these platform gaps, five teams maintained a shared spreadsheet across the organisation, updated daily by hand. The workaround surfaced what was missing, and added problems of its own.
04
Every update had to be made twice: once in the platform, once in the spreadsheet. Five teams, every order, every change.
05
Updates were time-consuming so teams batched them. By the time status was logged, it was already lagging behind reality.
The objective was to retire the spreadsheet by closing the gaps that had forced it into existence: a consolidated view of the lifecycle, early warning of milestone delays, and a preserved baseline for performance.
01
A unified timeline view
The spreadsheet was replaced by a unified timeline view, embedded in the order detail page and across all its instances.
02
Earlier warning signals
With every milestone now visible in one place, the traffic light could move from order-level to milestone-level.
03
Measurable on-time performance
The original ETA is now preserved alongside the current one.
| Before | After |
|---|---|
| Order lifecycle lived in spreadsheets and Slack | End-to-end process traceable on-platform |
| Customer Success blind to developing delays | Delays caught internally, before client impact |
| On-time performance measurement was broken | Real ETA performance visible for the first time |
Scale isn't something you add to a company. It's something the systems either support or don't. What customers experienced as delays came from an order lifecycle spread across spreadsheets, Slack threads, and five teams each holding part of the picture. Making it visible made it fixable. That's most of what designing for scale actually is.
Part (II): The Self-Service Platform. With the foundation stable, the customer experience work became the priority: redesigning the platform to do what the team had been doing manually. A separate case is in development.