The Event Ticketing RFP: Requirements Checklist and Vendor Scorecard
An event ticketing RFP should cover five things: commercial and settlement terms, peak on-sale capacity, entry and access-control performance, fraud and resale governance, and data ownership at contract exit. Feature lists are the least useful part of the document. The strongest RFPs describe the moments where ticketing operations actually break, then ask each vendor to prove how their platform behaves in those moments.
Part of How to Choose an Event Ticketing Platform: The Complete Buyer’s Checklist
This is the procurement companion to our buyer's checklist for choosing an event ticketing platform. That guide covers how to decide what you need. This one covers how to write the document that gets you honest answers.
Why do most ticketing RFPs fail?
Because they are written by people who last bought ticketing five to seven years ago, using a requirements list copied from the previous cycle. The result is a document that scores vendors on features every credible platform already has, while ignoring the operational conditions that decide whether a contract succeeds.
Three failure patterns recur:
- Feature parity theatre. Two hundred yes/no questions, of which one hundred and eighty return "yes" from every bidder. The scoring separates nobody.
- Silence on peak load. The RFP asks about uptime but never defines the on-sale it must survive, so vendors answer against their comfortable average rather than your worst minute.
- No exit clause. Data ownership, export formats and migration support are left to the contract stage, where the buyer has already lost all negotiating leverage.
A ticketing platform is not a piece of software you evaluate in a demo. It is an operational partner that will handle your money, your audience data and the fifteen minutes a year when your entire commercial reputation is on the line.
The five moments that break ticketing operations
Write the RFP around these five moments. Each one is a place where the difference between platforms becomes visible, expensive and non-negotiable.
1. The peak on-sale
Ten to sixty minutes where demand can exceed normal traffic by three orders of magnitude. Ask for the vendor's largest verified concurrent-user figure, the architecture that produced it, the queue model, and what happened the last time an on-sale went wrong. Ask for the post-mortem, not the press release.
2. Settlement day
The most under-specified area in ticketing procurement. Define payout frequency, currency handling, chargeback allocation, refund float, reconciliation format and who carries payment-processing liability. Vague settlement language costs more over a contract term than a rate difference of half a percent.
3. The entry rush
Sixty to eighty percent of an audience can arrive inside a thirty-minute window. Ask about offline scan capability when connectivity fails, scan throughput per device per minute, duplicate-detection behaviour, and whether access control is native or a third-party integration the vendor does not control.
4. The refund or postponement event
Cancellations, rescheduling and partial refunds are operationally brutal and reputationally public. Ask how a mass refund is executed, how long it takes, who communicates with buyers, and what it costs.
5. Contract exit
Ask what leaves with you: customer records, transaction history, seat maps, scan logs, marketing consents. Ask for the export format and the timeframe, in writing, before you sign anything.
What should the requirements section contain?
Nine categories, roughly sixty line items. Keep each requirement written as an observable behaviour rather than a feature name, so that "yes" means something.
| Category | What to require | Why it separates vendors |
|---|---|---|
| Commercial and settlement | Fee structure by ticket type, payout frequency, currency and FX handling, chargeback allocation, refund float, reconciliation file format, liability split | Where total cost of ownership actually lives, well below the headline rate |
| Peak load and on-sale | Verified peak concurrency, queue model and fairness logic, inventory-locking behaviour, cart timeout policy, payment throughput ceiling, degradation plan | Separates platforms built for marquee on-sales from those built for steady inventory |
| Access control and entry | Scan throughput per device, offline mode, duplicate detection, hardware options, turnstile integrations, staffing model | Most demos never test this, and most incidents happen here |
| Fraud and resale governance | Bot mitigation layers, purchase limits by identity, named-ticket capability, authorised resale controls, audit trail | Determines whether your on-sale reaches fans or brokers |
| Data ownership and exit | Data controller status, export scope and format, migration support, retention, deletion, consent portability | The clause that decides your leverage in five years |
| Integrations and API | Documented public API, rate limits, webhooks, CRM and marketing connectors, sponsor and partner feeds, sandbox availability | Reveals whether the platform is a system or an island |
| Reporting and analytics | Real-time sales views, cohort and channel attribution, custom exports, user permissions, historical retention | Decides whether your commercial team can act during the on-sale, not after it |
| Marketing and distribution | Owned-channel tooling, marketplace reach, distribution partners, cross-border sales, language and currency support | Distribution is revenue, not a feature |
| Support and operations | Named account team, event-day escalation path, response times by severity, on-site support scope, incident history | The difference between a vendor and a partner |
Two drafting rules make the difference. Require evidence, not assertion: "describe the largest on-sale you have operated, with date, concurrency and outcome" beats "do you support high-demand on-sales". And require a named owner for every operational commitment, so the answer cannot hide behind the company.
How should you score the responses?
Use weighted scoring with a small number of categories and a published weighting. Publishing the weights in the RFP itself improves the quality of responses, because serious bidders invest their effort where it counts.
| Scoring dimension | Suggested weight | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|
| Peak-load evidence | 20 percent | No verified figures | Figures without context | Named event, date, concurrency, post-mortem |
| Commercial and settlement clarity | 20 percent | Rate only | Rate plus terms | Full model with liability and reconciliation detail |
| Entry and access-control depth | 15 percent | Third-party dependency | Native, untested at scale | Native, with throughput data from comparable events |
| Fraud and resale governance | 15 percent | Policy statement | Basic limits | Layered controls with audit evidence |
| Data ownership and exit | 10 percent | Silent or restrictive | Export on request | Defined scope, format and timeframe in the response |
| Integration and API maturity | 10 percent | Closed | Documented | Documented, sandboxed, with reference integrations |
| Support model | 10 percent | Ticket queue | Named contact | Named team with event-day escalation and incident history |
Score each dimension one to five, multiply by weight, and sum to a hundred-point total. Then apply one discipline that most panels skip: any vendor scoring one on peak-load evidence or data ownership is eliminated regardless of total. Those two are structural, and a strong average elsewhere does not compensate.
What are the red flags in vendor answers?
- Concurrency quoted without a named event. A number with no event, date or outcome attached is a marketing figure.
- "Unlimited" anything. Unlimited scale, unlimited support, unlimited customisation. Every platform has ceilings; the honest vendors tell you where theirs are.
- Access control described only as an integration. Fine if disclosed, dangerous if discovered during an entry rush.
- Data export "available on request". That is a negotiation, not a commitment.
- No incident history. Every platform operating at scale has had a bad day. A vendor claiming otherwise is either new or not answering the question.
- Discounting before scope is agreed. Price movement that early usually reappears as a service gap later.
How long should the process take?
Between twelve and eighteen weeks for an enterprise ticketing procurement, and it should end at least one full season before your first on-sale on the new platform.
- Weeks 1 to 3: internal requirements gathering across commercial, operations, marketing, finance and technology. Agree weights before you see any vendor.
- Weeks 4 to 5: market scan and shortlist, typically five to eight vendors invited.
- Weeks 6 to 9: RFP issued and responses returned. Allow three weeks minimum; a two-week window filters for availability rather than quality.
- Weeks 10 to 12: scored evaluation and structured demos against your scenarios, not the vendor's script.
- Weeks 13 to 15: reference calls with comparable operators, plus a technical deep dive on peak load and settlement.
- Weeks 16 to 18: commercial negotiation and contracting, with the data-exit clause settled before signature.
If you are entering a new market at the same time, run the market decision first. Our seven-factor framework for choosing your next event market sets out why requirements change materially by geography, particularly around payments, identity rules and distribution.
What proof should you expect from a vendor?
The same proof we expect to provide. webook.com has operated the ticketing for Riyadh Season for four consecutive years, one of the largest recurring entertainment programmes in the world, and has sold more than 40 million tickets to over 18 million users across a network reaching 180-plus countries. Those are the kinds of figures an RFP should demand, with the event names attached.
The operational detail behind a programme at that scale is where the useful answers live: how queues are sequenced, how inventory is released across a season, how entry is staffed across simultaneous venues. Arab News published a look behind the scenes of Riyadh Season's ticketing operation that describes the scale of the challenge. Ask every bidder for their equivalent.
Before you issue the document
Read your draft RFP once more and ask a single question of every requirement: if a vendor answers "yes", do I know anything I did not know before? Delete every line that fails. What remains is the document that will actually separate the bidders.
If you want to test your requirements against a platform operating at national scale, talk to the webook.com business team.
Frequently asked
What should an event ticketing RFP include?
Nine requirement categories: commercial and settlement terms, peak-load capacity, access control and entry, fraud and resale governance, data ownership and exit, integrations and API, reporting, marketing and distribution, and support model. Write each requirement as an observable behaviour with evidence attached, not as a feature checkbox.
How many vendors should be invited to a ticketing RFP?
Five to eight. Fewer than five and you lose commercial tension; more than eight and evaluation quality collapses under document volume. Shortlist on operational fit and verified scale before issuing, not after responses arrive.
How should ticketing vendors be scored?
Weighted scoring across seven dimensions, one to five each, with weights published in the RFP. Apply automatic elimination for any vendor scoring lowest on peak-load evidence or data ownership, since neither weakness can be offset by strength elsewhere.
What is the most commonly missed requirement?
Data ownership at contract exit. Buyers negotiate rates hard and leave export scope, format and migration support to the contract stage, when leverage has gone. Define what leaves with you, in what format and within what timeframe, inside the RFP itself.
How long does a ticketing RFP take?
Twelve to eighteen weeks from requirements gathering to signature for an enterprise procurement, and it should conclude at least one full season before the first on-sale on the new platform. Compressed timelines shift risk onto implementation, where it costs the most.
Let's build your event's ticketing
Tell us about your event and what you want it to achieve, and we'll put a dedicated team on the setup that fits.
Get started now