Note before you read on. This is a demonstration piece, built on a composite scenario rather than a named client, and every figure in it is illustrative. We wrote it the way we write a real one, so what you’re judging here is the structure and the level of detail.
The situation
A warehouse software company sells a WMS to mid-sized shippers. The sales cycle ran about 6 weeks. Onboarding then ran 3 weeks, and on bad accounts 4.
For a long time nobody called that slow. Enterprise WMS projects run 3 to 6 months. Against that, 21 days looked like a selling point, and the sales deck said so.
It stopped looking like one when the buyer changed. The company started closing 3PLs with 40 to 90 warehouse staff. Those buyers signed in 6 weeks and expected to ship orders out of the new system the following Monday.
The cost showed up in two numbers. Churn inside the first 90 days sat at 14%. The implementation team, 4 people, couldn’t start more than 6 accounts in a month, and that capped new revenue no matter what sales did.
The operations lead timed one onboarding end to end. It took 61 hours of internal time. About 34 of those hours were spent waiting on the customer.
Where the 3 weeks went
They measured 9 onboardings before changing anything. That part matters. Every team that attacks a slow process has a favourite villain, and it’s usually the wrong one.
Data collection took 5 days. The customer had to export an item master, and most of them built it by hand because nobody on their side knew how to pull it out of the ERP.
SKU mapping took 4 days. An engineer matched customer item codes to internal fields, one column at a time, in files that averaged 8,000 rows.
Shipping rules took 3 days. Carrier selection, packaging, cut-off times, and the 5 or 6 exceptions every shipper has and nobody writes down.
Training took 2 days. It happened on the warehouse floor, usually across 2 shifts, because a picker who learns the system in a meeting room forgets it by Thursday.
The rest was queueing. An engineer would finish a mapping on Tuesday and the customer’s operations manager wouldn’t open it until Friday.
We ask for that timing sheet before we write a case study. It’s the difference between a story your buyer can act on and a story about how well things went. If your team already has one, the first draft comes back with the result section already filled in.
The solution
They changed three things, and the order they did it in is part of the story.
First, they stopped asking for the item master. They wrote 4 importers instead: one for each of the 3 ERPs their customers actually ran, and a generic CSV mapper for everyone else. The 3 targeted importers covered 71% of new customers.
Second, SKU mapping became a suggestion rather than a task. The importer proposed a field match, the customer approved or corrected it in a browser, and corrections ran to 30 or 40 lines out of 8,000. That turned 4 days of engineering into about 90 minutes of customer review.
Third, the shipping rules got defaults. Every account used to be configured from an empty screen. The team built 3 profiles out of the 9 accounts they’d measured, parcel-heavy, pallet-heavy and mixed, then started each new customer on the closest one.
Training was left alone, and that was deliberate. It’s 2 days of floor time. You can compress it on paper and pay for it later in support tickets.
What didn’t work
The first attempt was a self-service wizard. The customer would do the whole setup alone and the implementation team would only review it. It was built in 5 weeks and abandoned in 3.
It broke where the customer was left alone. Customers dropped out halfway through, on average at step 4 of 9, and then called anyway. The ones who finished made silent errors, a cut-off time in the wrong timezone or a carrier account left in test mode, and those surfaced 2 weeks later as failed shipments.
The second version put a person back in the loop for exactly 45 minutes. That call is now the only scheduled meeting in the onboarding. It’s also where the trainer catches the exceptions no form would have found.
The result
Median onboarding went from 21 calendar days to 4 working days, measured across the 22 accounts started after the change. Internal time per account fell from 61 hours to 19. The team stayed at 4 people and now starts about 14 accounts a month.
Churn in the first 90 days went from 14% to 9%. That number carries a caveat, and the caveat stays attached. Pricing changed in the same quarter, so those 5 points aren’t onboarding alone.
We would rather publish 9% with that caveat attached than 5 points without it. Your buyer reads the caveat as evidence somebody counted. A clean number with no conditions on it is the one they stop believing.
Not everything improved. Data quality on the customer side is still the biggest single variable, and an account with a bad item master still takes 2 weeks. The 3 importers cover 71% of customers, which leaves roughly 1 in 3 on the generic CSV path at 6 or 7 days.
What to take from it
The interesting part isn’t the 4 days. It’s that the team timed 9 onboardings before touching anything, and found the delay was mostly queueing rather than work. Waiting took 34 of the 61 hours. Your slow step is probably a queue too.
If your onboarding number is the one printed in your sales deck, time it before you fix it. What you’d change on instinct is the visible part. The visible part is rarely the slow part.
We would ask for that timing before we wrote a word of the page. Without it the result section thins out to an adjective. Our drafts get thinner in exactly the places the measurement is missing.
That’s also how we write these. A case study with no friction in it reads as marketing, so the wizard that failed belongs in the piece as much as the 4 days do. Your buyer has already had a failed attempt of their own, and the page has to survive that.
You can see what we ask for and what you get back on the case study page, and the other samples sit in the portfolio. Tell us which numbers you’re allowed to publish and we’ll tell you what the piece can carry.