Case / Third-party logistics / Operations
Ninety steps to one invoice, and why the fix wasn't in billing.
An acquisition had just brought in a wave of new customers, and they were leaving. Support was issuing refunds to keep them.
A billing team's largely undocumented, ninety-step process for creating a single invoice traced back to an onboarding form nobody actually completed. The fix added the right friction upstream, rather than streamlining a process everyone could already see was broken.
Context
A third-party logistics provider offering outsourced inventory management, warehousing, and order fulfillment for e-commerce brands, shipping a high volume of orders daily across multiple U.S. warehouses.
Invoice volume was climbing, turnaround expectations were aggressive, and the billing system was aging: it couldn't cleanly capture certain fee types and didn't connect to the tools sales and finance used downstream. Everyone agreed invoicing was slow and error-prone. Nobody had mapped why. There had been at least one earlier attempt to fix it that hadn't stuck, which meant asking the same questions again.
What surfaced
The official ask was to investigate billing. Stakeholder interviews surfaced something more specific: creating a single invoice took dozens of distinct manual tasks, understood in full by a handful of people on the billing team, most of it undocumented. A single $1,000 order could carry three thousand line items. Billing staff often didn't trust their own data and routinely did detective work to verify it before an invoice went out.
That would have been a complete enough finding on its own. But tracing the process further pulled upstream and back to onboarding. New accounts were set up using a 120-question intake spreadsheet. In practice, fewer than 20 of those questions typically got answered, and every new account was handled as a one-off, because nobody had consistent baseline information about how it should actually be set up. The people running onboarding had learned the legacy system by trial and error, since there wasn't a reliable source of truth to learn it from.
The form that only got 20 of 120 questions answered wasn't a compliance problem. It was evidence the form didn't apply to most of the customers being asked to fill it out.
There was a second, quieter pressure underneath it: pressure to close new accounts quickly mattered more than precision, which turned onboarding into a formality to get through rather than a data-capture step to protect.
The intervention
The immediate work was mapping: structured stakeholder interviews to document the actual invoice-creation workflow, which is where the ninety-step count came from. Alongside, workshops to get stakeholders to articulate, in their own words, what billing was supposed to do for the business rather than starting from an assumed definition.
The recommendation wasn't to re-engineer the invoice process directly. It was to replace the onboarding spreadsheet with an adaptive intake flow: a small number of questions up front to establish how familiar the customer already was with third-party logistics, with the remaining questions changing based on those early answers. A customer who already knew what they wanted could specify exactly how their product should be stored. A less experienced customer got more guided steps, with videos explaining each one.
The bet wasn't that better questions alone would fix this. The same pressure to close accounts fast had already turned a 120-question form into a formality once. So the recommendation paired the adaptive flow feeding a persistent account profile: a rollup, visible to anyone at the company, showing an in-depth customer profile. Making incompleteness visible across the org, instead of buried in one team's spreadsheet, was designed to prevent it from happening again.
The recommendation was a redesigned intake flow, not a rebuild of the billing system, and not a promise that the invoice process itself would shrink to fewer steps. To make the opportunity concrete for the client, I built out a working prototype of both the intake flow and the account rollup (not something the engagement had called for or that got built).
What changed
A previously undocumented process got mapped and made visible for the first time, itself a reduction in operational knowledge risk. Stakeholders arrived at a shared, workshop-built definition of what billing was for. An adaptive, front-loaded onboarding flow was designed and proposed: functioning as both an explainer for newer customers and a data-capture tool for the company.
I don't have confirmed data on whether the new flow shipped, or changed invoice handling time or accuracy after the fact. What exists is the diagnostic finding and the design of the fix, not a measured before-and-after. The ninety-step count is real and interview-derived. Granted it's also a product of how the interviews scoped the workflow; a different methodology might count the same process slightly differently.
Not every broken form needs to be shorter. Just smarter.
Ninety manual steps looked like a billing problem. It was an intake problem that billing was quietly absorbing the cost of, one invoice at a time, compounding for months after the account was set up.