The RFP is broken for travel technology.

What the RFP is actually measuring

An RFP measures three things well: whether a vendor can write, whether a vendor can price a statement of work down to the last change-request clause, and whether a vendor can withstand a procurement process that sometimes runs longer than the implementation itself. None of those three skills correlate with the ability to design a revenue system, land an integration inside a twenty-year-old Sabre or Amadeus host, or make a general manager trust a demand forecast enough to override her own gut on a Friday night rate. The RFP is a filter for patience and prose. It is not a filter for outcomes.

Consider what a hundred-and-forty-question document can actually verify. It can verify that a vendor has a SOC 2 report, a disaster recovery plan, and reference clients who will say polite things on a scheduled call. It cannot verify that the vendor's engineers can sit with your revenue team and disagree productively about a hurdle rate, or that the platform's rate shopper handles a Skyscanner or Google Flights price change without a six-hour lag. Those details decide whether the system earns its budget line in year two, and no RFP response has ever contained them.

The deeper issue is who inside the RFP process is actually answering the questions. On the vendor side, it is rarely the engineers who will build the integration. It is a solutions consultant or a proposal specialist whose entire job is producing persuasive procurement documents. On the buyer side, it is rarely the general manager or the head of revenue who will live with the system. It is a procurement function whose incentive is defensibility, not fit. Two groups of professional document-writers, neither of whom will touch the software after signature, decide which engineering team gets the contract.

Travel technology suffers from this more than most verticals because the systems in question sit directly on the P&L. A mis-selected CRM is an inconvenience. A mis-selected revenue management system, chosen because its RFP response used the phrase machine learning eleven times, is millions of pounds of mispriced inventory before anyone admits the mistake out loud.

The false comfort of comparability

The appeal of the RFP is that it produces a scorecard. Three columns, twenty-seven rows, a weighted total that looks, to a board, like due diligence. It looks like a decision. It is actually a spreadsheet, and spreadsheets reward the vendors who are best at filling in spreadsheets. The firms that score highest on an RFP are, overwhelmingly, the ones with the largest proposal teams, not the ones who have shipped the most software into a live property management system on a Friday afternoon without breaking the night audit run.

There is a specific mechanism behind this. RFP scoring rubrics ask binary or near-binary questions: does the platform support X, yes or no. A platform with twelve modules, half of them acquired through roll-up acquisitions and barely integrated with each other, answers yes to more questions than a platform with four modules built to work together from the same data model. Oracle Opera, Cloudbeds, and Mews all answer yes to broadly the same feature list on a PMS RFP. The differences that matter, how each handles a mid-stay rate change, how each surfaces a folio dispute, how each behaves when a channel manager and a booking engine disagree about availability at the same second, never appear as a checkbox.

Comparability also creates a false sense that the hardest part of the decision has been done rigorously, which makes the softer, harder-to-quantify parts of the decision get rushed. Once the scorecard produces a winner, nobody wants to reopen the question by saying the winning team seemed slow to answer follow-up emails, or that the demo environment was clearly staged. The spreadsheet has spoken. Overriding it looks like bias rather than judgement, so committees defer to the number even when their own instincts, formed over twenty years in the industry, say something different.

The result is systematic adverse selection. Vendors who are good at selling win RFPs. Vendors who are good at building lose them to vendors who are good at selling, and eventually stop bidding on RFPs altogether, because the win rate does not justify the cost of the response. The travel industry has slowly RFP'd itself into a vendor pool skewed toward companies with excellent proposal departments, which is a strange criterion to have accidentally optimised procurement for.

What to run instead

Run a working session, then a paid pilot of two to three weeks on a real, bounded slice of the problem, not a sandbox demo built to impress. In the working session, the shortlisted teams sit with your revenue managers, your engineers, and, critically, your actual data, not an anonymised sample designed to be flattering. You want friction in that room. You want a vendor's engineer to say, out loud, that your current rate calendar structure will not map cleanly onto their pricing model, because that sentence tells you more about the engagement than any RFP response ever will.

In the pilot itself, the vendor ships something small into a staging environment that mirrors production, connected to a live or near-live feed from your PMS, channel manager, or GDS connection. Not a slide about integration capability. An actual integration, even a narrow one: a single property, a single rate code, a single distribution channel. You are not buying the full platform in week two. You are buying evidence of how the team behaves when the API documentation is wrong, which it always is somewhere, and how quickly they fix it once you point it out.

This is a small operational shift with a large evidentiary payoff. A two-week paid pilot, priced fairly and paid for regardless of outcome, costs a buyer somewhere in the range of eight to twenty thousand pounds per vendor evaluated, depending on scope. Run against two shortlisted vendors, that is a fraction of the cost of a failed eighteen-month RFP-driven implementation, and an even smaller fraction of the opportunity cost of a mispriced inventory book while the wrong platform limps toward go-live. Our approach to vendor evaluation for clients is built around exactly this substitution: replace the paper exercise with a working one, and let the working one produce the paper trail procurement actually needs.

The objection procurement teams raise immediately is fairness: if vendor A gets a working session and vendor B does not, is that not a biased process? It is the opposite. A scored RFP response is heavily influenced by which vendor has the best-resourced proposal team, which has nothing to do with fairness of outcome for the buyer. A pilot structured identically for every shortlisted vendor, same data slice, same time window, same success criteria agreed in advance, is a considerably fairer test of who can actually do the job.

The counter-argument, and why it does not hold

The counter-argument, raised in nearly every procurement conversation we have had on this subject, is compliance. Procurement will insist the RFP protects the organisation from accusations of favouritism, from audit risk, from a rejected vendor's legal challenge. It does not protect any of those things as well as its defenders believe. It protects the process, which is not the same as protecting the outcome, and regulators and auditors have never actually required an RFP specifically; they require a defensible, documented, non-discriminatory process, which a well-run pilot satisfies just as completely.

A structured pilot, run with agreed success criteria published to every vendor in advance, produces a stronger audit trail than an RFP does. It produces a working artefact: code that ran, in a specific environment, against specific data, on a specific date. It produces named references, people inside your own organisation who watched the vendor's team work under real conditions, not references hand-picked by the vendor's marketing department. That is a more defensible record of due diligence than a scored questionnaire, because it is evidence rather than assertion.

There is a second, quieter version of the objection: public sector or heavily regulated buyers, some national carriers and government-linked tourism boards among them, are legally required to run a formal tender. Where that is true, the right move is not to skip the tender but to build a paid proof-of-concept stage into it as a scored component, weighted heavily, ahead of contract award. Several European rail and tourism authorities already do this for digital procurement.

The third objection is scale: RFPs feel necessary when comparing more than two or three vendors, because you cannot pilot with fifteen firms. The answer is a lightweight written stage, much shorter than a traditional RFP, purely to cut the field from a dozen to two or three, and reserve the pilot for the final round where the decision actually gets made.

What survives after the ink dries

Eighteen months after a botched RFP-driven selection, almost nothing from the RFP itself survives contact with reality. The scored functionality matrix is filed away. The vendor's promised roadmap items have shifted twice. The named account team that impressed the committee has, in a third of the cases we have seen across the industry, moved to different accounts or left the company entirely. What remains is the software, running or not running, and the relationship between your engineers and theirs, functional or dysfunctional.

The RFP tests whether a vendor can write a good RFP response. The pilot tests whether the vendor can ship code that works in your environment.

A paid pilot leaves behind something durable precisely because it was never a paper exercise. It leaves a small amount of production or near-production code that either gets built upon or gets ripped out, a working relationship between two engineering teams that have already had at least one disagreement and resolved it, and a documented, first-hand answer to the only question that actually mattered: what does this vendor do when something breaks at an inconvenient hour. That answer does not appear in any RFP response ever written.

There is also a talent effect worth naming. Engineers on both sides remember pilots. A vendor's best engineers want to be put on a pilot, because a pilot is where their craft is visible, and they actively avoid RFP response work, because it is proposal writing dressed up as engineering. If you want the vendor's best people assigned to your evaluation rather than their weakest, structuring the process as a pilot is the single most effective change a buyer can make.

None of this means documentation disappears. A well-run pilot still produces a short written summary, agreed success criteria, and a recommendation, written after the fact to describe what happened rather than before the fact to predict what might happen. That distinction, between a document that reports and a document that speculates, is the entire argument against the RFP in one sentence.

The four questions to ask before you write another RFP

Most procurement teams do not need to abandon structure. They need a different structure, ordered around evidence rather than assertion. Before drafting the next hundred-page document for a booking engine, a revenue platform, or an AI initiative, run the decision through four questions in sequence.

1. Can the vendor show us code running against our data, not a demo environment, within two weeks of first contact. If the honest answer is no, ask why not; a team that cannot stand up a narrow, real integration inside a fortnight is telling you something about how it will behave during the actual implementation, when the stakes and the surface area are far larger. 2. Who, specifically, will be in the room during the pilot, by name, and will those same people remain on the account after signature. Vendors routinely field their strongest engineers for a proof of concept and then staff the delivery with a different, more junior team. Naming the people in advance and holding the vendor to it removes this entire category of surprise. 3. What is the single hardest integration point in our environment, and will the vendor attempt it during the pilot rather than the easiest one. A vendor who volunteers to tackle the GDS handshake, the mid-office reconciliation, or the rate parity edge case, rather than steering the pilot toward a clean, easy demonstration, is showing you confidence that is worth more than any reference call. 4. What happens to the pilot's output if we do not proceed. If the vendor's answer involves proprietary lock-in, code that cannot run outside their platform, or data that cannot be exported cleanly, that is a term to negotiate before the pilot starts, not after you have decided you like the team.

These four questions replace roughly ninety per cent of a traditional RFP's length. They take longer to answer honestly than to answer politely, which is precisely the point. A vendor's response to question three, in particular, tends to be the single most predictive signal in the entire evaluation, more predictive than reference calls, case studies, or years in business combined.

What this looks like in practice

A mid-sized regional airline, forty aircraft, point-to-point network, was preparing to replace its ancillary revenue platform, the system that prices and merchandises seat selection, baggage, and lounge access at booking. The incumbent RFP draft, inherited from a previous initiative that had stalled, ran to ninety pages and had already consumed six weeks of the commercial team's time before anyone outside procurement had seen a line of code from any vendor.

We proposed cutting the draft to a four-page brief: the three ancillary categories generating the weakest attach rate, the specific booking flow steps where drop-off was highest according to the airline's own funnel data, and the name of the commercial director who would answer to the CEO if the project missed its first-year revenue target. That brief went to five vendors. Two responded with clarifying questions about the funnel data before submitting anything. Those two went into a three-week paid pilot, each given the same anonymised slice of booking flow data and the same staging environment, connected to a mock version of the airline's existing reservation system.

One vendor's team spent the first four days asking the airline's own analysts why baggage attach dropped sharply on the mobile app specifically, a detail the ninety-page draft RFP had never surfaced because no question in it had been shaped to surface it. That vendor's pilot build, shipped in week two, addressed the mobile flow specifically and lifted the simulated attach rate by nine per cent in testing. The other vendor built a technically competent, generic merchandising widget that matched what their marketing site already showed. The airline signed with the first vendor inside three weeks of the pilot ending, at a fraction of the elapsed time the original RFP timeline had budgeted, and the production system was live in under four months.

The commercial director's own account of the decision, given afterwards to the wider leadership team, was blunt: the RFP draft would have scored the generic widget vendor higher, because their proposal document was better written and their case study slide had a bigger logo on it. The pilot showed, in code and in a conversation with the airline's own analysts, which team actually understood the problem. That is the entire argument for replacing the RFP, told in one procurement cycle rather than in the abstract.