Passenger help and emergency support in a driverless service

The absent driver leaves real work to allocate

A passenger presses a help button because a shuttle has stopped unexpectedly. There is no driver to explain the delay, check whether anyone is hurt or decide whether the doors should open. The automated driving system can manage its own movement, but someone still has to speak to passengers, locate the vehicle, arrange help and coordinate with emergency responders. A service that has not allocated those tasks is not ready simply because the vehicle can complete a normal route.

The Department for Transport's pilot applicant guidance expects an automated passenger service applicant to describe remote or in-person passenger support, including during incidents, and to give passengers a clear means of communication. It asks for contingency planning, safeguarding, an incident management plan and procedures for emergencies and evacuation. It also says passengers should have onboard safety information and a way to obtain remote support. These are service and operator tasks distinct from proving that the automated vehicle can drive itself.

This page owns the passenger-help and emergency-response operating model. The APS permit overview owns the wider permit. The accessibility owner deals with the whole passenger journey and disability access. A separate incident-reporting owner can explain notification and record obligations. This guide focuses on what happens from the moment a passenger needs help through safe recovery, responder handoff, investigation and service restart.

The actual Vehicle Special Order and APS permit may impose specific conditions. Government guidance describes expectations, but a web page cannot determine the reporting category, deadline or operational requirement for a particular deployment. A passenger safety specialist and transport lawyer should review the proposed service, vehicle and issued instruments before publication or launch.

Define help before the first journey

Passenger help is not one undifferentiated call centre task. A booking question, a passenger unable to board, a lost child, harassment, illness, a breakdown and a vehicle fire require different people and responses. Create a service taxonomy that identifies how each concern enters the system, who receives it, what information they need, when they escalate and who has authority to pause the journey. Include passengers who cannot use a smartphone or speak to a voice agent.

The service should state its hours of operation and support coverage. If vehicles run at night, help cannot be available only during office hours. The operator should know the number of vehicles one team can support, how calls are prioritised and what happens when several journeys need help at once. A nominal telephone number is not a support capability if it routes to voicemail during a live service. Test the real queue and staffing model during an exercise.

Give passengers more than one practical way to ask for help. An onboard control, app, voice channel, text route or accessible alternative may be suitable depending on the vehicle and users. Each channel should acknowledge receipt and explain what happens next. A passenger should not have to guess whether a request reached a person. If the vehicle loses connectivity, the design needs a fallback for both passenger communication and vehicle safety. The two problems may have different solutions and owners.

The support worker should see the correct vehicle, location, route, passenger contact method and current vehicle state without exposing more personal information than needed. The interface should make it hard to confuse two similar shuttles. If the support provider is separate from the permit holder, the contract must establish access to those facts and the ability to summon recovery or emergency services. The DfT guidance says the permit holder remains responsible for the APS operation even where third parties supply customer support or other services.

Keep passenger support distinct from remote driving

A person who reassures a passenger or arranges a replacement journey is not necessarily controlling the vehicle. A remote automated-driving-system assistant may give bounded advice to the vehicle. A remote person who steers or must watch the road to intervene immediately raises a different legal and safety question. Do not give a passenger-support worker a motion control without a full legal and engineering assessment. The current no-safety-driver pilot guidance expects remote ADS assistance to be limited to advice in its operator assessment, with tested communications and fallback.

Draw the interface boundary. What can passenger staff do? They may be able to contact passengers, ask the vehicle to remain stopped, request a route review or dispatch a recovery team. Which commands affect vehicle motion, doors, power or access? Who can authorise them? What independent checks does the vehicle apply? A command labelled emergency override may have significant safety implications. The operator should test permissions, logs and safeguards rather than assume the job title defines the legal role.

The service should coordinate the passenger and vehicle sides of an event. If the vehicle reports a sensor fault and stops, the ADS team needs technical information, while passenger support needs to know what to tell people and when to arrange another journey. A single incident identifier can connect the records, but each team must retain the details it needs. A safe vehicle stop does not complete the passenger duty if someone is stranded at an inaccessible roadside location.

An operator should also know when it has no reliable view of the situation. A frozen video feed or inaccurate location can make an apparently calm support call misleading. Staff should be trained to state uncertainty, escalate appropriately and avoid commanding movement based on an unverified scene. A support script should not promise that the vehicle will continue when engineering has placed it on hold.

Plan for ordinary disruption as carefully as dramatic emergencies

Many failures will not be collisions. A shuttle may stop behind roadworks, lose a data link, fail to open a door, miss a pickup, run out of service because of a defect or become unable to complete a trip. Each event requires a passenger communication, a vehicle decision, a recovery path and an evidence record. The DfT guidance asks for contingency planning to maintain service continuity and passenger safety when an automated service fails or cannot operate.

At a minimum, decide how the operator identifies affected passengers, informs them of the problem, assesses any immediate risk, offers a suitable alternative and confirms they reached a safe endpoint. A replacement vehicle may not be accessible for the same users. A passenger may need an in-person helper to leave the stopped vehicle or cross a road safely. The service should not classify the event as resolved merely because the vehicle was recovered to a depot.

Test a missed connection between support channels. If the booking app knows that a journey was cancelled but the onboard help centre does not, passengers may receive inconsistent instructions. If a support worker arranges a taxi but the operator lacks a method to confirm its arrival, the passenger could be left waiting. The handoff should record who is responsible until the passenger has a safe onward plan. A commercial refund process is separate from immediate safety and accessibility.

Create a service stop rule. A single fault may affect all vehicles on a software build or all journeys through a flooded road. Passenger staff should know when to stop taking new bookings, how to reach dispatch and how to tell people already travelling. The technical team should identify affected vehicles; the permit holder should decide the service response. A dashboard that shows vehicles as available after the operator has suspended the route is an operational defect worth testing before launch.

Prepare for illness, safeguarding and disruptive behaviour

A passenger may report illness, threats or abuse while travelling. The operator needs a way to speak with them, identify location, decide whether to stop the vehicle, contact emergency services and arrange safe support. The DfT guidance asks for a passenger safeguarding policy and a risk assessment specific to the automated service. It gives examples such as onboard monitoring, passenger interaction with remote support, safeguards for children and training for relevant staff. These are possible evidence areas, not a universal command to install every form of surveillance.

Safeguarding needs a clear escalation route. A call-centre worker should know who can act when a child is at risk, how to preserve relevant evidence and how to avoid promising confidentiality that cannot be maintained. Staff who interact directly or remotely with passengers need role-appropriate vetting and training under the applicable law and guidance. This page does not decide an individual's DBS eligibility by job title. That decision requires the real duties, workforce and current DBS rules to be assessed separately.

Privacy matters where a provider uses CCTV, audio or passenger location. Record why the data are needed, who can view them, how long they are kept and how incidents can be investigated lawfully. A camera may help staff understand an event but may fail at night or in a crowded vehicle. Design a way to act when the monitoring system is unavailable. A passenger's dignity and ability to request help should not depend on being continuously observed.

Disruptive behaviour can also involve someone outside the vehicle blocking it or attempting to enter. Passenger staff should not improvise vehicle movement to escape a situation. They should follow the tested response plan, coordinate with the ADS operator and call emergency services when needed. The plan should consider how a passenger receives instructions if the external disruption also affects connectivity.

Give responders vehicle-specific information

The DfT's first-responder guidance is a primary source for how a pilot organisation can help responders recognise, access and secure a self-driving vehicle. The operator should prepare a current vehicle information pack and contacts for the area of deployment. Emergency services need to know how to stop the vehicle moving, access passengers, isolate relevant hazards and arrange recovery. A generic brochure about automated driving will not answer those questions at the scene.

The pilot applicant guidance asks the incident plan to cover detection, emergency contacts, first-responder access, securing a vehicle, movement of a damaged vehicle, trapped-passenger extraction information, post-incident safety and cooperation with investigations. Build those items into an operational sequence. A support worker should know which vehicle has stopped and be able to connect a responder with a technical expert. The technical expert should be reachable under the actual hours of operation.

Engage with local responders before deployment. A conversation can reveal whether the vehicle's emergency release, battery isolation or tow point is understandable to responders who have never seen that model. The official guidance encourages this engagement as part of incident planning. An introductory meeting is not proof that every shift knows the vehicle. Use controlled information, exercises and updates when hardware changes. The pilot should not assume responders will identify the vehicle by appearance alone.

A responder may need to direct traffic or order a vehicle to move. The organisation should have a tested communication and authority path for lawful instructions. The support centre should not send a remote motion command simply because a caller says they are at the scene. Verify identity and situation through the agreed emergency channel and use the vehicle's safe procedures. A cyber attacker could exploit an informal emergency override.

Make accessibility work during the incident

An emergency procedure must work for passengers with mobility, sensory or communication needs. If a vehicle stops in traffic, a passenger using a wheelchair may not be able to leave without trained help. A person who cannot hear the speaker may miss evacuation instructions. A support worker should be able to switch communication channel or arrange in-person assistance. The accessibility plan and incident plan should share scenarios and evidence rather than contradict each other.

The DfT pilot guidance asks how people with mobility difficulties can enter or leave the vehicle in an emergency or other disruption. Test that question at realistic stops, including awkward kerbs, darkness, wet weather and blocked doors. The safety action may sometimes be to remain in the vehicle until responders arrive. A generic instruction to exit immediately can be dangerous. Specialists should decide the correct response for each vehicle and hazard, and staff need simple instructions they can use under pressure.

A passenger's assistance dog or essential equipment should be accounted for during recovery. The operator should not promise a replacement journey without checking whether the replacement can accommodate the passenger. It should track the passenger's safe onward arrangement, not just the vehicle's status. Feedback after the event can reveal which parts of the plan failed in practice.

This guide focuses on help and emergency support. The separate accessibility guide owns the whole booking-to-destination design and ongoing access evidence. The two should link after integration, but neither should substitute for an actual exercise with the intended users and responders.

Decide what to record and report

The incident record should connect vehicle time and location, passenger communications, automated-system alerts, staff decisions, emergency contact, help provided, data preserved, reporting decision and service restart. The DfT guidance asks APS applicants to record and investigate incidents involving passengers or the public and to identify a responsible person for verifying reports. The actual permit and Vehicle Special Order may specify additional categories and notification times. Keep a condition-specific reporting matrix rather than repeating one general deadline.

Separate the first safety response from the full investigation. Staff should call emergency services and protect passengers before waiting for a complete root-cause analysis. A prompt initial notification may sometimes have incomplete facts. Record what was known, what remains uncertain and when an update is due under the actual instrument. Preserve logs, relevant video and support messages lawfully, with access controls and a retention decision. A service provider should not publish personal incident detail merely to show transparency.

After the event, ask why the plan worked or failed. Did passengers reach support? Was the correct vehicle located? Did the recovery team arrive with the right equipment? Could responders secure the vehicle? Was the alternative journey accessible? Did dispatch continue offering an unsafe route? Assign fixes with owners, test them and update training. A lesson learned that has no implementation record is not an effective control.

Restart is a decision, not the automatic end of a support ticket. An engineering lead may clear the vehicle, a passenger lead may clear the service response, a legal lead may confirm whether an authority restriction applies, and an insurer may need notice. If a defect affects a fleet, one repaired vehicle does not justify restarting every unit. Record who authorised the return to service and the configuration and route that were cleared.

An exercise for a stopped passenger shuttle

Imagine a shuttle with six passengers stops near a junction because its automated system cannot interpret temporary road markings. One passenger presses help. Another needs step-free access to leave. The vehicle's mobile connection is intermittent, and a responder calls the number printed on its exterior. The exercise should test whether the operator can identify the vehicle and its state, speak to passengers, prevent an unsafe restart, direct the responder to the correct access information, arrange accessible recovery and preserve the event data.

Add a second problem: the support centre receives two other calls at the same time. The staffing plan should show how it prioritises the stopped vehicle, whether another worker can take over and how an escalation is recorded. If passenger support and ADS support are separate suppliers, test the handoff between them. A written contract saying they cooperate is weaker than evidence that a realistic incident was handled in the expected time and order.

The exercise should end only after the passengers have a safe plan, the vehicle is secured, required reports are considered, the cause is investigated and a restart decision is made. Record difficulties honestly. If the vehicle's printed contact is outdated or the responder cannot access a technical document, correct the problem and repeat the test. The point of an exercise is to find gaps before a real emergency.

A practical support register

This is an editorial planning tool. It is not an official permit form or a substitute for the vehicle's emergency manual. The exact action depends on the event, location, passenger and issued conditions. Use it to find missing owners and tests, then validate the real procedure with specialists.

Where Complys may fit

A permit holder may need controlled support procedures, responder information, training evidence, incident actions and review dates. Complys could be assessed for those administrative records in a demonstration. This page does not claim that it provides an emergency call centre, dispatches recovery vehicles, monitors passengers, sends statutory notifications or decides whether a vehicle is safe to restart. Any specific product promise needs current product-owner verification.

In a demonstration, use the stopped-shuttle exercise. Ask how the team would link the incident plan, contact list, vehicle pack, action owners and updated training record, then retrieve the earlier version after a later investigation. If live calls, dispatch and telemetry are handled in other systems, state that boundary. The AV software overview gives a wider procurement script. The AV checker can orient readers to possible regimes, but cannot assess an emergency plan.

The next step is to allocate every passenger-help action to an actual team and run a realistic exercise with responders and people with different access needs. A no-driver service needs a human support system that works when normal travel fails. The applicant should keep the issued permit and government guidance as the source of legal requirements, then demonstrate the response for its actual vehicles and routes.