What 25 associations and trade show organizers actually ask event tech vendors

We analyzed 1,781 requirements and questions from the RFPs of 25 associations and trade show organizers. The findings were consistent, and the most expensive gaps were not in what buyers asked, but in what they left out.

Most advice on writing an event technology RFP is from people who have never had to respond to one.  

We have. Our solution design team responds to these documents constantly, and over the past two years, we have built a structured record of what arrives: The requirement lists, the scoring grids, the questions asked, and the answers we gave. When we sat down to analyze it properly, we expected to find variation. Different association, different sector, different event = different priorities.

That is not what the data shows. Association and trade show organization RFPs are remarkably consistent, and they are consistent in a specific and somewhat surprising way. They are thorough about the things vendors find easy to answer, and close to silent about the things that become expensive eighteen months into a contract.

This article is what we found, and what we would change.

How we did this

The dataset covers 25 organizations: Professional and trade associations, and trade show organizers, running conferences, exhibitions, and the conference-plus-exhibition events that sit between them. Together they represent 1,781 individual requirements and questions, drawn from two sources: Original RFP documents issued by organizers, and completed responses where the questions came to us directly.

Counting is at the theme level. An organization that asks twelve separate questions about session management counts once. This measures how many buyers care about something, not how many words they spent on it.

We have kept every organization anonymous, and no requirement is quoted verbatim. Many of these documents were issued in confidence, and the aggregate is the useful part anyway.

Part one: the eight things nearly everyone asks about

Ranked by how many of the 25 organizations raised each theme at all.

Two observations are worth pulling out.

Exhibitor tooling is a first-tier concern, and it is what makes association RFPs different. Nearly every organization in the dataset asked about exhibitor portals, lead capture, sponsorship inventory, or interactive floor plans. This is the clearest structural difference between an association RFP and a corporate event RFP. An association running a conference with an exhibition is serving two customers with two entirely separate definitions of success—attendees who want a good program, and exhibitors who want qualified leads and will decide next year's renewal based on whether they got them. Most published RFP advice treats the event as though only attendees exist.

Support is asked about far more often than it is specified. Twenty-one organizations raised support in some form. Very few defined what they actually wanted: Whether a named person is assigned from day one, what happens at 7 AM on the second show morning when badge printing fails, what the contractual response time is during live event hours as opposed to business hours, and whether training is included in the license or billed separately as professional services. "Describe your support model" is a question every vendor answers well, but no two vendors answer it in the same way.

‍

Part two: the four things almost nobody asks about

This is the part of the analysis we did not expect, and it is the reason we wrote this article rather than another RFP template.

Applying deliberately strict matching: Counting only explicit, unambiguous language rather than anything adjacent. Four themes are close to absent.

Data ownership and contract exit: 2 of 25.

Two organizations in the entire dataset stated plainly who owns the data and what happens to it when the contract ends. Two. Many more asked about exporting reports, which is a different question with a comfortable answer. The one that matters is what happens at the end: who owns the attendee records, the behavioral data, the exhibitor lead history; in what format it is returned; how long the vendor retains a copy; whether any of it costs extra at the point when leverage has moved entirely to the other side of the table.

This is the single most consequential omission we found. It is asked about less than badge printing, and it is the only requirement on this list that cannot be renegotiated later.

Accessibility compliance: 4 of 25.

Only four organizations named a standard — WCAG, Section 508, or equivalent — as a requirement. For associations with public-sector members, education members, or healthcare members, accessibility is frequently a condition of participation rather than a preference. It is also, unlike most requirements, something that is genuinely difficult to retrofit. A vendor either built for it or did not.

Generative AI governance: 2 of 25.

Two organizations included contract language governing how a vendor may use generative AI on their data, whether attendee information can be used to train models, who owns AI-generated outputs, and what disclosure is required. Meanwhile, AI as a product feature came up considerably more often.

That asymmetry is the finding. Buyers are asking whether the platform has AI. Almost none ask what the platform does with their members' data to provide it. Of the two questions, the second is the one a board will eventually ask about.

Offline and low-connectivity operation:      .

Better represented than the others, but still under half, which is surprising for an in-person event category. Convention center's Wi-Fi fails. It fails at the worst possible moment, at the doors, on the first morning. What the check-in system does when the network drops, and whether scans reconcile cleanly on reconnection, are operational questions with live-event consequences.

Part three: you are not buying a platform, you are buying into a stack

This did not appear in any single question. It emerged from reading the documents.

Association RFPs name incumbents constantly. The registration provider under contract for another two years. The abstract management system the education committee will not give up. The AMS holding member records. The lead retrieval provider with an existing exhibitor relationship. The badge printers already in the warehouse.

Twenty-four of 25 organizations asked about integrations, and that number is not really about APIs. It is a signal that almost nobody is buying greenfield. You are buying a component that must fit within an existing arrangement, and the practical question is not "do you have an API?" Every vendor has an API, but:

• Which of these named systems do you connect to natively today, without custom development, and for which of them can you show a live client reference?
• Is the sync real-time or a nightly batch? Nightly batch means the badge printed at 8 AM reflects yesterday's registration.
• Who pays to build the integration, who pays to maintain it when the other vendor ships a breaking change, and what is the day rate?
• When a sync fails, can our team see the error and retry it ourselves, or do we file a ticket and wait?

We could go further. The most useful thing an association can put in an RFP is a plain list of every system the platform must talk to, named, with the contract end date for each. It reframes the entire evaluation, and it is the fastest way to find out which vendors have done this before.

Part four: one in five questions only ever earns a "yes"

Across the responses in our dataset, roughly one in five questions could be answered with nothing more than a confirmation of capability. Yes, we do that.

Some of that is unavoidable; you do have to establish the basics. But a substantial share is avoidable, and it follows a pattern. Long runs of closed questions about branding and configuration are the most common offender. Can you upload a logo? Can you customize colors? Can you use a custom domain? Can you change fonts?

Every vendor in your process will answer yes to all of them, which means these questions consume pages of everyone's time and move no candidate up or down your ranking. They also crowd out the questions that would.

A single open question does the work of fifteen closed ones. 

Compare:

“Can you customize the registration page with our branding?”

with:

“Describe the branding controls available to a non-technical administrator, and name what requires vendor involvement. Include a client example.”

The first is answered yes by everyone. The second immediately separates the field, because the honest answer for most platforms involves a boundary, and where a vendor draws that boundary tells you what working with them will actually feel like.

A practical rule: If you can predict that every vendor will answer a question identically, it is not an evaluation question. It is a checklist item. Move it to a requirements grid, score it as pass or fail, and use the saved space for questions that produce different answers from different vendors.

What a stronger RFP looks like

Nothing here argues for a longer document. Most of these RFPs are already long. The argument is for a different distribution of attention.

1. Put data ownership and exit terms in the document, not the contract negotiation. Who owns what, in what format it is returned, at what cost, and on what timeline. Ask it while you still have leverage.
2. Name every system the platform must integrate with, and the contract end date for each. Then ask which are native today, with a reference.
3. Specify support instead of asking about it. Named contacts, contractual response times during live event hours, escalation path, what is included and what is billed.
4. Ask for exhibitor outcomes, not exhibitor features. Average qualified leads per exhibitor across comparable events, with methodology. Feature lists are identical across vendors; results are not.
5. Convert predictable questions into a pass/fail grid. Reclaim the space for questions that discriminate.
6. Name a standard where a standard exists. WCAG level, SOC 2, ISO 27001, GDPR handling, AI and data use. "Are you compliant?" is not a question; it is an invitation.

A note on what we are not claiming

We build event technology. We compete for these contracts. That is worth saying plainly, because it shapes what this analysis can and cannot be.

What we can accurately tell you is what arrives on our side of the table, because we have read and analyzed it. What you should not take from us is a definition of the right answer. The value in the summarized analysis above is the pattern: The questions buyers ask cluster tightly around demonstrable features and thin out precisely where the long-term risk lies. That pattern holds regardless of who wins your process.

If it is useful, we have made the underlying question set available as a free tool. The Event Tech RFP Builder takes you through the requirement areas above, lets you set what is essential against what is merely preferred, and produces a cover letter and a vendor-ready requirements workbook with response column. It takes a few minutes, and it is yours to send to whoever you like, including our competitors.

And if you are in the middle of a process and want a second read from people who respond to these for a living, what your scoring weights are actually rewarding, where a requirement is written in a way every vendor will pass, what a realistic implementation timeline looks like against your event date, our solution design team does this. It is not a sales call, and it does not require you to be evaluating us.