Bottom line up front: a WMS go-live lives or dies on two things — the software, and the super user. Get the person wrong, and the whole warehouse works overtime on launch day.
Across 30-plus implementations, the pattern is clear: far more projects fail on the human side than on software selection. Pick the right super user and the warehouse runs itself after the consultants leave. Pick wrong and you'll firefight for months.
What a WMS Super User Actually Does: Three Hats, No Fewer
Most people think a super user is just "the person who learns fastest and clicks the mouse for everyone else." Wrong. A real super user wears three hats, and all three are mandatory.
Hat one: translator. Consultants speak system — "this field controls wave release logic." Floor staff speak operations — "can this order ship today?" The super user translates back and forth, accurately. Translate badly and every process agreed in blueprint workshops is fiction.
Hat two: seed trainer. After the consultants leave, training dozens of floor staff, answering questions, onboarding new hires — that's all on the super user. In a 50-person warehouse, one consultant can't train everyone alone.
Hat three: go-live firefighter. In the first week after launch, exceptions surface daily that never appeared in testing: how to split a mixed pallet, how to book over-received goods, how to void a misprinted label. Waiting for a consultant's schedule means the dock backs up. The super user has to make the call on the spot — "handle it this way for now, I'll log it and confirm with the consultant tomorrow."
A super user isn't "the person who's good with computers." They're the deputy commander of the go-live.
The Cost of Picking Wrong: I've Seen This Exact Failure Three Times
The first time: 2022, an apparel 3PL near Los Angeles, 120,000 square feet. The project manager took the easy route and appointed the IT department's "most system-savvy" specialist as super user. The guy was great at Excel, a VLOOKUP wizard — and had never set foot in the warehouse. UAT covered nothing but happy paths: normal receiving, normal shipping, all green. On day one, a picker asked how to split one order across two pallets — he froze. An order clerk asked how to insert a rush order into a released wave — all he could say was "let me ask the consultant." Throughput collapsed that day, and the owner's wife ended up on the floor scanning to save the shift. Three weeks later they rolled back to the legacy system. The project slipped two months and burned a pile of extra implementation fees.
The second time: 2023. They picked the "star employee" — the fastest picker in the building, well liked by everyone. Problem: he had no time. He skipped blueprint workshops, crammed UAT overnight, and I wrote his SOPs for him. On launch day he knew his own station — and nothing else.
The third time was the most painful: the pick itself was fine — solid operations knowledge, respected by peers — but he was a people-pleaser. In blueprint workshops the consultant proposed a plainly unreasonable process — two night-shift staff doing four people's verification workload. He didn't want to seem difficult, so he nodded. After launch, night shift blew up every single night, and only then did he admit "I actually thought it was wrong at the time." A super user who won't say no is the same as having no super user.
Same lesson all three times: you're not picking "the most technical person" or "the hardest worker." You're picking the person best suited for this specific job.
How to Pick a WMS Super User: Five Hard Criteria
These are the five criteria I give every client. The scoring sheet is below — 80 points or above to qualify.
-
Deep operations knowledge — can explain the "why." The bar isn't "can operate it" but "can explain why each exception is handled the way it is." Ask: "why can't over-received goods go straight to putaway?" The right answer: "because QC hasn't cleared them — once they're on a shelf, nobody can find them." Someone who only knows the "how" falls apart the moment a variation appears while training others.
-
Peer credibility. Do coworkers actually ask this person questions, and listen to the answers? You can't fake this. Lead pickers and veteran order clerks usually have it naturally.
-
Can simplify, and has patience. Test: have them explain the returns process in three minutes to you as a new hire. If you got it, they pass. Most of a super user's job is explaining the same thing repeatedly — patience is hard currency.
-
Can commit at least half their time for the next three months. The super user role is a time sink: blueprint workshops, UAT, SOP writing, training, Q&A. Before appointing anyone, negotiate the backfill ratio with their direct supervisor — in writing. A verbal "we'll try to accommodate" always turns into "finish your day job first" right before launch.
-
Not hostile to the new system. Some veteran operators know the business cold but oppose every new system on principle — "our paper tickets worked fine." Making that person the super user plants a counter-propaganda node inside your project. Attitudes can change, but you can't afford to gamble inside a project timeline.
Operations veteran or IT? My answer: the operations person becomes the super user, IT becomes their backup. IT solves system-level puzzles faster; but only someone on the floor every day can judge whether a process is right. You need both — but the title goes to operations.
Super User Scoring Sheet (Steal This)
| Dimension | What to look for | Max score |
|---|---|---|
| Operations depth | Can explain the "why" behind exceptions, not just the "how" | 30 |
| Peer credibility | Coworkers ask them questions and respect the answers | 20 |
| Communication & patience | Can teach one process in 3 minutes so a new hire gets it | 20 |
| Time commitment | Can guarantee half-time backfill for 3 months | 20 |
| Learning attitude | Curious about the new system, not resistant | 10 |
| Total | 80+ qualifies; 70–80 workable with a trained backup | 100 |
Picked Right — Now Train: The 8-Week Super User Ramp Plan
Picking is only the first half. Training is the second. Here's the timeline:
- 8 weeks before launch: joins blueprint and process design workshops. One job: poke holes. Flag anything night shift can't physically do. Feedback in blueprint costs a whiteboard sketch; after launch it costs rework.
- 6 weeks before: lead UAT tester. No happy-path-only testing. Deliberately test exceptions — splits, over-receipts, short shipments, label reprints, offline-and-resume — each at least twice, hands on keyboard.
- 4 weeks before: writes SOPs in their own words. One page per process, with screenshots, no copying consultant documents. Test: hand it to a new hire outside the project — if they can follow it, it passes.
- 2 weeks before: becomes the instructor and trains the whole floor. Rehearse twice before going live. After teaching it three times, they'll know the system better than most consultants — beaten in by questions.
- 1 week before: walk the go-live night checklist — user accounts and permissions, printers, scanners, label stock, emergency contact sheet. Check every item.
- Launch day plus two weeks: on-site duty with an issue logbook. Fifteen minutes before clocking out, review with the consultant: issues surfaced, resolved on the spot, or needing config changes.
Here's the counterintuitive part: many people assume "the more technical training the super user gets, the better" and pile on system deep-dives. Dead wrong. A super user's highest value isn't "knowing the system" — it's "daring to say no to a bad process" and "being the first person the floor calls when something breaks." They can always ask IT or the consultant about technical details. But the judgment of "this process won't survive contact with the floor" belongs to them alone.
Five Common Failure Points — Dodge Them Early
- Making IT double as super user without reducing their workload. Both jobs suffer — neither the sysadmin work nor the super user work gets done properly.
- The super user joins UAT but skips blueprint. By the time they realize "we can't do this," rework costs ten times a blueprint fix.
- SOPs written in consultant-speak. If floor staff can't understand them, they don't exist. They must be in the super user's own words.
- Releasing the super user right after launch. The first three months are peak issue season — they need to stay in the role, at least part-time.
- Only one super user per warehouse. Vacation, resignation, sick leave — one absence and the whole building is lost. One primary plus one backup is the minimum; a backup who followed even half the journey beats having none.
On go-live night, the last item on my checklist is always the same: call the super user and ask, "are you ready for tomorrow?" When they say yes, I can finally sleep.
By Lin Xiao, WMS Implementation Consultant










