Choosing passenger transport software: the criteria follow from your obligations

Passenger transport software is the dispatch system of the operating company. It plans recurring and one-off journeys, assigns them to vehicles and drivers, supports execution in the vehicle and turns the result into records for billing and for the client. What separates it from neighbouring product categories is not the feature count but the question of whose problem the system solves.

Four building blocks belong together, and the dividing line runs wherever one of them is missing:

• Dispatch and tour planning. Journeys are bundled into tours under constraints from vehicle, staff and passenger. With recurring journeys across a school year or a dialysis cycle, repetition is the normal case, not the exception.
• Execution in the vehicle. A driver app shows the tour, captures status updates and carries the pre-departure check. Without it the record is created in the office at night, from memory.
• Communication with passengers, relatives and clients. Sick notes, delays, cancellations. These messages are not a convenience; they decide whether ten calls hit the office in the morning or none.
• Records and billing. Service records per payer and client emerge from the execution data. If that step requires a second round of data entry, the break is already built in.

Three product categories get confused regularly because all of them deal with journeys. They solve different problems, and buying the wrong one becomes apparent in the third month.

The distinction is not academic, it sits in the statute. For private hire vehicles, section 49(4) of the Passenger Transport Act requires bookings to arrive at the business address or the operator home, the vehicle to return without delay unless a new booking has come in, and the arrival of the booking to be recorded in writing or electronically, with the record kept for one year. An app-based system is expressly permitted for this.

That yields a very concrete selection criterion. Software that merely schedules journeys but does not log when and how the booking arrived does not meet this duty. In an inspection the question is not whether the tour was driven but whether the moment of acceptance is documented. Taxi services under section 47 are not subject to this particular logging duty, which is why pure taxi systems often do not provide for it at all.

Records are where software in a passenger transport operation pays for itself, or does not. For patient journeys, payment depends on the prescription and the approval under section 60 of the Social Code Book V; for disability support services it depends on the funding decision. What the payer checks is not the journey but the record of the journey.

The tax side comes on top. Under section 147(3) of the German Fiscal Code, accounting vouchers must be kept for eight years, ledgers and annual accounts for ten, other records for six. Section 257 of the Commercial Code adds that the documents must remain available throughout the period and be made legible within a reasonable time.

For the selection that means: a system whose records can only be pulled up on screen shifts a statutory duty into a contractual relationship that may end sooner than the retention period. How quickly a missing record turns into a deduction is set out in our article on rejected service records.

• The record emerges from execution, not from a second round of data entry in the office.
• Every journey carries timestamps, vehicle, driver and status history, and later edits stay traceable.
• Records export as complete files per payer and billing period, not just as a screen view.
• The export is machine-readable and can be evaluated without the vendor system.
• Cancellation, empty run and no-show are distinct, justifiable states rather than a missing entry.

Passenger transport generates data well beyond name and address. Wheelchair type, the need for an escort, the dialysis cycle, a note about seizures in the vehicle. These are health data within the meaning of Article 9 GDPR, whose processing is prohibited in principle and becomes lawful only through one of the exceptions listed there.

The practical consequence is not a form but a question of architecture. Put those attributes in the same field the driver reads the tour from and you have made them visible to everyone who sees tours. We set out the graduation of access roles and deletion periods in a separate article on Article 9 GDPR in passenger transport.

Two more points apply to the vendor. A software provider processing passenger data is a processor, and Article 28 GDPR requires a contract with prescribed content, including what happens to the data at the end. Article 32 GDPR requires technical and organisational measures appropriate to the risk, and with health data the risk is elevated by definition.

Tour planning that knows only addresses and times produces plans that cannot be driven. The attributes that forbid an assignment are legally anchored and not a matter of preference.

• Wheelchair spaces. Since 2016, section 35a of the Road Traffic Licensing Regulation has set requirements for wheelchair and occupant restraint systems and permits DIN 75078-2 for that purpose. A wheelchair space is therefore its own capacity type, not a repurposed seat. What that means for fleet choice and evidence is in our article on wheelchair restraint under DIN 75078.
• Escorts. An approved escort occupies a seat and is at the same time a billable attribute with a validity period. Systems that carry it as a note lose both.
• Driving and rest periods. Whether the German Drivers Hours Regulation applies depends on vehicle type and use. Where it applies, shift length is a planning boundary rather than a violation discovered afterwards.
• Driver qualifications. Passenger transport driving permit, instruction in the restraint system, criminal record certificate depending on the client. An expiry date nobody monitors becomes visible on exactly the wrong morning.

The underlying criterion is easy to test and separates systems sharply: can the software prevent an inadmissible assignment, or can it only document one? A free-text field documents. A constraint prevents.

The question asked least often in vendor meetings is the one about the end. Yet it decides how expensive a switch will be in five years, and it can be settled cheaply beforehand.

One widespread misconception belongs here. The right to data portability under Article 20 GDPR belongs to the data subject, that is the passenger, not to your company. Your claim to your own operational data follows from the contract and from Article 28(3)(g) GDPR, under which the processor deletes or returns the data once processing ends. What "return" means concretely, in which format and at what price, is not stated there. That is yours to agree.

1. 1Test the data migration before the contractHave a real extract from your old system imported, not a sample file supplied by the vendor. Passenger master data with attributes and recurring journeys is the test, not the address list.
2. 2Put the export format in writingWhich objects, which format, which deadline after termination, at what cost. An export that exists only as a pile of PDFs serves section 257 of the Commercial Code poorly in practice.
3. 3Regulate retention beyond the contractEight years of retention outlast most software contracts. Settle whether you archive the records yourself or the vendor holds them, and what applies in the event of insolvency.
4. 4Measure the rollout on one contractRollout duration is driven by the quality of the legacy data, not by the feature count. A single contract as a pilot shows that within two weeks.

The following questions fit into a single meeting. They are phrased so that an evasive answer stands out.

• Show me the service record for a single day, exported as a file, not as a screen view.
• How does the system log the arrival of a booking, and how long does that record remain available?
• Which roles exist, and what exactly does a driver see about a passenger who needs an escort?
• Can you assign a journey requiring a wheelchair space to a vehicle without one? Please try.
• Is the processing agreement available, and where is the data hosted, sub-processors included?
• What happens to our data the day after termination, in which format and at what price?
• Which part of our legacy data can you migrate, and what do you typically fail to migrate?

The fourth question is the most revealing. If the system allows the assignment and merely shows a warning, you now know the answer to most of the others as well.