Product Q&A: How We Built TRM to Show a Traveller's Entire Journey

A Q&A with Ronnie Galea, Product Director at Restrata

An earthquake hits Tokyo. You need to know which of your people may be affected - whether they are currently visiting, arriving back home after a trip, or are due to arrive. 

But flight bookings, hotel details and recent check-ins can tell different stories. How do you work out who needs support? 

This is where a travel risk management system must earn its place: helping teams piece together incomplete information and decide where to act. 

We asked Ronnie Galea, Restrata’s Product Director, why we’ve built TRM to connect the whole journey - giving teams a clearer picture of who may be at risk, so they can respond. 

Ronnie, why did Restrata build TRM this way? 

Ronnie: We wanted to make it easier for teams to understand who needs support and act on that information. 

That means connecting travellers to their journey, not just an isolated itinerary or single GPS location. It also means considering who the person is. For example, are they a traveller in a completely foreign environment? Are they returning home from a trip only to find they are caught up in an incident? These questions are important to someone with a duty of care over their people because it affects the level of support they need to provide. 

We have brought separate bookings, and other traveller location data together into one trip. So a flight booked through the travel company and a separately booked hotel become part of the same journey, without the manager having to join the records manually. 

Say an assistant booked the trip. How do you connect it to the traveller? 

Ronnie: That’s a very practical problem. An assistant might book a flight using their own email address. You still need that journey connected to the person travelling. 

Our matching process uses several fields to help link bookings to the correct person’s record. We’ve taken that extra step because the information is only useful if it tells you the right person’s story. 

It’s the kind of detail that can disappear in a big product demonstration. But for travel and security managers, connecting people to their trips matters. 

Does every new traveller mean more admin for the team? 

Ronnie: We want to remove as much of the manual administration as we can. 

We have automated traveller engagement. Picture this, an incoming booking triggers a new profile to be created.  The system can then send a branded welcome email with links to download the app. Follow-up can be automated too. Your team has fewer profiles to create, invitations to send and reminders to chase. 

When a booking doesn’t contain everything needed, you can choose additional details travellers must provide when self-registering, such as next-of-kin information. You also control who can self-register through options such as email-domain restrictions or an organisation code. That makes it easier to get started while collecting the information your team needs to support them. 

What’s in it for the traveller? 

Ronnie: Asking someone to download an app is only effective when there is some benefit for the traveller. 

In the Restrata app, travellers can view their trips, see alerts and access additional content set by their organisation through custom links. When configured, travellers can also call for assistance.  

Additional travel details can be added and travellers can also ‘check-in’, sharing their current location at any time. 

Preparation matters too. Pre-trip advisories give travellers relevant, trip-based information before they leave, preparing them before something goes wrong.  

If the booking says Tokyo, how much confidence can you put in that? 

Ronnie: A booking tells you where someone planned to be. A check-in tells you where they were at a particular time. Neither guarantees where they are now. 

resilienceOS brings together available information - including itineraries, GPS, check-ins and verified site-access records - and weighs its source and age to assess where someone is most likely to be. We call that Location Confidence. 

For the travel manager, that means less information to piece together and a clearer basis for deciding who may need support - and where to ask for an update.  

So an earthquake hits Tokyo. Who might you miss? 

Ronnie: When an incident happens, your duty of care is for everyone likely to be affected. This is different to supporting only those who you 100% know are affected. This is where  resilienceOS really comes into its own; we help you understand who is likely affected and take action. 

For example, when the earthquake hits you need to know who is likely there now. You also need to know who has travelled to the affected area recently, are they potentially still there? What about travellers due to arrive? They may need support or for travel plans to be aborted. 

That’s why we show you the  journey alongside location information. A high-confidence location can help you prioritise, but someone with less certain information may still need support. If records disagree, we highlight this for you, helping to flag and resolve uncertainty without the need for complex analysis. 

With everyone identified, you can now tailor your response by cohort. If you have a group of travellers in a foreign environment, you can tailor communications specifically for them. If another group live in the location and are returning home, you can send a different communiction to them.   

resilienceOS helps your team to make a better decisions and offer tailored support to your people.  

What about the people in Tokyo who aren’t travelling? 

Ronnie: Duty of care doesn’t stop with your travellers. You may also have employees based within the impact zone, or contractors working at a local site. These groups need to be part of your picture too. 

Where site-access data or check-in information is available, resilienceOS brings that context alongside travel information.  

By weighing all available information, we help teams understand who may need support, so they can quickly take action. . That matters for privacy too: the aim is to gather enough context to support someone, rather than track every movement. 

When talking about locating and supporting travellers, is privacy a consideration? 

Ronnie: No matter the event or the group of people you are responsible for, Personally Identifiable information, or PII, must be managed with privacy at the forefront. 

Our aim is to always ensure the maximum amount of context for travel and security managers when dealing with risk exposure and events that impact their travellers. Access to data though, needs to be handled sensitively. 

Within resilienceOS, clients have the ability to control access to PII through user roles and Data Access Permissions. For example, members of a regional team can be restricted to see PII  

Does everyone who may be affected need the same follow-up? 

Ronnie: Not necessarily. A first-time visitor may need more guidance than someone who knows the area well. The response depends on their circumstances, the incident and an organisation’s policies. 

Within our travel dashboard, managers can filter views for the people they’re responsible for, including domestic/international trips, travellers returning home, or even travellers in higher risk locations. This additional perspective helps travel and security managers understand who’s potentially at risk and follow-up as needed. 

From the dashboard, you can export information to brief others. From a privacy perspective, teams can also be restricted to only view traveller’s ‘Personally Identifiable Information’ (PII) that they are authorised to see. 

Can organisations keep their existing assistance provider when they use Restrata? 

Ronnie: Yes. We’ve designed resilienceOS as an open ecosystem. The technology and the assistance relationship don’t have to be the same purchasing decision. 

Organisations can keep their assistance provider where supported, or work with a partner from our ecosystem. We also connect booking and intelligence sources so teams can bring relevant information into the operational picture. 

That matters particularly when travel is one part of a more complex operation. A person may move from a flight to a site and then onto a managed journey. Within resilienceOS, travel sits alongside people, sites, journeys, intelligence and communications. The connections available depend on the organisation’s configuration, but the purpose is continuity: understanding the person’s situation and coordinating support in the same environment. 

What has building travel risk technology taught you? 

Ronnie: I spent the best part of a decade working within Travel Risk and critical event management. My experience has reinforced just how much the practical details matter: presenting a full traveller’s story through matching bookings to the right person, combining location data into a cohesive picture, highlighting issues and conflicts when they arise.  

I also know that you need to focus on the traveller’s experience just as much as the security and travel managers experience. Making onboarding easier and giving traveller’s a meaningful experience via the app are essential. 

The design question I keep coming back to is whether features and solutions help keep travellers safe and healthy. At the end of the day, that’s what matter to us here at Restrata and to the clients we serve. 

See how Restrata could support your travel programme 

Explore a travel risk management system that connects the person, their journey and the support your team provides. 

Request a demo of Restrata’s Travel Risk Management solution.