Service

Transfer booking software development

For owners of airport transfer, chauffeur and minibus companies who want booking, pricing, allocation and account billing designed around their own routes, vehicle classes, drivers and agent relationships rather than a taxi app that treats every journey as a metered ride.

The problem

What goes wrong today

Where it usually starts

A transfer company with eight vehicles runs on a shared calendar, a price list in a spreadsheet and a controller's phone.

  • A hotel concierge emails a request for two passengers from the airport to the hotel on Friday; the controller looks up the route price, replies, and writes the job in the calendar with the flight number in the notes.
  • On Friday the flight lands forty minutes late, the driver has been in the car park since the scheduled time, the parking fee is now a problem, and the next job for that driver starts in twenty minutes on the other side of the city.
  • Nobody told the passenger where to find the driver, so the passenger walks past the meet-and-greet sign to the taxi rank.

Where it gets harder

Return journeys are booked as two unrelated entries that drift apart when one is amended.

  • A corporate account books by email and expects one invoice a month with cost centres; it receives a scatter of card receipts.
  • An agent who sends twenty bookings a month is owed commission that is calculated by hand from the calendar.
  • Vehicle classes get confused: a saloon is sent for a family with four suitcases and a pushchair.
  • Peak days are overbooked because the calendar does not know how many eight-seaters the firm owns, and a driver who worked until two in the morning is given a six o'clock pick-up.

Scope of the service

What the build covers

A custom transfer booking build normally covers the journey from quote to settlement:

  • Pricing from fixed-route tables between airports Stations, ports and postcode zones with a distance-based fallback for everything else, by vehicle class you define such as saloon, executive, people carrier and minibus, with surcharges for night hours, child seats, waiting time and extra stops
  • A booking flow that captures flight or train numbers Terminal, number of passengers and luggage, meet-and-greet in the arrivals hall or a kerbside pick-up, and a return journey held as a linked leg
  • Dispatch with driver and vehicle availability per class Rest rules you set, and conflicts shown before they happen
  • A driver page on a phone with job details Passenger name board, status taps and a place to record waiting time and parking
  • Passenger notifications With the driver name and vehicle at the right moment
  • Corporate accounts with cost centres and monthly invoicing
  • Partner agents who book under their own login and earn commission By your rules

How discovery works

Discovery works through a peak Friday with you: how pick-up times are set from a landing time, what happens when a flight is delayed, how meet-and-greet is handled at each airport you serve, how drivers are paid and rested, which agents send bookings and on what terms, and what a corporate account wants on its invoice. Each answer becomes a named stage in the scope document: quoted, booked, allocated, on the way, waiting, on board, completed, invoiced or commissioned.

Deliberately out of scope

  • Metered on-demand taxi work, vehicle maintenance records and driver payroll, which stay in their own tools and are connected where it pays

When the scope grows

Scoping scenario

An operator serving three airports with thirty vehicles across four classes, two hundred hotel and agent partners and a dozen corporate accounts wants flight-delay monitoring to shift pick-up times automatically, a dispatcher view that prevents a driver being allocated inside their rest window, agent commission statements per month, and a corporate portal where travel bookers see their own cost centres. That is a materially different build from a four-car firm wanting an online quote form and a diary, and the scope document says which is being built.

Deliverables

What you receive

  • Discovery notes from a walk-through of a peak day, from the first airport landing to the last late-night drop
  • A written scope document naming each journey stage, vehicle class and pricing rule, with what is out of scope
  • Design of the quote and booking flow, the dispatch view and the driver page, checked on a controller screen and a driver phone
  • The build, deployed to your hosting or ours
  • Migration of route price tables, corporate accounts, agents and future bookings from the current calendar and spreadsheets, where relevant
  • Training for controllers, drivers and the accounts person, with a one-page guide for flight delays and amendments
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, your route price tables, vehicle list, agent terms and a look at how bookings and flight checks are handled today.

    Project stage: Onboarding
  2. Planning

    Discovery with the owner, the lead controller and a senior driver; the scope document and milestone plan are agreed.

    Project stage: Planning
  3. Design

    Clickable designs of the quote and booking flow, the dispatch view and the driver page, checked on a controller screen and a driver phone at arrivals.

    Project stage: Design
  4. Development

    Built in stages: vehicle classes and route pricing first, then booking with flight details and returns, then dispatch, the driver page, accounts and agents.

    Project stage: Development
  5. Client review

    Controllers run a test weekend with real bookings keyed in parallel and tell us where prices, allocation or passenger messages do not match the day.

    Project stage: Client review
  6. Revisions

    Route tables, surcharges, rest rules, message timing and invoice layout are adjusted from the review and re-checked against the scope.

    Project stage: Revisions
  7. Ready for launch

    Future bookings and accounts migrated, card payments and messages tested, any flight data connection checked, driver phones set up, launch checklist signed off.

    Project stage: Ready for launch
  8. Delivered

    The firm quotes, books and dispatches on the new system; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Flight and rail status data providers for delay monitoring and pick-up time adjustment
  • Card payment providers for online bookings, deposits and balances
  • Accounting software for corporate invoices and agent commission statements
  • SMS, email and messaging providers for driver details and pick-up instructions
  • Mapping and distance services for fallback pricing and driver navigation
  • Hotel and travel agent booking channels that pass transfers through an API

How we would approach it

Worked example

Concept demo

A three-airport operator with agents and corporate accounts

The situation

A transfer operator serving three airports with thirty vehicles wanted to stop its controllers watching flight boards and recalculating commission by hand.

Why it is a custom build

This needs a custom build rather than a taxi dispatch product because the pick-up time is a derived value tied to a flight, the vehicle classes and rest rules are hard constraints on allocation, and two separate commercial relationships, agents and corporates, run through the same booking record.

The scope we would propose

  • A route table per airport and vehicle class with a distance fallback
  • A booking record that holds the flight number and derives the pick-up time from landing plus a meet-and-greet allowance, shifting automatically when a flight data connection reports a delay and alerting the controller when the shift collides with the driver's next job
  • A dispatch view that shows vehicle availability per class and blocks allocation inside a driver's rest window
  • Agent logins where hotel concierges book at their negotiated rate and see a monthly commission statement
  • A corporate portal where a travel booker sees only their own cost centres and downloads one invoice a month

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of airports, stations and ports served and the size of the fixed-route tables
  • Vehicle classes, surcharges and whether a distance fallback is needed
  • Flight and rail delay monitoring through a data connection
  • Meet-and-greet handling and passenger messaging per airport
  • Driver rest rules, vehicle availability and allocation conflicts
  • Corporate accounts with cost centres and monthly invoicing
  • Partner agents, their rates and commission statements
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

Would the package do, or do we need a custom build?

A single-airport or regional operator with a few vehicle classes, fixed-route pricing, meet-and-greet, returns and a driver page is usually covered by the transfer booking package through configuration. Multi-airport fleets with automated flight-delay shifting, driver rest rules, agent commission and corporate portals are where the custom route becomes the honest recommendation. Discovery is where we say which.

How does the system deal with a delayed flight?

The booking stores the flight number and derives the pick-up time from landing plus your meet-and-greet allowance. With a flight data connection in scope, a reported delay shifts the pick-up and alerts the controller if the new time collides with the driver's next job; without one, the controller updates the landing time by hand and the same shift happens.

Can we price by fixed routes and by distance?

Yes. Fixed-route tables between your airports, stations and postcode zones take priority, with a per-mile fallback for anything not in the table. Both are owned by you, per vehicle class, with your own surcharges.

How are agents and hotels handled?

Each agent gets a login, a rate card and a commission rule. Their bookings flow onto the same dispatch view as everyone else, and a monthly statement shows the commission owed or the net amount due. Hotels that send bookings by email can be given the same login.

Who owns the system afterwards?

You do. The source code, bookings, route tables, accounts and agent records are handed over at delivery and can be exported at any time. Hosting and maintenance are optional and separately agreed.

Get a project quote for transfer bookings software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote