Traveler location check during an incident

How do we identify the travelers affected by an incident at a destination, ask them to confirm their status, and escalate the ones who do not respond?

Run the incident as a check-in with a clock and an escalation path. When an incident hits a destination (a natural disaster, an attack, civil unrest, a transport shutdown, a health event), Callvu classifies the incident's area and period from the alert and the duty of care policy, identifies the travelers in or due in the area from the bookings, the itineraries and the tracking consents, sends each a check-in on every channel on file asking them to confirm they are safe and where they are, with a path to ask for help, reads the responses, chases the non-responders on the escalation schedule through their emergency contacts and the local contacts, puts the unresolved cases to the duty-of-care team in the Decision Desk with the last known position and the options, and keeps the incident record until every traveler is accounted for.

In scopeComplex: multi-party handoffsCallvu moves: classify, chase and verify, decide

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

Four hours after the earthquake the company still did not know which of its people were in the city.

Today, without Callvu

When an incident happens, the first question is who is there, and the answer lives across the booking tool, the agency's reports, the expense system and people's memories. The second question is whether they are safe, and the answer is a round of calls and messages by whoever is awake. The ones who do not answer are the ones who matter, and nobody owns the escalation.

The duty of care policy and the travel risk standard expect the organization to be able to account for its travelers during an incident. The data exists: the bookings give the location and the dates, the profile gives the channels and the contacts, the consents allow the check-in and the location request. The check-in is a message with a reply; the escalation is a schedule; the decision is the team's.

Accounting for travelers in an incident is a process that should already exist when the alert arrives.

How it runs

From the requestto the system of record.

An incident alert arrives (from the risk provider, the news, an employee report or the authorities) for a destination. Callvu opens the incident and classifies its scope.

Travelers in the area: Confirm their status and location on any channel, or ask for help.
Emergency and local contacts: Are asked about a traveler who does not respond.
Duty-of-care team: Decides unresolved cases and the assistance in the Decision Desk.
Assistance provider: Delivers help where the team requests it.
Callvu: Classifies the incident, identifies the travelers, sends the check-ins, reads responses, chases, escalates and records.

Classify the incident and identify the travelers
The alert's area (a city, a region, a country), its period and its severity are classified under the duty of care policy, which sets the check-in urgency and the escalation schedule; the travelers in the area or due to arrive in the period are identified from the bookings (flights, hotels, cars), the itineraries, the expense card activity where the policy allows, and the location consents, and the list is shown to the duty-of-care team with each traveler's last known position and channels.
Chase and verify status
Each traveler receives a check-in on every channel on file (text, messaging app, email, a call where the severity requires) asking them to confirm they are safe, where they are and whether they need help, with a one-tap reply and a path to request assistance; the responses are read and recorded with time and location; a traveler who confirms is marked safe and asked to check in again on the schedule while the incident lasts.
Escalate and decide
A traveler who does not respond within the schedule's window is chased again, then through the local contact (the hotel, the office, the client) and the emergency contact, each asked through their link; a traveler still unaccounted for, a traveler who asks for help, or a traveler in a severe area goes to the duty-of-care team in the Decision Desk with the last known position, the contacts' answers and the options, and only the allowed outcomes (continue the search, task the assistance provider, arrange evacuation or relocation, or close as accounted for).
Record
The incident record (the travelers, each check-in and response with time, the escalations, the decisions and the assistance) is kept in the booking system, the system of record, until every traveler is accounted for and the incident is closed, and the record is available for the after-action review and the duty of care evidence.

Where it ends: Within minutes of the alert the organization knew who was in the area, within the schedule it knew who was safe, the non-responders were escalated through their contacts, and the team decided the unresolved cases with the data in view. The Decision Trace shows the incident classification, the traveler identification and the decisions; the Audit Trace shows every check-in, response and escalation with time.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

Duty of care policy: The policy sets the incident severity levels, the check-in urgency and channels per level, the escalation schedule (how long before a non-responder is escalated to contacts and to the team), the roles on the duty-of-care team and their authority to task the assistance provider or order an evacuation, and the records to keep; the process runs the policy's schedule.
Travel risk management standard (ISO 31030) and the employer's duty of care: The standard expects the organization to be able to locate and communicate with travelers during an incident, to have incident response procedures, and to keep records; the employer's legal duty of care to employees abroad is evidenced by the check-in and escalation record.
GDPR and data protection for location and incident data: Locating a traveler and contacting third parties during an incident is processed on the vital interests basis and the consent recorded in advance; the data is limited to the incident's purpose and retained for the review period.

Company policies

The travelers in the area are identified from the bookings and the itineraries within minutes of the alert.
Every traveler is asked on every channel, with a one-tap reply and a path to help.
Non-responders are escalated on the schedule through their contacts, and the team decides unresolved cases.
The booking system holds the incident record until every traveler is accounted for.

Controls

Incident classification by area, period and severity.
Traveler identification from bookings, itineraries and consents.
Multichannel check-ins with one-tap replies.
Escalation schedule through contacts.
Decision Desk for unresolved cases and assistance.
Incident record and closure.

Clocks and deadlines

Identification: Minutes from the alert.
Check-in window: The policy's window per severity before a non-responder is escalated.
Re-check: On the schedule while the incident lasts, for confirmed travelers.

Documents and checks

The incident classification and the traveler list
Each check-in and response with time
The escalations and the contacts' answers
The decisions and the assistance
The incident record

In the Decision Trace

The incident classification.
The identification basis per traveler.
Each decision and the person.

In the Audit Trace

Each check-in and response with time and channel.
Each escalation with time.
The closure.

The handoff

Between the front doorand the back office.

The front door

The check-in on the traveler's own channels; contacts through their links.

The back office

The duty-of-care team works a live list with responses and escalations; the assistance provider is tasked from the decision.

The Decision Desk

A traveler unaccounted for after the escalation, a request for help or a traveler in a severe area goes to the duty-of-care team in the Decision Desk with the last known position and the contacts' answers, and only continue the search, task the provider, evacuate or relocate, or close as accounted for.

Proof

In scope.Proof at scale, not one process at a time.

The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.

More than 1,000 processes are live across Callvu customers.

Across Callvu customers

Questions

What buyers ask next,answered plainly.

How are the affected travelers found?

From the bookings, the itineraries, the expense activity where the policy allows and the location consents, for the incident's area and period, within minutes of the alert.

What does the check-in ask?

Whether the traveler is safe, where they are and whether they need help, with a one-tap reply on every channel on file and a path to request assistance.

What happens when someone does not respond?

They are chased again, then their local and emergency contacts are asked, and an unresolved case goes to the duty-of-care team to decide the search, the assistance or an evacuation.

Related processes

Emergency contact and duty-of-care details High-risk destination approval Flight disruption handling Travel insurance claim intake Try it in the sandbox All travel and ecommerce processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.