Skip to main content
Travel Operations_TravelodeskBooking & dispatch platform

Unifying multi-city travel bookings, dispatch, and driver operations_

A travel operations platform that keeps multi-city itineraries, price locks, driver assignment, cancellations, and admin decisions in one consistent booking record.

  • Travel SaaS
  • Dispatch Management
  • Multi-city Booking
  • Driver Assignment
  • Workflow Design
Challenge_

A multi-city booking changes after the first quote: legs are added, prices are locked, drivers become unavailable, and cancellation rules differ by service. Separate booking and dispatch records caused teams to work from different versions of the trip.

Approach_

Parallaxis modeled the itinerary as a sequence of service legs connected to one commercial booking, then built administrative workflows for pricing, assignments, exceptions, and customer-visible status.

Outcome_

The platform gives booking and operations teams a common source of truth for complex itineraries and creates a clean foundation for automated dispatch, notifications, reconciliation, and partner integrations.

Overview

Travelodesk manages trips that are more complicated than a single pickup and drop. One customer journey can include airport transfers, local travel, inter-city legs, waiting time, different vehicle categories, and more than one driver.

Parallaxis designed the product around the operational life of that journey. The customer-facing booking experience and the administrative dispatch workflow share the same itinerary, pricing decisions, assignment state, and cancellation history.

The fragmented itinerary problem

When each travel leg is managed as an isolated booking, a small change creates a chain of manual corrections. Operations may assign a driver against an outdated pickup time, finance may use the original quote, and the customer may receive a confirmation that no longer matches the plan.

The platform needed to preserve the commercial agreement while still allowing authorised staff to make operational changes as vehicles, drivers, and schedules evolved.

A booking made of service legs

We modeled a trip as a parent booking with ordered service legs. Each leg carries its own route, timing, vehicle requirement, assignment, and operational status, while shared customer, quotation, payment, and policy information stays at booking level.

This gives the team a full itinerary view without losing the ability to dispatch and update one segment independently. It also creates a clearer audit trail when a trip is changed after confirmation.

Price locks and controlled changes

Quoted travel prices can expire or change with availability. Price-lock state records when a commercial value became binding and separates permitted operational edits from changes that require a new customer approval.

Cancellation is handled as a workflow rather than a delete button. The system can retain the affected leg, reason, applicable rule, refund state, and who approved the action.

Driver assignment as an operational decision

The administrative interface brings timing, route, vehicle requirements, and current assignment together. Dispatchers can assign or replace a driver while preserving earlier decisions, reducing the risk of silent changes that are difficult to investigate later.

A foundation for automation

Once booking, leg, and assignment states are consistent, notifications and integrations become reliable. The same state changes can drive customer updates, driver instructions, reminders, partner API calls, and reconciliation reports without separate teams maintaining their own spreadsheets.

Project highlights

  • Multi-city and multi-leg itinerary model
  • Unified customer and operations booking record
  • Price-lock state and approval boundaries
  • Driver assignment and reassignment workflow
  • Vehicle and route requirements by service leg
  • Cancellation reasons and refund-state tracking
  • Admin views for booking exceptions
  • Audit-friendly history of operational changes
  • Foundation for notification and partner integrations

Facing a similar bottleneck?

Tell us where ops is stuck - we will confirm fit without a pitch deck.