Short answer: a corporate travel policy works when every rule in it can be expressed as a condition a booking system can check at the moment of booking: allowed cabin by flight duration, an advance purchase window, a price cap against the lowest logical fare, a named list of preferred suppliers, and a small approval matrix for everything else. Rules that only a human can interpret end up unenforced.
Why most travel policies fail
Travel policies usually fail in one of two ways. Either they are so vague ("book responsibly", "use good judgement") that finance cannot point to a broken rule when spend drifts, or they are so detailed that travellers stop reading and book outside the programme entirely. Booking outside the managed channel is the expensive failure: the company loses negotiated rates, loses the data it needs for reporting, and loses sight of where its people are, which undermines duty of care as well as cost control.
Industry bodies such as the Global Business Travel Association (GBTA) have long pushed managed programmes towards the same conclusion: compliance improves when the policy lives inside the booking flow rather than in a PDF. A rule that appears as a warning or a block at the moment of choice gets followed; a rule discovered during expense review two weeks later just produces arguments.
The structure of an enforceable policy
Write the policy in two layers. The first layer is a short human document: purpose, scope (who it covers, which trip types), responsibilities, and the principles behind the rules. The second layer is a rule table: each rule stated as a condition, a threshold and an outcome. The outcome vocabulary should be small and match what booking systems can do:
- Allow: in policy, book without friction.
- Warn: visible nudge ("a cheaper fare exists"), booking still permitted, flagged in reporting.
- Approve: booking is held or ticketed on condition, and routed to a named approver.
- Block: not bookable in the tool at all. Use sparingly; blocks are the main driver of off-channel booking.
If a rule cannot be written in that form, it belongs in the principles section, not the rule table, and you should not expect a system to enforce it.
Air rules: cabin, fares and advance purchase
Air is where the money and the arguments are, so make the rules mechanical:
- Cabin by duration. The common pattern is economy by default, with premium economy or business permitted above a stated flight duration or for overnight flights. Pick thresholds in hours, because a system can measure hours; "long flights" is not a rule.
- Fare basis rules. State whether basic economy or non-refundable fares are the default, and when flexible fares are justified (for example, trips likely to change). A booking tool can filter or rank fare families only if the policy names them.
- Lowest logical fare. Rather than "cheapest flight", define a comparison window: the traveller may book any fare within a set amount or percentage of the cheapest option that departs within a set number of hours of the requested time, with the maximum number of stops you accept. All four values are numbers a system can check.
- Advance purchase. Set a booking lead time for domestic and international trips and route late bookings to approval rather than blocking them, since genuine late trips exist. Track the share of bookings inside the window as a programme metric.
Preferred suppliers and payment rules
Preferred supplier rules only work when the booking tool knows who the preferred suppliers are. List them by code, not by prose: airline codes, hotel chain and property identifiers, car and rail vendors. Then decide the display behaviour, since the biggest lever is what travellers see first. Most programmes rank preferred options at the top of results rather than hiding alternatives.
Payment rules belong in the same table: which trips go on central billing or lodge cards, which on corporate cards, when personal cards are acceptable, and how ancillaries such as seats and bags are paid. If your agency runs its own stack, the payment rules should map onto how your travel agency software reconciles bookings against invoices, otherwise finance ends up matching lines by hand.
Approval matrices that do not clog inboxes
An approval matrix answers three questions: which bookings need approval, who approves, and what happens when the approver is silent. Keep it small. A workable default:
| Trigger | Approver | If no response |
|---|---|---|
| In policy, below spend threshold | None - auto-approved | Not applicable |
| Out of policy on one rule (for example late booking) | Line manager | Escalate or auto-approve after a stated number of hours, decided per company |
| Out of policy on price cap or cabin | Line manager plus travel manager or finance | Booking expires with the fare |
| High-risk destination | Travel manager or security owner | Blocked until reviewed |
| VIP or executive travel | Named executive assistant workflow | Per company |
Two design rules save the most pain. First, approve the exception, not every trip: pre-trip approval for everything doubles workload and delays ticketing while fares change. Second, always define the timeout behaviour, because airline fares are not held indefinitely and a silent approver otherwise becomes the most expensive person in the company.
Exceptions: design for them, do not deny them
Every programme has exceptions: medical and accessibility needs, visa runs, conference blocks at non-preferred hotels, travel disruption. A policy that pretends otherwise trains people to bypass it. Give exceptions a route: a reason code chosen at booking time, an approver, and a record. Reason codes matter more than they look, because they turn exceptions into data. If a quarter of exceptions cite the same city pair, that is a negotiation target, not a discipline problem.
Keep the exception list short and reviewed. When a reason code accounts for a large share of bookings, it is no longer an exception; either the rule is wrong or the code is being used as a loophole.
From document to booking tool configuration
The test of the whole exercise is whether the rule table can be loaded into a booking system. This is how the mapping looks in practice:
Whether you rent an off-the-shelf tool or commission a corporate booking tool of your own, walk through the rule table with the implementer line by line. Any rule the system cannot represent should be rewritten or moved to the principles layer, and rules the system can enforce that your policy never mentions (for example, refundable-fare preferences per route) are worth adding. Agencies and TMCs that build their own stack usually wire the same rules into their B2B portal so that offline bookings made by agents follow the same policy as self-service ones, and reporting flows into one place. For a wider view of the software landscape this sits in, see our guide to how OTAs, TMCs and host agencies differ.
Template checklist
Use this as the skeleton of the document. If you can tick every line, the policy is enforceable:
- Scope: who is covered, which trip types, which geographies
- Booking channel: the tool and agency to use, and what happens to off-channel bookings
- Cabin rules by flight duration in hours, including overnight and medical exceptions
- Fare rules: default fare families, when flexible fares are allowed
- Lowest logical fare definition: price window, time window, maximum stops
- Advance purchase windows for domestic and international, with the late-booking route
- Hotel caps per city or city tier, and the preferred property list
- Ground transport rules: car class, rail class, rideshare policy
- Payment rules: central billing, corporate cards, personal card reimbursement
- Approval matrix with named roles and timeout behaviour
- Exception reason codes and where they are reviewed
- Duty of care hooks: data capture, high-risk destination routing
- Review cycle: who owns the policy and how often thresholds are revisited
This article is general information about travel technology and online marketing. It is not legal, tax or financial advice, and advertising platform policies change often. Check the current policy documents and take professional advice for your own situation.