Dispatcher Proof of Concept

Control Forklift and Material Tasks in One Live Area

Tasks stop being shouted across the hall. They are queued by priority, assigned to a specific operator, accepted, executed and confirmed — and for the first time the queue age, response time and rejected-task count are numbers rather than impressions.

Pilot my dispatch area Talk to a manufacturing engineer

Typical duration3–6 weeks

Pilot scopeOne area, selected forklifts and operators, defined task types

Primary buyerLogistics Manager

Decision at the endRule configuration and scale plan for further areas

Is this the problem you need to solve?

Forklift tasks are assigned by radio and by whoever shouts loudest.
Urgent tasks queue behind routine ones because there is no queue to see.
Two drivers arrive for the same pallet while another request waits.
Nobody can say how busy the fleet actually is, only that it feels busy.

Primary buyer: Logistics Manager · Warehouse Manager · Production Manager · Shift Manager

What this PoC will prove

Can tasks be queued, prioritised and assigned digitally without adding radio traffic?

Will operators accept and confirm tasks on the device every time, including on the late shift?

What is the real queue age and task response time once they are measured?

Does the priority rule survive contact with a genuinely busy shift?

How much of the fleet’s time is travel, and how much is waiting for an instruction?

Recommended pilot scope

One area with a real task backlog, not the quietest corner of the plant.
Selected forklifts and their operators, across the shifts that run.
The task types that matter — typically supply, removal, transfer, replenishment and put-away.
Priority and escalation rules as they should be, agreed before the pilot.
Source and destination points with barcode confirmation.

What will be live during the PoC

Live dispatch board with the queue, priorities and current assignments.

Operator device flow: receive, accept, navigate, confirm.

Priority and escalation rules applied automatically as the queue grows.

Task history with timings, rejections and exceptions.

How this PoC runs

Week 1

Discovery and decision definitionDefine the area, task types, priority and escalation rules, and agree what a service-level breach means here.Exit gate: Task types and priority rules agreed with the shift managers.

Week 1

Baseline measurementObserve the current assignment method for a representative period: how long requests wait, how many are forgotten, how often two drivers duplicate a job.Exit gate: Baseline observed and accepted.

Week 1–3

ConfigurationConfigure locations, task types, rules and devices, and train the operators on their own machines during their own shifts.Exit gate: Every pilot operator completes a task unaided.

Week 3–5

Controlled live operationThe area runs on the dispatch board across all shifts, with queue age, response, execution time and rejections tracked.Exit gate: A full production week including the busiest shift.

Week 5–6

Rollout decision and business casePresent the KPI baseline versus pilot, the exception list, the rule configuration and the scale plan.Exit gate: Go, adjust or stop.

Durations are typical, not guaranteed. What extends a schedule: missing or incomplete data, security and network approvals, hardware lead times, sample collection, installation access, the production schedule, ERP test access, and the time your team needs to review results.

No unplanned shutdown is expected. Any installation window or controlled interruption is agreed with you in advance and scheduled around production.

How success will be measured

How success will be measured
Metric	How it is defined	Where the number comes from	Type
Queue age	Age of the oldest waiting task, sampled through the shift, and its distribution.	MSF platform data	Operational
Task response time	Time from a task being created to an operator accepting it.	MSF platform data	Operational
Execution time	Time from acceptance to confirmed completion, by task type.	MSF platform data	Operational
SLA compliance	Share of tasks completed within the agreed service target for their priority.	MSF platform data	Operational
Rejected and reassigned tasks	Tasks refused or reassigned, with the reason — the signal that a rule does not match reality.	MSF platform data	Technical
Wrong-delivery incidents	Confirmed deliveries to the wrong destination during the pilot, versus the observed baseline.	Agreed baseline measurement	Operational
Operator utilisation	Share of shift time spent on confirmed tasks versus waiting or travelling empty.	MSF platform data	Operational

Before implementation, MSF and your team agree how each metric is calculated, where the baseline comes from, what data is excluded, and what result supports a rollout decision. This page lists what gets measured; the actual targets belong in the written PoC scope, not in a marketing claim.

What you need to provide

Task types, priorities, locations and the materials involved.
Operators, shift coverage and the devices available or to be provided.
Service targets and escalation rules, including who is allowed to override a priority.
Permission to observe the current method honestly during the baseline period.

Who does what

Meta Smart Factory provides

Discovery workshop and scope facilitation
Solution configuration for the agreed scope
Integration and connection work inside that scope
MSF hardware listed in the proposal
Training for the pilot users
The KPI definitions and validation method
Issue tracking and support during the pilot
The final result report and rollout design
The configured dispatch board, rules and operator flow for the pilot area.
An exception list showing where the rules produced the wrong answer in practice.

You provide

A named business owner and a named technical owner
Timely access to users, the line, machines and approved systems
An accurate explanation of the process and the master data
Network, power, mounting and safety access
ERP, PLC and vendor documentation, plus the experts who know them
Representative samples or historical data
Validation that the baseline is fair
Feedback and the acceptance decision
Operators for the full live period, including nights and the busiest shift.
A shift manager empowered to adjust a priority rule when the pilot shows it is wrong.

Defined in the written proposal

Panel PCs, tablets, servers and GPU servers
Cameras, lenses, lighting and enclosures
Scanners, printers, RFID readers, meters and sensors
Travel, installation, freight, import duty and local electrical work
Whether hardware is rented or purchased
Whether any PoC fee is credited against a rollout

Commercial terms, hardware ownership, travel, integration scope and any rollout credit are defined in the written PoC proposal. They are not the same for every product, and this page does not promise them.

What you receive at the end

A live dispatch board for the pilot area.
Operator mobile flow configured and trained.
Priority and escalation rule configuration as tuned during the pilot.
KPI baseline versus pilot comparison.
Exception list with the rules that needed adjustment.
Scale plan for the remaining areas and fleet.

Dependencies, exclusions and limits

This PoC depends on

Device and network coverage across the pilot area, verified during readiness.
Shift managers willing to run the queue rather than route around it.

Not included in this PoC

AGV dispatching and automated vehicle control.
Forklift telematics, fleet maintenance and driver-safety systems.

What this PoC does not claim

Utilisation and queue numbers describe the piloted area during the piloted period. They are a baseline for a rollout decision, not a fleet-sizing conclusion — that needs a longer observation window across seasonal demand.

Go, adjust or stop — the decision gate

GoGo: response and SLA improve and operators use it — extend the dispatch board to the remaining areas.

AdjustAdjust: the priority rules or device coverage need rework; the exception list says which.

StopStop: the constraint is fleet capacity or layout, which the queue data now proves rather than implies.

Frequently asked questions

How many forklifts should be in the pilot?

Enough that a queue genuinely forms — usually the whole fleet of one area rather than a couple of vehicles. A pilot with no contention cannot prove that prioritisation works.

Do operators need new devices?

Existing rugged tablets or terminals are reused where they meet the requirement, and that is checked during readiness rather than assumed. Where new devices are needed, they are listed in the proposal with their cost.

What if drivers ignore the system?

That is a genuine risk and it is measured, not hoped away — rejected tasks, unconfirmed tasks and shift-by-shift adoption are on the scorecard. If adoption collapses on the night shift, the PoC will show it and say why.

How does this relate to the WMS and Logistics PoCs?

Dispatcher assigns and confirms the task. WMS knows what and where the stock is. Logistics measures the flow the tasks belong to. Each can be proven alone; together they are one scope and a longer schedule.

Request this Proof of Concept

Tell us the scope you have in mind and we will come back with a written PoC plan: what gets connected, what you provide, how success is measured and what the decision at the end looks like.