Multi-City Business Trip Planning: How to Book, Approve, and Track Complex Itineraries

An East Coast sales tour: four cities in five days. New York Monday, Boston Tuesday, Washington Wednesday, Atlanta Thursday, home Friday. A single delay out of LaGuardia on Monday morning cascades into the entire week. The Tuesday Boston customer dinner moves to a breakfast. The Tuesday-night Boston hotel becomes a Wednesday-morning Boston hotel. The Wednesday Washington appointment shifts by two hours. The Wednesday-night DC hotel needs a late check-in flag. The Thursday Atlanta flight needs a 30-minute earlier departure. Five reservation changes. Three approval signatures. Two project codes. One traveler who just wants to be home by Friday dinner.

This is what a multi-city business trip actually looks like in practice, and most travel programs are still booking it the way they book a single-leg round trip. The result is high-cost, high-friction itineraries where changes pile up faster than the booking platform can absorb them, approvals split across three managers who never see the whole picture, and the expense report that lands four weeks later does not reconcile cleanly against the budget any of them approved.

This guide is for travel managers building the program-level workflow that makes multi-city trips bookable, approvable, and trackable without manual stitching. We cover what counts as a multi-city trip, the seven hidden cost drivers that make these itineraries different, a step-by-step booking process, how to structure approvals when a single trip touches multiple projects or cost centers, how to track changes mid-trip without losing the audit trail, and how to design the back-end so the expense report writes itself when the traveler lands.

What counts as a multi-city business trip?

A multi-city business trip is any single trip where the traveler visits two or more business destinations before returning to their origin city. Three common patterns:

• Linear tour: Origin → City A → City B → City C → Origin (the classic sales tour)
• Hub-and-spoke: Origin → Hub City, day trips out to nearby cities, back to hub each night, then home
• Loop: Origin → City A → City B → Origin, where City A and City B are along the same route

A round trip with a single business stop and a personal layover is not a multi-city business trip in the policy sense. A trip with one business destination and a planned weekend somewhere else is also not multi-city in this sense. The distinguishing feature is two or more business destinations, each requiring its own meeting, lodging, ground transport, and (often) policy treatment.

Why multi-city trips are different (and harder)

Seven structural reasons multi-city trips cost more and break more often than single-destination trips:

1. Weaker negotiated airline rates on one-way segments:

‍Corporate airline contracts are priced for round trips. Multi-city itineraries use multiple one-way segments, and one-way pricing is often 15 to 30% above the comparable round-trip rate per mile. A four-city tour can cost the same as two separate round trips for this reason alone.

2. Hotel-rate variance across cities:

A single trip may cross a low-rate market (Atlanta, $180 average) and a high-rate market (San Francisco, $360 average) in the same week. A policy with a single hotel cap fails immediately. A policy with neighborhood-level caps requires the booking tool to apply different caps per leg.

3. Approval splits across projects, cost centers, or business units:

A sales tour visiting four customers may have four different project codes. A roadshow visiting investors across cities may have one parent campaign and four sub-campaigns. The single trip needs to be split across multiple GL accounts at booking, not after the trip.

4. Cascading change risk:

‍A delay on leg one shifts leg two. A cancellation on leg two changes leg three. A single disruption can require three to five separate rebookings, each of which may need approval, may break policy, and may push the traveler into out-of-policy fares.

5. Per diem and policy variation by city:

‍Per diem rates differ by city. Hotel caps differ. Ground-transport allowances differ. A traveler crossing four cities is technically subject to four different policy treatments and may inadvertently violate one without realizing it.

6. Visa and entry requirements for international multi-city:

‍A trip crossing two or more international destinations may need separate visas, may have transit restrictions, and may trigger different VAT-recovery filings per country.

7. Time-zone and circadian load:

‍A four-city tour across three time zones in five days produces a different traveler-fatigue profile than a single-destination trip, and traveler fatigue degrades sales effectiveness on the back half of the trip. The travel manager owns this trade-off whether they realize it or not.

The hidden cost of multi-city friction

The headline cost of a multi-city trip is the visible booking total. The hidden cost is what surrounds it:

A program running 30 multi-city trips per month is absorbing roughly 60 to 90 hours of additional travel-manager time before any traveler-side time is counted. The platform-level fix is to make the booking, approval, and reconciliation workflow understand "trip" as a unit, not "leg" as a unit.

How to book a multi-city business trip: the 7-step process

Given below is the 7 step process for multi-city business trip booking: 

Step 1: Map the full itinerary before opening any booking tool

The biggest mistake travel managers make is booking leg one and figuring out leg two from there. Multi-city trips need the full itinerary mapped on a single page first. The map should include each city, dates, the business purpose of each stop, the budget owner for each stop, and any constraints (visa requirements, time zone limits, traveler preferences, customer availability windows). Ten minutes spent on the map saves an hour on rebookings later.

Step 2: Validate the business case per leg, not in aggregate

A four-city tour may have one leg that does not earn its trip cost. The budget conversation should happen leg by leg, not trip total. A "Boston customer dinner that justifies a $1,400 booking detour" is the kind of decision that should be visible to the budget owner before the trip is booked, not discovered in the expense report later.

Step 3: Choose the routing strategy intentionally

Three patterns, each with different cost profiles:

• Linear  (A to B to C to D to home): Lowest fatigue, highest one-way fare cost
• Hub-and-spoke (base in one city, day trips out): Lower flight cost (fewer one-ways), higher ground transport, less city-level immersion
• Loop (A to B back to A via shared route): Lowest cost, only works when geography cooperates

Picking the wrong routing strategy can cost 15 to 25% on the trip total. Travel managers should be running this analysis at booking time, not just accepting the traveler's preferred routing.

Step 4: Lock in flights with the right fare class flexibility

For multi-city itineraries with any disruption risk (which is most of them), flexible fare classes on at least the high-risk legs pay for themselves. A change-fee-free fare on the Monday morning departure flight is often worth $80 to $200 more than the basic economy alternative when the chance of a Monday cascade is 30%-plus.

Step 5: Book hotels with same-day-change flexibility on at least two legs

Direct-to-hotel rates often allow same-day changes; many discount-rate bookings do not. For the legs most likely to shift (typically the middle legs of a multi-city tour), pay the small premium for the flexibility. The cost is far less than the cost of being stuck with two non-refundable nights.

Step 6: Set up the multi-level approval workflow before submitting

This is where ITILITE's multi-level approval routing comes into play. When a multi-city trip splits across three project codes and two cost centers, the booking should route to each relevant manager with visibility into only the legs they own, plus a summary view for the program-level approver. Single-package approvals (one manager sees the whole trip and approves or denies) work for some companies. Per-leg approvals (each project owner approves their slice) work for others. The platform should support both models and let the travel manager choose per trip.

Step 7: Tag each leg with project code at booking time

This is the step most programs skip and pay for later. Each leg of the trip should carry its project code, cost center, and budget owner from the moment of booking, not be retroactively allocated by the AP team during expense processing. ITILITE applies project-code tagging at the leg level so that the eventual expense draft auto-populates with the correct allocation without manual intervention.

Approval routing for multi-city trips

The approval workflow for a multi-city trip should answer four questions before the booking is submitted:

1. Who approves what:

‍For a four-leg trip touching three projects, the right model usually has each project owner approve their leg(s) and a program-level approver approve the whole trip. The platform needs to support parallel approvals (project owners review at the same time) so the approval chain does not become serial and take a week.

2. What happens when one approver delays: 

‍A program running multi-city trips needs an escalation rule: if any approver does not respond within 24 hours, the request escalates to a backup approver. Without this, a vacation or sick day from one approver can hold up an entire trip and force out-of-policy bookings to recover.

3. How changes get re-approved mid-trip:

When a leg changes mid-trip (delay, customer reschedule, weather), the system should auto-route a change approval to the affected leg's owner, not just the program-level approver. ITILITE handles this by linking each leg to its original approver and triggering a delta-approval workflow when a change exceeds a configured threshold.

4. Who sees the audit trail:

‍Multi-city trips create more audit-trail surface than single trips. Every approval, every change, every override should be logged in a single trip record that finance and travel ops can pull up in one place. Fragmented audit trails are how policy compliance becomes policy theater.

For more on how corporate cards interact with multi-city expense allocation, see our coverage of business travel and expense cards.

Project-code allocation across legs

Most multi-city business trips split costs across more than one project, cost center, or business unit. Three allocation methods work in practice:

• ‍Proportional allocation (by leg cost): Each project pays the actual cost of its leg(s). Cleanest from a finance perspective, harder to configure if leg costs are not known until post-trip.‍
• Time-based allocation: Total trip cost is split by the number of business days spent on each project. Useful when the trip costs are interwoven (one rental car covers multiple cities, one hotel chain status crosses legs).‍
• Business-case-weighted allocation: The trip owner allocates costs by business case (the closing meeting in city C drives 50% of trip value, allocate accordingly). Most flexible, hardest to audit.

The right choice depends on the program. The key requirement is that the allocation method be chosen at booking time and locked into the trip record so that the expense draft generates correctly when the trip ends. ITILITE allows the program to configure allocation method at the policy level and overrides per trip when needed.

Tracking changes mid-trip without losing the audit trail

A multi-city trip with no mid-trip changes is rare. The question is not whether a change will happen but whether the platform handles it without breaking the audit trail. Three capabilities the platform needs:

• Real-time itinerary status: The travel manager and the affected approvers should see every change as it happens, not after the traveler emails them. A change to leg two should show up in the trip record the moment it is booked, with a clear before-after diff.
• Auto-routing of change approvals: When a change exceeds the configured threshold (typically a percentage of the original leg cost or an absolute dollar amount), the platform should route an approval to the leg owner automatically. The traveler should not have to email anyone.
• Single trip-record view: The audit trail should live in one place per trip, not be split across the booking system, the expense system, and a Slack thread. When finance asks "why did this trip cost $4,200 instead of the approved $3,400 six weeks later," there should be a single record that shows what changed, when, who approved it, and why.

For more on how AI handles mid-trip disruption support, see our deep dive on AI transforming customer support in business travel.

Auto-linked expense drafts: the back-end that saves the front-end

The most undervalued capability in multi-city trip management is auto-linked expense drafts. When the trip is booked with project codes per leg, the platform can pre-generate a draft expense report with each leg as a line item, each line pre-coded to the correct project, each line pre-attached to the booking receipt. The traveler lands and the expense report is already 80% complete.

For multi-city trips, this saves the traveler 60 to 120 minutes of reconciliation per trip and saves the AP team another 30 to 60 minutes. ITILITE auto-generates these drafts at the moment of booking and refreshes them as legs change, so by the time the traveler returns, the only thing left to do is add incidental expenses (meals, ground transport not booked through the platform) and submit.