For a global operator, the challenge is not proving that an autonomous vehicle can move. It is building an autonomous logistics model that can be repeated across sites without forcing every terminal, airport or factory into the same process. A route that works in one port may fail under another terminal's traffic rules. An airport may need automated coupling and flight-driven dispatch. A factory will judge the same technology by whether production continues when orders change.
The practical answer is to standardise the technology and governance that benefit from scale, then localise the operating decisions that protect safety and continuity. Vehicle telemetry, software release controls, data ownership, performance definitions and support standards can be shared across a network. Task logic, traffic rules, system interfaces, energy plans and incident response remain site decisions.
This guide is for operators planning more than a single pilot. It explains where global standardisation creates value, where local adaptation is mandatory and what evidence should be required before a site moves from demonstration to regular operation.
Standardise the core, localise the operating model
A multi-site programme needs an explicit boundary between network standards and local operating design. Without that boundary, each site becomes a bespoke engineering project. Push standardisation too far, and the programme ignores the conditions that determine whether a fleet can operate safely and productively.
|
Operating layer
|
Standardise across the network
|
Decide at each site
|
Evidence required
|
|
Vehicle and telemetry
|
Data model, health reporting, software release process, audit history
|
Vehicle form, payload, coupling, weather protection and route limits
|
Duty-cycle test and interface validation
|
|
Fleet orchestration
|
Task-state model, event logging, KPI definitions and control-room principles
|
Task sources, priorities, dispatch rules and fallback procedures
|
Peak and disruption simulation
|
|
Safety
|
Hazard methodology, change control, incident taxonomy and minimum training standard
|
Speed, right of way, geofences, mixed-traffic rules and emergency response
|
Site safety case and controlled trials
|
|
Systems and data
|
Identity, access, cybersecurity, data ownership and interface governance
|
TOS, WMS, MES, airline, customs and local legacy connections
|
End-to-end task trace and exception tests
|
|
Energy and support
|
Battery-health policy, service levels, spare-parts categories and escalation paths
|
Charging or swapping capacity, tariff windows, local climate and maintenance roster
|
Availability model and local support plan
|
This distinction also improves procurement. A request for proposal can define the network standards once, while each site appendix documents its routes, systems, traffic and service requirements. Suppliers then price a common platform and the actual local work separately. That makes future expansion easier to compare and reduces the risk of hiding integration effort inside vehicle cost.
Choose the first site for learning value, not visibility
The highest-profile site is rarely the best first deployment. A useful first site has a repeatable transport task, a visible operating loss and a local team with authority to change procedures. It should also produce lessons that other sites can reuse.
Before selecting a site, ask:
-
Which task creates enough waiting, cost or safety exposure to justify change?
-
Can current task volume, cycle time, empty travel and interventions be measured?
-
Are the source systems available, and does one team own task status?
-
Can a route be introduced in stages without disrupting the whole operation?
-
Does the site have an operations owner, safety owner and IT owner with decision authority?
-
Is there a second site that could use the same network standard after the first deployment?
A site with clean roads but no meaningful bottleneck may produce an attractive demonstration and little business learning. A more valuable pilot solves a real operating constraint while keeping the initial scope controlled.
What international deployments teach about scale
Felixstowe shows why port automation needs phased change control
In July 2026, Hutchison Ports confirmed a third order that would expand the Felixstowe autonomous truck fleet to 100 vehicles. The investment also included a second automated battery swapping station. The lesson for other terminal operators is clear: fleet scale depends on traffic change control, workforce preparation, communications and energy capacity growing together.
Port of Felixstowe's implementation update and
fleet expansion announcement document those stages.
Westports shows that delivery and operational readiness are different milestones
Westwell delivered 60 E-Truck electric terminal tractors and battery swapping equipment to Westports Malaysia in August 2026. At the time of the public update, the vehicles had entered charging, commissioning and operational integration. Commercial operation was the next milestone.
That distinction matters in every large deployment. Factory acceptance, arrival on site, commissioning, limited operation and regular commercial service require different evidence. Westports also required protection for tropical heat, heavy rain, coastal humidity and salt exposure. A vehicle specification may be global, but environmental engineering, energy design, support capability and acceptance remain local.
The August 2026 project update provides the status and configuration.
Hactl and HKIA change the brief for airport ground handling automation
Airport towing is not a lighter version of container transport. Hong Kong Air Cargo Terminals Limited (Hactl) designed its initial autonomous electric tractor work around a one-kilometre route between an outdoor Unit Load Device (ULD) staging area and the intake deck of SuperTerminal 1. The development scope included automatic coupling and uncoupling for dollies with different specifications. Initial speed was restricted to 8 kilometres per hour as an additional safety measure.
The Hactl programme also planned progressive integration with the existing driver-controlled tractor fleet. That is a useful model for ground handling agents because it allows the operation to validate a specific route and physical handoff before adding longer or more complex work. At Hong Kong International Airport, Q-Tractors subsequently entered baggage and cargo transport operations, where punctuality and apron rules shape dispatch. The
Hactl project scope and
HKIA deployment show why airport adaptation must cover cargo interfaces, traffic and task timing together.
Seres shows why factory intralogistics is governed by production risk
At the Seres Zero-Carbon Smart Logistics Port, 18 Q-Trucks support automotive production logistics. Westwell's first-party project data records 32 containers per hour, about eight minutes to the welding workshop and 11 minutes to final assembly, with 856 tonnes of annual carbon dioxide reduction across the project.
The operational lesson sits behind those figures. Transport tasks follow orders and production data. Container-as-warehouse and drop-and-hook methods change how inventory and vehicle movements connect to line feeding. A factory therefore needs acceptance tests for urgent orders, material shortages, blocked routes and vehicle withdrawal. The relevant question is whether the line continues to receive material, not whether the truck completes a standard route.
Build an operating business case
Autonomous logistics business cases often begin with vehicle price and labour equivalents. That is too narrow for an investment that changes transport, software, energy, safety and operating support.
Start with the loss the programme is meant to remove. At a terminal, it may be crane waiting, congestion or inconsistent shift coverage. At an airport, it may be missed cut-offs, towing delays or difficulty staffing repetitive airside routes. At a factory, it may be line-side shortages, excess buffers or avoidable intermediate handling.
Then model total cost across:
-
vehicles, batteries and replacement cycles
-
charging or battery swapping infrastructure
-
connectivity, maps and site equipment
-
TOS, WMS, MES or airline-system integration
-
safety engineering, training and route preparation
-
control-room staffing and remote assistance
-
local maintenance, spare parts and field service
-
software support, updates and change control
-
contingency capacity during commissioning and maintenance
The model should cover a normal week, a peak period and a disruption case. Vendor range or throughput figures are useful inputs, but they do not replace a duty-cycle model built from the site's routes, loads, queues and energy windows.
Define one performance language for every site
Multi-site operators need comparable measures, even when operating models differ. The network should define each metric once and require every site to record its operating boundary, fleet size, shift pattern and task mix.
A practical core set includes:
-
cost per completed move
-
on-time task completion
-
equipment waiting for transport
-
empty distance and unladen task share
-
interventions per 100 operating hours
-
mean recovery time after disruption
-
fleet availability after energy and maintenance losses
-
safety events, emergency stops and false alarms by category
-
percentage of tasks completed without supplier assistance
Local sites can add operational measures, such as crane intensity, flight cut-off performance or line-side delivery adherence. The common core allows an operator to compare whether a second site is improving faster, carrying more local support cost or generating more interventions than the first.
Use deployment gates that produce reusable evidence
A global rollout should create a reusable package at every stage.
|
Gate
|
Evidence to produce
|
Do not advance if
|
|
Baseline and operating design
|
Current task map, loss baseline, safety scope, data ownership and local responsibilities
|
The site cannot explain where tasks fail or who owns recovery
|
|
Simulation and controlled testing
|
Peak model, disruption cases, route and handoff validation, energy-capacity model
|
Testing covers normal flow only
|
|
Limited live operation
|
Results across real shifts, interventions, recovery records and trained site operators
|
Supplier engineers still resolve routine exceptions
|
|
Mixed-traffic and peak validation
|
Evidence under representative demand, traffic and equipment delays
|
Safety rules or task priorities require frequent manual overrides
|
|
Scale and replication
|
Support model, spare-parts plan, release controls and a second-site template
|
Alert and support workload grows almost in line with fleet size
|
The output of the first site should include more than performance results. It should leave behind a task-state model, interface specifications, safety scenarios, training materials, operating procedures and an acceptance template. Those assets are what reduce the cost and risk of the next deployment.
Questions global operators commonly ask
What separates a successful pilot from commercial readiness?
Commercial readiness requires sustained results across representative shifts, peaks and disruptions. The site team must be able to handle routine exceptions, and local maintenance, energy supply, spare parts and escalation procedures must already be in place. A successful demonstration proves a route; commercial readiness proves an operating model.
Should a terminal electrify first or move directly to autonomy?
The answer depends on route stability, digital readiness, safety scope and the urgency of decarbonisation. An electric terminal tractor can address tailpipe emissions and operator conditions while the site prepares automation. A fully autonomous vehicle needs task integration, traffic rules and remote operations from the start. Mixed fleets can support a phased transition if one scheduling layer manages both.
What is usually the largest hidden cost?
Integration and operating support are frequent sources of unplanned cost. Vehicle deployment exposes unclear task ownership, inconsistent system status and gaps in incident response. A total-cost model should therefore include integration, control-room work, local engineering, training, energy and long-term support.
Scale comes from repeatable evidence
Autonomous logistics scales when a network can repeat the parts that benefit from common standards and make local decisions without redesigning the whole platform. The first deployment should therefore produce two outcomes: better site performance and a reusable operating package for the next location.
Westwell's
industry solutions cover ports, airports, logistics parks and manufacturing. For operators planning a multi-site programme, the most useful starting point is one real transport flow and one candidate second site. Together, they reveal which decisions should become network standards and which must remain local.
