Common challenges
Forklifts you don't need,queues you do.
Reach trucks queue at the pick face during the rush and sit parked for most of the shift around it — a fleet sized for the one hour that breaks the day, then carried as spare capacity for every hour that isn't. The fix isn't fewer trucks or more of them, it's knowing which asset class a task actually needs, hour by hour, before the next lease renews.
See hardware & telemetry
Is this your problem?
How to tell an over-fleeted yard from a genuinely busy one.
Utilisation doesn't have one clean industry number the way travel or dwell time do, so the diagnostic has to be built from two things read together: how each asset class — forklift, reach truck, pallet truck — is actually used across an hour, and how many task minutes that hour's work genuinely required of that class. When utilisation regularly sits well under what the hour demanded, the fleet is oversized or misallocated for the work in front of it. When it tracks the task minutes, the same truck count is simply doing what it's there to do.
It happens because the fleet gets sized once, for the worst hour of the year, and then never revisited for the hours around it. Task allocation compounds it — a job goes to the nearest free vehicle rather than the class actually built for it, so a travel-heavy run ties up a fast reach truck while a pallet truck built for exactly that job sits at the dock. And because forklift telemetry and WMS task data usually live in separate systems, nobody ever sets utilisation against task minutes to see either problem before the lease renews.
WareBee scores fleet utilisation against a peer set matched on order profile, SKU count and footprint — never a blanket industry figure — so 'we've got too many trucks' or 'we never have the right one free' becomes a specific asset, shift and hour you can point at, argue with and act on.
What's actually causing it
Four places the fleet gets it wrong.
Each one is measured on your digital twin from data you already generate, so you can see which applies to you before the next lease renews.
Fleet sized for peak hour, idle the rest
The truck count was fixed to survive the worst hour of the day, then never revisited for the hours either side of it.
Utilisation for every asset class is measured against the task minutes that hour's work actually required, so a fleet that was right for the peak and wrong for the rest of the shift stops being a guess. What-if scenarios test a smaller core fleet, a different class mix or a rental buffer against your own peak before a lease renews.
Task allocation ignoring asset class
A reach truck picks up a job built for a pallet truck because it was the nearest free vehicle, not the right one.
Each task carries the equipment class it actually needs, checked against how many trucks of that class are free before the work is assigned, rather than handed to whichever vehicle happens to be closest. Where that check doesn't run, one class stays fully booked while another with spare capacity sits at the dock.
Travel-heavy tasks on the wrong equipment
A long run to a far dock lands on whichever truck was nearest, not the class built to cover the distance.
Location and utilisation feeds from the fleet enrich travel-time analysis, so a task with a genuinely long run can be matched to the class built for distance rather than the one that happened to be closest to the pick face. Left unmatched, that travel-heavy work quietly sets the pace for the whole class it landed on.
Utilisation invisible between telematics and WMS
The telemetry exists, the task data exists, and nobody has ever joined the two into one number.
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 living in a separate telematics dashboard. Joined into the digital twin, utilisation and workload finally sit on one comparable scale instead of two systems nobody cross-checks.
Fit the fleet to the hour, not just the peak.
WareBee measures utilisation for every asset class — forklifts, reach trucks, pallet trucks — against the task minutes that actually required that class that hour, on your digital twin, so a fleet sized for the one hour that breaks the day stops being invisible for the rest of it. Task allocation checks the equipment class a job needs before it checks which truck is nearest, so a travel-heavy run lands on the class built for distance and a short hop doesn't tie up a machine rated for more.
Because it runs on your digital twin, you can test a smaller fleet, a different class mix or a rental buffer against your own peak before a lease renews or a purchase order is signed — and see the CO₂ line move alongside the utilisation number, not only the cost one. Your team approves the plan; the WMS receives it as the tasks and equipment assignments it already understands.
- Utilisation measured by asset class and hour, against task minutes
- Tasks assigned by equipment class needed, not the nearest truck
- Fleet mix and sizing tested on the twin before a lease renews
Questions
Forklift and MHE utilisation, answered.
How do you measure utilisation across a mixed fleet of forklifts, reach trucks and pallet trucks?
Every asset's utilisation is read against the task minutes that actually required its class, hour by hour, using the same telemetry event model regardless of which manufacturer built the truck. A reach truck from one brand and a pallet truck from another land on one comparable scale for dwell, travel and utilisation, so a mixed or mixed-age fleet doesn't need normalising by hand before the comparison means anything.
Do I need forklift telematics to get a first answer, or can WareBee start without it?
No. WareBee starts from data you already generate — WMS and ERP task records, scans, or a simple CSV export are enough for a first utilisation read by asset class. Forklift and MHE telemetry sharpens travel time, dwell and congestion analysis considerably once it's connected, but it's an enhancement rather than a prerequisite for finding out where the fleet is over- or under-used.
How do I tell an over-fleeted yard from a scheduling problem?
Compare utilisation by asset class against the task minutes that actually required that class, hour by hour. If a class sits well under what the hour's tasks demanded even though every task was assigned promptly, the fleet itself is oversized. If the same class is fully booked but tasks queue waiting for it because allocation sent work to the nearest truck rather than the right class, that's a scheduling fix, not a purchase order.
What happens at peak versus the rest of the year?
Peak is usually the stretch where the fleet actually earns its size — task minutes for every class run close to what's available. The rest of the year is where the same fleet, sized for that peak, sits parked for long stretches. What-if scenarios test a smaller core fleet plus a rental or reallocation buffer for peak weeks, so the trucks bought for the worst week stop being dead weight for the weeks around it.
What data do you need to diagnose an MHE bottleneck?
Reading fleet utilisation needs task event history by asset class — which truck did which job, and how long it took — alongside your layout and order data, pulled from a WMS or ERP feed, scheduled export or plain CSV. That's what lets each asset class's actual hourly usage get set against the task minutes the work genuinely demanded. Forklift and MHE telemetry, once connected, lands in the same event model as every scan and sharpens travel time and dwell readings further, but the first utilisation comparison runs without waiting for a telematics project.
Once a fleet mix or task-allocation rule changes, does that update actually reach the WMS?
It reaches the WMS. Once a revised task-allocation rule or fleet mix is approved, the change writes back as the assignment logic and priorities your WMS already runs on — a reach truck stops defaulting to the nearest job and starts going to the one its class was actually built for. Nothing about the rest of the fleet's scheduling changes; only the allocation rule that was measured to be misrouting work updates. Actuals flow back afterwards, so the next utilisation read reflects what the fleet genuinely did under the new rule, not the projection that justified it.