Warehouse metrics
Busy trucks and idle trucks,by class and by hour.
MHE utilisation is the share of an asset's available hours actually spent on task work, read by class — forklift, reach truck, pallet truck — and by hour rather than as one fleet-wide average. WareBee joins telematics off the trucks that carry it with the task data that assigned the work in the first place, so a class parked for most of a shift and a class queuing at the pick face stop reading as one blended number.
See what's driving forklift utilisation
What it is
Read by class and by hour, not as one fleet total.
On WareBee's digital twin, MHE utilisation is the share of an asset's available hours actually spent on task work — measured by class, forklift, reach truck or pallet truck, and by hour, rather than rolled into one fleet-wide figure. WareBee joins telematics off the trucks that carry it with the task data that assigned the work in the first place, so a truck's dwell time sits right next to the job it was waiting to serve instead of living in a telematics dashboard nobody cross-checks against the WMS.
The reading moves with how work gets assigned as much as with how much work there is. Task allocation that hands a job to whichever truck is nearest rather than the class actually built for it leaves one class fully booked while another with spare capacity sits at the dock. A fleet count fixed to survive the single hour that breaks the day carries that same size through every quieter hour around it, where it reads idle rather than needed. And a travel-heavy run matched to the wrong class either ties up equipment rated for more than the job needs, or slows a class that was never built to cover that kind of distance.
MHE utilisation only tells you something once it's held against the fleet it's fair to compare with — order profile, SKU count and footprint decide how much genuine work a class should expect in a given hour, long before task allocation or fleet sizing enters the picture. WareBee runs that match first, so a class reading quiet gets checked against fleets asking the same thing of their trucks, rather than compared with a number lifted from an operation that never resembled it.
What moves this number
What decides which class reads busy.
Each one is measured on your digital twin from data you already generate, so a utilisation gap traces back to a class and a cause rather than a general sense the yard is over- or under-trucked.
Task allocation sending work to the nearest truck
A job goes to whichever vehicle is free and closest, not the class actually built for it, so one class stays booked solid while another with room to spare sits at the dock.
Each task carries the equipment class it actually needs, checked against how many trucks of that class are free before the work is assigned. Where that check doesn't run, utilisation by class stops reflecting what the fleet was actually asked to do.
A fleet sized once, for the worst hour of the day
Truck count gets fixed to survive the single hour that breaks the day, then carried through every quieter hour around it without being revisited.
Utilisation for every asset class is measured against the task minutes that hour's work actually required, so a fleet that's right for the peak and wrong for the rest of the shift stops being a guess. What-if scenarios test a smaller core fleet against the same peak before a lease renews.
A long run landing on whichever truck was nearest
A travel-heavy job to a distant dock goes to whatever's free, not the class actually built to cover that kind of distance.
Location and utilisation feeds from the fleet enrich travel-time analysis, so a genuinely long run can be matched to the class built for distance instead of the one that happened to be closest. Left unmatched, that run quietly sets the pace, and the utilisation reading, for whichever class it landed on.
Telemetry and task data living in two separate systems
The telematics exist, the task data exists, and until the two are joined there's no single hour either one can be read against.
Forklift and MHE telemetry lands in the same event model as every scan, so a truck's dwell time sits right next to the task it was waiting to serve instead of a separate dashboard nobody cross-checks. Joined into one model, utilisation by class and hour becomes a number that exists at all.
Which class needs the fleet, and which is carrying spare capacity.
A single MHE-utilisation figure for the yard hides which class is actually driving it. Once yours is read against a peer set matched on order profile, SKU count and footprint, the next question is whether the gap is coming from task allocation sending work to the nearest truck rather than the right class, a fleet sized for one peak hour and carried through every quieter one, or a travel-heavy run matched to the wrong equipment — the same telemetry and task data that builds the figure breaks it down by class and hour.
From there it's an allocation and sizing question, not a purchase order by default. A revised task-allocation rule, a smaller core fleet or a rental buffer for peak weeks can be tested on the digital twin against the same task volume already producing the current figure, so the utilisation effect shows up before a lease renews. Once approved, the change reaches the WMS as the assignment logic and priorities it already runs on.
- MHE utilisation read against a peer set matched on order profile, SKU count and footprint
- Every class's utilisation traced to allocation, fleet sizing or a mismatched travel-heavy run
- Fleet and allocation changes tested on the twin before a lease renews
Questions
MHE utilisation, by class and by hour.
What exactly counts toward MHE utilisation?
It's the share of an asset's available hours actually spent on task work, measured by class — forklift, reach truck, pallet truck — and by hour rather than rolled into one fleet-wide figure. WareBee joins telematics off the trucks that carry it with the task data that assigned the work, so a class's dwell time sits next to the job it was waiting to serve instead of a separate dashboard nobody checks against the WMS.
Does low utilisation on one class mean the fleet is oversized?
Not necessarily, and assuming so skips the more useful question. A class can read low because the fleet genuinely has more trucks of that type than the work needs, or because task allocation keeps sending that class's jobs to whichever truck is nearest instead of the one actually built for them, leaving real demand sitting on a different class's ledger. The two causes call for opposite fixes, so the reading only becomes useful once it's traced back to which one applies.
How is MHE utilisation different from plan adherence?
Plan adherence checks whether task completion across the whole shift is keeping pace with the plan, wave by wave and zone by zone. MHE utilisation is narrower and equipment-specific: how much of a particular truck class's available hours were actually spent on task work in a given hour. A shift can track its plan closely overall while one truck class still sits parked for long stretches, which is exactly the kind of gap the narrower reading is built to catch.
Does a published MHE utilisation rate exist to check against?
Utilisation has no version of itself that means the same thing everywhere — how much genuine work a class should expect in an hour depends on order profile, SKU count and footprint before any allocation rule or fleet decision comes into it. WareBee checks those three first, then places your reading only against fleets doing comparably shaped work, so a quiet-looking class gets judged against trucks that were actually asked to do less, not against a fleet with nothing in common with yours.
What data does WareBee need to diagnose fleet utilisation?
Task event history by asset class — which truck did which job, and how long it took — alongside layout and order data pulled from a WMS or ERP feed, scheduled export or plain CSV, is enough for a first read. Forklift and MHE telemetry, once connected, sharpens travel time and dwell readings further, but the first utilisation comparison runs without waiting on a telematics project.
Does a revised fleet or allocation plan reach the WMS?
Yes. Once a revised task-allocation rule or fleet mix is approved, it writes back as the assignment logic and priorities the WMS already runs on, so a class stops defaulting to the nearest job and starts going to the one it was actually built for. Actuals flow back afterwards, so the next utilisation reading reflects what the fleet genuinely did under the new rule.