When a Thai factory evaluates a forklift call and dispatch system, replacing a factory call bell with a wireless button is not enough. “The button was pressed” and “a driver’s device rang” do not reveal who accepted the job, which truck was assigned, when it arrived, or why the request waited. A useful system follows the material-movement request from acknowledgement and assignment through pickup, delivery and closure. This guide turns that operating model into a 30-day proof of concept, an RFP and reproducible FAT/SAT evidence.
What a forklift call and dispatch system should solve
Many plants use several channels at once: a bell, an extension call, radio, chat and a handwritten board. The contact may work, yet ownership disappears after the message is sent. The next improvement meeting has no reliable answer to three questions:
- Who accepted responsibility, not merely who received a notification?
- Which qualified truck and operator were assigned, and under which priority rule?
- How much time passed at acknowledgement, assignment, arrival and completion?
The minimum solution therefore needs a call input, a dispatch decision, driver notification, positive acceptance, event history and a supervisor queue. A PLC, gateway, WMS or MES integration can follow, but the business states and accountable roles come first.
Safety boundary: dispatch does not replace forklift safety controls
This boundary is non-negotiable. A call/dispatch platform is not a collision-avoidance device, safety-rated control, traffic rule, horn, warning light, physical separation, trained spotter, operator training programme or approved emergency channel. A mobile “arrived” status never proves that a travel path is clear. Site risk assessment, Thai law, manufacturer instructions, EHS approval and applicable standards remain authoritative.
US OSHA forklift guidance discusses separating forklift and pedestrian traffic where possible, yielding to pedestrians, sounding a horn at obstructed locations, maintaining a clear view and using a spotter for blind spots when needed. It also addresses operator training and evaluation. These are US references, not Thai law, but they clearly illustrate why a workflow notification cannot replace physical and procedural traffic controls.
ISO 3691-4:2023 addresses safety requirements and verification for driverless industrial trucks and their systems, and its official abstract notes that operating-zone conditions materially affect safe operation. A workflow that sends jobs to human-operated forklifts does not become compliant with that standard by using software. If AGVs or AMRs later share the job pool, keep business assignment and the driverless-truck safety system as separately reviewed boundaries.
Move from a factory call bell to a stateful dispatch workflow
A bell expresses only that somebody wants attention. A dispatch workflow gives each request a unique job_id and controls seven states:
requested → acknowledged → assigned → arrived → loaded → delivered → closed
| State | Business meaning | Minimum evidence |
|---|---|---|
| requested | A valid movement request exists | job ID, type, pickup, timestamp |
| acknowledged | Dispatch or the responsible team accepted the queue item | actor, time, channel |
| assigned | A specific eligible truck/operator owns it | vehicle, operator, priority |
| arrived | The assignee reached the defined pickup zone | time and verification method |
| loaded | The identified load was handed over | load ID, quantity, exception |
| delivered | The load reached the defined destination | destination, time, receiver |
| closed | Completion or cancellation is approved | result, reason, approver |
If acknowledged and assigned are collapsed, “dispatch saw it but nobody is going” becomes invisible. If delivered and closed are collapsed, a quantity discrepancy or rejected delivery can look complete. The operator screen may remain simple; the underlying model should preserve the distinctions.
Standardise factory call points and operator call notifications
Inputs can include fixed buttons, tablets, HMIs, barcode scans, Andon events or MES screens. Whatever the device, normalise the payload:
call_point_id, kept stable even when the displayed location name changes;request_type, such as empty pallet, replenishment, finished-goods removal or non-emergency assistance;- controlled
pickupanddestinationmasters rather than free text; load_idfor a pallet, lot, kanban or handling unit;- priority derived from line-impact rules, not the requester’s preference;
- device occurrence time, server receipt time and timezone;
- whether the requester is a person, role, workstation or machine.
A physical button is fast but expresses little context and needs debounce and accidental-press handling. A tablet carries details but introduces gloves, login, charging and breakage. An automatic PLC/Andon call needs rules for chattering, duplicate alerts and repeat requests before recovery. These are acceptance cases, not details to postpone until rollout.
Separate delivered, viewed, acknowledged and accepted
The most common mistake in real-time manufacturing-floor notification is treating push delivery as business acceptance.
| Evidence | What it proves | What it does not prove |
|---|---|---|
| broker accepted | Messaging infrastructure took the message | Device or human received it |
| device delivered | Target endpoint received it | It was read or owned |
| viewed | A user opened it | Responsibility was accepted |
| acknowledged | Dispatch/team accepted the request into its queue | A truck/operator owns it |
| assigned/accepted | A named resource accepted responsibility | It has arrived |
| arrived | The resource reached pickup | Loading and delivery completed |
An RFP might use an illustrative SLO such as “90% of ordinary replenishment calls acknowledged within 60 seconds”. That is a design example, not an industry standard, guarantee or emergency criterion. Recalculate it from the site baseline, staffing, zones and operating risk. A timeout should transfer responsibility through a defined escalation chain rather than just send more noise.
Dispatch eligibility before shortest distance
Assigning the nearest truck sounds efficient, but distance alone ignores capacity, attachment, licence/qualification, permitted zone, battery, current load, one-way aisles, segregation, shift and higher-priority work. Ask bidders to explain the decision in five stages:
- Filter out ineligible trucks and operators.
- Apply product, route and zone constraints.
- Rank line-stop risk, promised time, age and load criticality.
- Compare estimated travel and queue among eligible candidates.
- Allow controlled human override with a reason and audit trail.
“AI dispatch” is less important than explainable inputs, exclusion reasons, tie-breaking, override authority and regression tests. For a small PoC, transparent rules may be easier to validate than a model trained on a thin history.
Measure waiting time from event rows
Use consistent timestamp definitions:
ack_time = acknowledged_at − requested_atassignment_time = assigned_at − acknowledged_attravel_wait = arrived_at − assigned_atservice_time = delivered_at − arrived_attotal_lead_time = closed_at − requested_at
Show p50, p90/p95, maximum, SLO breach rate, open jobs, cancellations and reassignments. An average alone hides the long tail and shift differences.
Consider a wholly fictional baseline of 48 eligible calls per day, median wait 11 minutes, p90 24 minutes and 12% without auditable acknowledgement. Do not multiply 48 by the median and call it total waiting time; a median is not a per-row total. Sum each eligible arrived_at − requested_at instead.
If the fictional event rows total 528 minutes/day before the PoC and 336 after, released time is 192 minutes or 3.2 hours/day. At 250 operating days, that is a theoretical 800 hours/year. It is released capacity, not automatic payroll saving. Monetise only the portion demonstrably redeployed to throughput, overtime avoidance or reduced shortage stops.
Put denominator and exclusions in the RFP
If an example target says “95% arrive within eight minutes”, define whether the clock starts at request or assignment, whether arrival is a button, scan or geofence, and whether an unprepared load is excluded. The eight-minute value in this article is only an illustrative proposal for one defined zone and ready-load conditions.
Use controlled reason codes for planned shutdown, test call, requester cancellation, network outage, vehicle fault and load not ready. Classify responsibility and publish both the SLO result and excluded volume. A supplier must not improve the result by hiding bad events in free-text exclusions.
Define ERP, WMS, MES, dispatch and OT ownership
ISA-95 provides a technology-neutral language for enterprise/logistics and manufacturing-control integration. Use it to separate systems of record rather than force everything into one app.
| System | Primary responsibility | Must not silently own |
|---|---|---|
| ERP | order, item and financial inventory records | second-by-second vehicle dispatch |
| WMS | location, handling unit and warehouse task | vehicle safety control |
| MES | production order, line state, material consumption | traffic rules |
| Dispatch | call, queue, assignment, acknowledgement, arrival, exception | unauthorised inventory correction |
| PLC/Andon | machine state and approved field signals | identity and enterprise masters |
| Safety/EHS controls | risk reduction and traffic operation | changes made to improve dispatch KPI |
A common flow is MES shortage → dispatch job → WMS pickup/load identity → dispatch assignment → delivery confirmation to WMS/MES. If the project writes to a PLC or control layer, separate that scope from read-only monitoring and require manufacturer approval, change control, backup, rollback and dedicated FAT/SAT.
Choose MQTT, OPC UA and APIs by boundary
MQTT 5.0 is an OASIS lightweight client/server publish-subscribe transport used in M2M and IoT settings. It is useful for distributing events from many call points, but its delivery behaviour does not prove that a material movement completed exactly once. Retries must use an idempotency key so that one request cannot become two active jobs.
OPC UA defines information, message, communication and conformance models and supports ClientServer and PubSub. It can expose structured PLC or gateway context. Its security model provides mechanisms for authentication, integrity and confidentiality, while the official specification leaves required deployment choices to site designers. “Uses OPC UA” is not a security acceptance criterion.
REST APIs often suit WMS/MES request-response and master lookups. A project can use OPC UA at equipment, MQTT from edge to platform and REST at the business boundary. The RFP should define schemas, versions, timestamps, retries, timeout, deduplication, ordering, offline buffer, errors and certificate/key rotation—not only protocol names.
For gateway ownership, lifecycle and offline design, see the Industrial IoT Gateway Selection Guide for Thai Factories.
Improve shop-floor communication without notification fatigue
Broadcasting every call to everyone looks fast on day one and becomes background noise later. Route by role, zone, shift, qualification and availability. Escalate only when the first owner fails to accept. Avoid sending to personal devices outside working time; record user changeover on shared devices; expire contractor access.
Use sound, vibration and screens for different purposes. A short ordinary call may use vibration and concise text; detail belongs on a stopped operator’s screen. Do not replace horns, warning lights, signs, fixed alarms or other approved safety measures with a phone notification. For radio/PTT and mixed-channel design, see the Factory Intercom Alternative Guide for Thailand.
Treat offline, retry and duplication as normal cases
Factory communication fails during maintenance, power events, AP restart and WAN outage. Show the last server-confirmed time, buffered count and degraded mode. If an offline call cannot be accepted, return a visible failure and switch to an approved alternate channel; never fail silently.
Each event should carry job_id, event_id, occurred_at, recorded_at and sequence/version. On recovery, do not rebroadcast stale requests as current emergencies. Validate state transitions instead of trusting arrival order. FAT should resend the same request ten times, cancel while disconnected and restart the server after assignment. An illustrative acceptance rule is zero unresolved duplicate active jobs.
Build cybersecurity and privacy into procurement
NIST SP 800-82 Rev.3 addresses OT security while considering performance, reliability and safety. Register call points, gateways, dispatch servers, mobile devices and WMS/MES interfaces as assets. Specify segmentation, least privilege, allowlists, certificate/key lifecycle, logs, backups, vulnerability response, remote maintenance and change control.
If operator identity or location is used, work with Thai legal and HR teams on purpose, granularity, retention, access, worker notice and investigation procedures. Ask whether continuous precise location is necessary. If a pickup-zone arrival event is enough, collect less.
A 30-day PoC: narrow footprint, broad exceptions
This implementation pattern uses two zones, three call points, two shifts and at least 120 calls. It is an example, not a standard or guarantee; recalculate for the site’s call rate and risk.
| Period | Work | Exit evidence |
|---|---|---|
| Days 1–5 | Observe, define events, baseline, network walk, confirm safety boundary | approved timestamps, scope, exclusions and RACI |
| Days 6–15 | Configure call points, workflow, devices, dashboard and limited integration | normal flow, identity and logging work |
| Days 16–25 | Run day/night shifts and fault/exception cases | 120+ calls, exception evidence, user feedback |
| Days 26–30 | Calculate KPI, close gaps, hand over SOP and RFP/FAT/SAT inputs | approved go/modify/stop decision and open risks |
Include double press, wrong pickup, load not ready, rejection, shift handover, flat battery, AP outage, server restart, cancellation, reprioritisation and vehicle fault. A happy-path demo is not a PoC.
Separate PoC technical SLOs from business outcomes
Illustrative gates might be: 90% ordinary calls acknowledged within 60 seconds; 95% ready-load calls in one defined zone arrived within eight minutes; zero unresolved duplicate jobs after retry; unaudited acknowledgements reduced from 12% to below 2%; p90 reduced from 24 to 14 minutes. All are fictional project values, not promises.
Assess four layers separately:
- technology: delivery, latency, offline recovery, security and device health;
- workflow: completeness of acknowledgement, assignment, arrival, exception and closure;
- operations: line wait, travel imbalance, unprepared load and operator workload;
- business: avoided stop, throughput, overtime, inventory discrepancy, operating cost and scalability.
RFP requirements that bidders can actually test
Business and function
- Submit the seven states, allowed/forbidden transitions, cancellation, reassignment, priority change and override design.
- Preserve unique job/event IDs and export who changed what and when.
- Explain candidate filtering by role, zone, shift, qualification and truck capability.
- Distinguish unacknowledged, unassigned, overdue and offline call points on the dashboard.
- Support concise operator language required at the site.
Non-functional and service
- Declare availability and latency measurement window, denominator, planned maintenance and degraded-mode treatment.
- Define offline retention, overflow, retry, deduplication and out-of-order recovery.
- Define backup/restore, monitoring, incident, patch, certificate renewal, log retention and support language.
- State which device replacements, call-point relocations and zone/master changes the local team may perform, what approval is required and how each change is audited and rolled back.
- Separate five-year TCO for devices, network/SIM, cloud/on-premises, integration, licences, support and upgrades.
Safety and accountability
- State that the platform is not a safety function and does not replace traffic controls or emergency channels.
- Separate read-only monitoring from any PLC/control write and require approval and rollback.
- Submit RACI for logistics, production, IT/OT, EHS, maintenance, vendor and subcontractor.
- Disclose hosting, remote access, data ownership and end-of-contract export.
FAT: prove logic and recovery
FAT should run every request type, allowed and forbidden transition, repeated button/API calls, out-of-order events, dispatch absence, rejection, timeout escalation, gateway/broker/WMS outage, offline device and recovery reconciliation. Security cases must include a role violation, invalid token, leaver account, expired certificate and detection of log tampering. Reconcile dashboard and export results with source events. Freeze software/configuration versions and record expected versus actual evidence. FAT does not prove factory radio coverage or site safety; list simulator limits for SAT.
SAT: prove the real operating environment
Use actual zones, racks, doors, shifts, trucks, accessories, Wi-Fi, WMS/MES and operators. Test handover, lunch congestion, load-not-ready cases and a planned network interruption under an approved safe procedure. Compare displayed state with physical state and define the authoritative source when they disagree.
Test the weakness of each arrival-evidence method: a button can be forgotten or pressed at the wrong place, BLE/geofence can trigger early or miss a boundary, and a barcode scan adds an operator step that may be skipped or performed against the wrong label. Select the method from the required evidence quality and operating burden, then verify it in the real zone. Safety-function tests must be executed separately by authorised, competent personnel under approved procedures; the dispatch SAT must never be used as a substitute.
Acceptance deliverables should include as-built diagrams, ports, roles, certificates, masters, restore evidence, training, SOPs, escalation, maintenance contacts, licences and configuration/data export conditions. A moving icon on a screen is not sufficient acceptance.
Buy, build or hybrid?
| Decision | Package/SaaS | Custom/low-code | Hybrid risk |
|---|---|---|---|
| Workflow | Operations can adopt standard states | Exceptions are genuinely differentiating | Keep extensions outside the core |
| Integration | Standard connectors cover systems | Legacy PLC/MES/WMS dominates | Name one interface owner |
| Operation | Vendor SLA/model is acceptable | Site must retain data/control | Avoid split incident ownership |
| Change | Product roadmap is acceptable | Rules change frequently | Contract upgrade regression tests |
| Cost | Scale and licence are predictable | Narrow special scope is stable | Count both subscription and gateway |
Give vendors your exception scenarios and sample data. Ask the site supervisor—not only the vendor—to operate the demo. Weight successful scenarios, evidence, recovery, local support and five-year TCO above the number of feature checkboxes.
Control the standardisation rate when scaling by zone
A plant-wide rollout immediately after one PoC causes location names, request types, priority rules and vehicle masters to proliferate by site. Separate a global template from local extensions, and keep the timestamp definitions behind common KPIs fixed. At the same time, permit genuine site differences in traffic rules, language, shifts, vehicles, network conditions and legal/EHS requirements.
Passing in one pilot zone does not authorise automatic rollout to a long-distance yard, cold store, hazardous area, outdoor route or contractor-operated fleet. Put every zone through a readiness checklist. Increase call points and trucks in controlled batches, and scale local support capacity at the same time.
FAQ
What is a forklift call and dispatch system?
It receives a material-movement request and tracks acknowledgement, assignment, arrival, delivery and closure. Unlike a bell or chat message, it records accountable ownership and waiting-time events. It is not a collision-avoidance or safety-control system.
Is a wireless factory call bell enough?
It may be enough for a tiny area with one guaranteed responder. For measurable waiting-time reduction, require job ID, acknowledgement, assignment, arrival, exceptions and KPI definitions.
Who should receive an operator call notification?
Eligible on-shift recipients selected by role, zone, qualification, truck capability and current load. Escalate only after the primary owner times out.
How fast is “real-time” on the manufacturing floor?
There is no universal number. Derive an SLO from business risk and baseline. The 60-second acknowledgement and eight-minute arrival values here are fictional procurement examples, not emergency criteria.
How should efficiency benefit be calculated?
Sum actual event-row waiting and compare like-for-like baseline and PoC periods. Do not multiply a median by volume. Treat released hours as capacity until redeployment is proven.
How should a 30-day PoC be costed?
Price call points, operator devices, gateway/network, workflow configuration, WMS/MES integration, cybersecurity, site work, training, support and either removal or production migration as separate lines. The two-zone, three-call-point, two-shift and 120-call scope in this guide is only an example; re-estimate after the site survey.
Can it replace forklift safety devices or traffic rules?
No. Keep collision avoidance, horns, warning lights, physical separation, spotters, training, traffic rules and emergency communications under the site’s risk assessment and EHS process.
Conclusion
A forklift call and dispatch system creates value when it converts a bell into a controlled seven-state job, separates delivery from acceptance, measures waiting from event rows, survives offline/retry and defines ERP/WMS/MES/OT ownership. A narrow 30-day PoC with broad exception testing can produce the evidence needed for a Buy/Build decision, a testable RFP and distinct FAT/SAT gates—without weakening existing safety controls.
TOMAS TECH can help a Thai plant map call points, dispatch rules and WMS/MES boundaries before committing to a product. If you want to define a 30-day PoC and acceptance evidence while preserving existing traffic and safety measures, contact TOMAS TECH.
