"WMS Reports: The 10 Dashboards Management Asks For (and Why 90% Are Shelfware)"

Verdict first: WMS reports are not a volume game. The question is never "how many dashboards do we have." It is two questions: does anyone actually open them, and does opening one trigger an action? In my experience, 90% of the reports management asks for end up as shelfware. Auto-generated every week, opened by nobody, and three months later even the sender can't remember who the recipient was supposed to be.

I have seen this exact failure three times, and the script never changes. The most recent was September 2023, at a 3PL outside Shanghai running close to a million square feet. During the WMS rollout, management handed IT a list of 42 reports. The exact words were "build them all, the data is in the system anyway." IT plus an outside consultant spent four solid months building every one of them. I came in for the post-go-live optimization, and the first thing I did was pull the report access logs: over the previous 90 days, 31 of the 42 reports had been opened zero times. Of the remaining 11, only 3 were actually read on a regular basis, inbound on-time rate, pick accuracy, and labor UPH. They eventually killed 39 reports and kept 3, delivered as one email at 8 AM every morning. The operations director told me: "If we'd known, we'd have built just those three. Those four months were wasted."

The 10 WMS reports that actually get read

The list below is distilled from 30+ go-live projects I have worked on. Every report on it must answer four questions: who reads it, what do they look at, how often, and who gets the call when a number goes red. If any one of those four has no answer, do not build the report.

1. Inbound on-time rate. Reader: operations manager. Metric: percentage of ASNs received and put away within 24 hours of arrival. Cadence: daily. Escalation: receiving lead. If it slips, the dock schedule or the labor plan broke.
2. Pick accuracy. Reader: operations manager and customer service. Metric: mis-pick orders over total pick orders. Cadence: daily. Escalation: pick supervisor. First check: wrong slot labels or an untrained temp.
3. Labor UPH. Reader: shift leads. Metric: units (or lines) picked per labor hour, compared across shifts. Cadence: daily. Escalation: the shift lead. A shift running 20% below the mean either has the wrong headcount or waves released too late.
4. Inventory accuracy. Reader: warehouse manager. Metric: SKUs with cycle-count variances over SKUs counted. Cadence: weekly. Escalation: inventory control. Variances cluster in slots, and slots mean mis-putaway.
5. Wave completion rate. Reader: operations manager. Metric: planned waves released and completed on schedule. Cadence: daily. Escalation: the planner. A late wave means overtime for the pickers. It is a chain reaction.
6. Exception aging. Reader: operations manager. Metric: exceptions (discrepancies, damages, system errors) open longer than 24 hours. Cadence: daily. Escalation: the exception handler. This report exists to name names.
7. Slot utilization. Reader: warehouse manager and 3PL sales. Metric: occupied slots over total slots, broken down by zone. Cadence: weekly. Escalation: slotting. Above 85%, start reshuffling. Above 95%, you cannot take on a new client next month.
8. Returns turnaround. Reader: customer service and operations manager. Metric: average days from return receipt to QC completion and restock. Cadence: weekly. Escalation: returns lead. Backlogged returns are invisible inventory, and they are the easiest to forget.
9. Overtime hours. Reader: warehouse manager and finance. Metric: overtime hours and cost by shift. Cadence: weekly. Escalation: whoever builds the roster. Overtime above plan three weeks in a row is not "a busy season." It is a broken labor model.
10. Cost allocation (3PL only). Reader: finance and key-account sales. Metric: storage and handling charges broken down by client. Cadence: monthly. Escalation: commercial. This report decides whether invoices go out on time.

Notice the pattern: every one of these ends in a concrete action. A report with no action attached is shelfware by definition.

WMS dashboard shelfware: why the real-time wall screen loses

Management's favorite request is the real-time dashboard, a big screen on the wall with numbers jumping live. It looks impressive. I have seen this exact failure three times, and the ending is always the same.

In May 2024, an e-commerce warehouse in the Pearl River Delta spent over 60,000 yuan on a real-time operations cockpit: 20+ KPIs rotating on a wall-mounted display. I visited three months later. The screen was still there, under a layer of dust. I asked the operations manager how often he looked at it. "A glance during meetings. Nobody stares at a wall during a shift." What actually drove his daily actions was a forwarded email from his assistant at 8 AM every morning: three tables, three red/green lights. Two reds, and he picked up the phone.

The reason is simple: management action happens in people, not on walls. Real-time dashboards fail for three reasons. First, too many metrics with no priority, so the reds drown in a sea of greens. Second, the manager sits at a desk, not in front of the screen, so even a visible anomaly produces no action. Third, numbers that flicker all day create numbness. The anomalies that actually need intervention happen two or three times a day, not two hundred.

So my standard practice: everything management asks for ships as a scheduled push, an email or a mobile message at 8 AM (or at shift handover), no more than five metrics, each with a traffic light and a named escalation. The wall screen is for visitor tours. That sounds harsh. It is also the conclusion verified across 30+ projects.

Do the math: what one WMS report really costs

Clients often say "the data is already in the WMS, how expensive can a report be?" Let me break it down using person-days from my actual projects:

One report from request to go-live eats 4 to 6 person-days on average. At typical implementation service rates, that is roughly 10,000 yuan before it produces a single insight. Forty-two reports is over 400,000 yuan, and that excludes yearly maintenance. The hidden costs are worse: the meetings to align metric definitions, the IT backlog clogged with report requests, and the regression testing on every report at each system upgrade.

Now the value side. A report that someone reads daily and acts on: 250 working days a year. Suppose it catches one would-be-missed anomaly per week, a delayed wave, a growing inventory variance. If each catch avoids a few thousand yuan of damage, the annual value is in the hundreds of thousands. The ROI is positive, and comfortably so.

But a report nobody reads has a decision value of zero and still costs its 10,000 yuan plus annual maintenance. That is why I say 90% are shelfware. It is not that reports are useless. It is that 90% of them were doomed to be unread from the day they were requested.

My go-live eve checklist: five questions, no answer means no build

This is the list I pull out the night before every go-live to block report requests. Any new report must answer these five questions in writing, signed by the requester, before it enters the development queue:

1. Who reads it? A specific person's name, not "the operations team."
2. How often? Daily, weekly, or monthly. Be precise.
3. What is the exact action when a number goes red? It must be concrete, like "call the receiving lead and add two people," not "keep an eye on it."
4. Is that action impossible without this report? If a phone call, a group chat, or a floor walk achieves the same thing, the report goes to the back of the queue.
5. Does the source data exist in the WMS? If not, who enters it, how often, and who owns bad data?

Answer all five, and it enters the queue. Miss one, and it goes back. I have watched too many projects die on question three. If you cannot name the action, the report never had a purpose.

Something you can use tomorrow: pull your current WMS report list and run it through these five questions. In my experience, at least half get cut in one pass. What you cut is not workload. It is noise. What survives is the WMS reporting management actually needs.

By Lin Xiao, WMS Implementation Consultant