Do you know where all your passenger data goes?
A passenger may plan a journey on a map, buy a ticket in your ticketing app, tap in, read a stop display and make a complaint. An Authority needs to know what each interaction records, who holds it and what may properly be joined up.
People search for
In this article
Passenger information is often created before anyone calls it “customer data”. A journey planner may log a search. An app account may hold contact details and ticket history. Equipment produces operational asset records. A complaint can include a route, time and location.
Authorities need to decide what data is needed to run and improve the service. Each record should be named and assigned to its contractual home, rather than leaving “customer data” as a vague contractual aspiration. Such wording suggests that the Authority has not determined the data it needs or why. The target operating model should address this in detail.
Where a record can identify someone directly or indirectly, it is personal data, even when the Authority is interested in a travel pattern or service trend rather than the individual passenger.
Start with the passenger task
Start by listing the passenger tasks that matter: planning a trip, buying and using a ticket, receiving disruption information, recovering lost property, making a complaint and requesting a refund. For each task, identify the record created, the system that holds it and who can access it. This quickly exposes gaps. A stop-display Supplier may retain fault logs, an app Vendor may receive feedback and an Operator may hold the evidence needed to answer a complaint, while the Authority receives only a monthly summary.
Separate the records needed to answer a passenger or fulfil a transaction from the operational or contractual evidence used to manage the network, and from analysis such as whether route complaints coincide with poor reliability. The purposes may require different data, levels of detail and retention periods.
Put records in the schedule that governs the service
For a contracted network, data provisions should follow each service function. Ticketing and account records belong with ticketing service requirements. Complaint, enquiry and lost-property records need a customer-service process that works across Operators. Fleet, on-bus technology and passenger-information data belong with the relevant technical or service schedules. A general data annex does not replace these operational provisions.
| Service area | Contract detail worth pinning down |
|---|---|
| Ticketing and payment | Required transaction and account data, reconciliation access, retention, fraud controls and arrangements at service exit |
| Customer contact | Case ownership, response times, evidence supplied by the Operator, access for the Authority and treatment of sensitive information |
| Passenger information and equipment | Fault and availability records, incident escalation, data formats and handover of configuration or historic records |
| Network analysis | The specific datasets that may be combined, the purpose, access controls and the approved output or report |
This is part of Contract Management. If payment depends on a measure, the Authority needs the underlying record and must be able to query it. For a complaint, contracts should specify who answers, who can see the case history and when it is deleted. They should identify the data-protection roles and require Suppliers to assist the Authority where appropriate.
Joining records needs a stated purpose
Authorities can learn from records across channels. An Authority may want to know whether complaints follow a disruption, whether a fare offer reaches its intended market or whether passengers abandon a journey-planning search after a cancellation. Any combined view should begin with a defined question and the minimum data needed to answer it.
Pseudonymised records can support analysis while limiting routine access to direct identifiers. They are not automatically anonymous: where additional information can reconnect a reference to a person, the records remain personal data. Dataset matching can increase identifiability.
Consider the DPIA before a Supplier builds the integration or procurement fixes the scope. Data flows are easier to change before a product is live.
Tools do not remove the Authority’s decisions
Within LiteFranchise™, the contract suite includes schedules for ticketing (with a proposed Managed Ticketing Supplier), customer service, data protection and service exit. ITA’s OneContact, 16Dashboard and IDInsight have published roles in customer contact, contract performance and transport intelligence. This helps an Authority avoid a generic “customer data platform” requirement. The Authority must still decide what information is shared, for what purpose and on what evidence.
An officer should be able to trace an important record from its source to the service or contract decision it supports. If that trace is not possible, revisit the specification before commissioning another dashboard.
Useful questions
Use these questions when reviewing an existing contract or writing a specification:
- Can we name every system that receives passenger information during planning, payment, travel and customer contact, including Supplier-hosted systems?
- Which schedule tells each Operator or Supplier what data it must provide, how quickly and in what usable form?
- What Authority systems or Managed Services, such as lost property, will your Operators be expected to use? Identify them and incorporate them into the contract.
- What specific passenger or network decision justifies combining ticketing, app and customer-contact records?
- Have we assessed whether the proposed matching or monitoring requires a DPIA and who owns it?
- At contract exit, can the Authority obtain the records, configurations and evidence needed to continue the service or respond to passengers?
More on Data & Governance