Event technology RFP template for paid event businesses

You're buying event software, and every proposal sounds reassuring. Ticket sales are simple. Reporting is powerful. Support is responsive. Then you ask who handles a failed refund on a Saturday evening, and the answers start getting less clear.

An event technology RFP, or request for proposal, should make those answers comparable before you sign. Tell suppliers which paid events you run, what the software must do in realistic situations, and how to price the same requirement. Ask them to explain limitations, demonstrate the work, and attach the terms you would actually accept.

The template below is for an event business buying ticketing, registration, admission, communications, or related software. Copy the sections you need, replace the bracketed instructions, and remove requirements that don't apply. You don't need to make your buying process bigger than the purchase. You do need to know what happens to ticket income, attendees, and staff when the software becomes part of your event.

Decide whether you need an RFP

A written proposal process helps when several people must approve the purchase, suppliers quote differently, or moving systems would affect live events and customer records. It also helps when a simple demo cannot settle the questions that matter to your business.

For a straightforward purchase with clear published terms, you may only need a short requirements sheet, a practical trial, and a contract review. Sending a long questionnaire to every possible supplier can create more work without improving your decision. Start with the uncertainty you need to resolve.

The problems organizers report after buying are the ones worth testing before you sign. In Loopyah's 2026 survey of 350 event organizers, high fees, limited customization and poor support were the most common frustrations with their current ticketing platform.

Our guide to event software features helps you identify the work you're buying software for. This template takes the next step, asking suppliers to prove how they would deliver it and what you would pay. If you're requesting rooms and venue services, use the separate venue RFP template.

Choose a person to coordinate the purchase. Bring in whoever runs ticket setup, manages admission, reconciles money, and approves data handling or contracts. In a small business, that may be the same person several times. The responsibilities still need answers, even when you don't have departments to assign them to.

Set the response rules before asking questions

Give each requirement a short reference, such as SALES-A or DATA-B. Require suppliers to keep those references in their response. Otherwise you'll spend the review translating differently organised brochures into something you can compare.

Ask suppliers to use these response labels:

• Included now, with the proposed plan and configuration identified.

• Available at extra cost, with the charge and supplier identified.

• Requires your team to complete a stated manual task.

• Requires another product or a custom integration.

• Planned, with no current availability to rely on.

• Unavailable, with any proposed alternative explained separately.

For each answer, request evidence, limitations, setup responsibility, and the relevant price reference. A help article can explain routine setup. A demonstration is better for a workflow with several decisions. Contract wording is necessary for a commercial commitment. Choose the evidence that answers the question.

Tell suppliers that unanswered requirements remain unresolved. They aren't included because nobody mentioned a charge, and they haven't failed merely because someone missed a cell. Ask for clarification, record the answer, and compare the revised proposal.

Use the following sections as your working request. The quoted instructions describe what to ask; your completed version should contain your own dates, volumes, responsibilities, and actual event conditions.

RFP section one: your business and purchase

Start with enough context for a supplier to propose the right service. You don't need to disclose your entire business plan or send identifiable attendee information to companies you haven't selected.

Write this introduction in your request:

"We operate [paid event formats] in [markets]. We are seeking [software and services] for [events or contract period]. Our current process uses [systems and responsibilities]. We want to change because [specific operational or commercial problems]. Our first required launch is [date], followed by [event dates]."

Then describe the volumes that affect delivery and pricing. Include events per year, expected paid tickets, complimentary tickets, orders, currencies, venues, concurrent events, and staff access. If you don't know a figure, give a labelled planning assumption and explain when you'll confirm it.

Be precise about what a volume means. Tickets and orders aren't interchangeable. A group purchase may create one order containing several attendees, and a refunded ticket may still count toward some supplier's usage allowance. Ask how the proposed contract measures each billable unit.

State what you're keeping. Perhaps your accounting software and website will stay, while ticketing and admission will change. Perhaps your venue supplies scanners under another agreement. Suppliers should price their part of that arrangement rather than assume you're replacing everything.

Close the introduction with the outcome you need. For example, "Our finance lead must reconcile each event's sales, refunds, fees, and payouts without requesting a custom report." That describes a result the supplier can demonstrate. "Better analytics" leaves too much room for interpretation.

RFP section two: the same response process for everyone

List the issue date, question deadline, proposal deadline, demonstration window, preferred decision date, and intended launch. Include a timezone. Ask suppliers to identify anything that makes the proposed schedule unrealistic before they invest in a full response.

Write:

"Return your response against our requirement references. Include the proposed plan, all required services, itemised pricing, implementation assumptions, applicable terms, and exceptions. State how long the offer remains valid. Identify the person authorised to clarify the proposal."

Name one contact for questions. When an answer changes the requirement, send the clarification to every supplier still being considered. Remove confidential commercial details from shared answers, but keep the requirement consistent.

Tell suppliers how you'll decide. Explain which requirements can prevent selection, what you'll test, who will review the proposal, and whether you expect a trial or reference conversation. You can disclose evaluation priorities without pretending that every decision fits a numerical formula.

Don't promise a purchase simply because you're running an RFP. Explain whether the request is exploratory or funded, whether a budget range is available, and what approval remains. A supplier can then decide whether its likely offer fits before writing a proposal you cannot afford.

RFP section three: demonstrate ticket sales and buyer service

This is where the request should start sounding like your event business. Use a real event configuration with fictional customer details. Give each shortlisted supplier the same starting information and ask them to show the result.

For example:

"Create our sample event using [ticket types], [sales periods], [capacity rules], and [buyer information]. Show a mobile purchase, the full price displayed to the buyer, payment, confirmation, and ticket access. Identify every setting our team must configure and any step supplied by another company."

Add the exceptions you actually encounter. Ask what happens when a payment fails, a buyer corrects an email address, someone purchases for a group, or a ticket holder needs a transfer. Have the supplier show both the buyer's experience and the staff action behind it.

For applicable US live ticket sales, the FTC's fees rule guidance explains upfront total pricing, including mandatory fees, with specified exclusions. Ask suppliers to demonstrate your intended pricing display across the purchase journey. Confirm the requirements that apply in your selling markets with the person responsible for compliance.

Request a refund demonstration using your policy. Ask who initiates it, which permissions they need, what the buyer receives, which fees return, and what records change. Then ask the supplier to show the transaction in its reports. A refund button alone doesn't answer the financial questions.

If you sell reserved places, multi-day passes, bundles, memberships, or add-ons, include the relevant purchase. Leave them out if you don't. You want a supplier to solve your actual selling arrangements, and you want the proposed price to cover those arrangements.

RFP section four: prove admission and disruption handling

Admission requirements depend on your venue, audience flow, staff, and connectivity. Describe those conditions before asking whether a product has an offline mode or supports scanning.

Write:

"Show our admission team admitting valid ticket holders, identifying a duplicate scan, finding a buyer without a ticket on screen, and handling a ticket with the wrong access. Explain which devices, accounts, permissions, internet services, and training this requires. Itemise equipment and staffing supplied under your proposal."

If unreliable connectivity is a genuine risk, ask the supplier to demonstrate what still works after the connection drops. Ask what data must be downloaded beforehand, which actions stop, how devices behave independently, and what happens when they reconnect. A vague promise about offline operation is hard to turn into an admission plan.

Don't combine ticket scanning and card payments into one assumed capability. They may depend on different services and carry different restrictions. If you need walk-up payments, request a separate demonstration covering payment approval, ticket creation, receipts, and the resulting admission record.

Describe your likely disruption too. That might be a postponed start, a cancelled date, or a venue change. Ask how staff identify affected buyers, issue the right message, manage refunds or transfers, and prevent outdated information from remaining in confirmations.

The useful evidence is a clear sequence with named responsibilities. Your team needs to know which action it takes, which action the supplier takes, and how to reach the right person while attendees are waiting.

RFP section five: reports, connections, and data export

Ask for the records you'll use to run the business. Give the supplier a sample output with invented details, or describe the fields and calculations you need. Avoid requesting a dashboard simply because another buyer included one.

Write:

"Using the demonstration transactions, show sales, discounts, refunds, fees, disputes, and payouts. Explain how the records connect, when they update, and how our finance lead can investigate a difference. Provide a sample export and define its fields, currency treatment, and timezone."

For each connection to another system, name the task. A connection that adds a buyer to your contact list may not also update a refund, preserve a marketing withdrawal, or repair a failed transfer. Ask the supplier to explain direction, timing, included records, failure notices, and who fixes errors.

If a supplier proposes an API, meaning a connection your own software can use, find out who builds and maintains it. Ask about access charges, usage limits, documentation, testing, and change notices. Include the other system's costs where they affect the proposed arrangement.

Require an exit export before you buy. Ask the supplier to provide a sample containing the records you would need after leaving, with sensitive details removed. Check whether you can connect orders to tickets, refunds, and payment references. A list of email addresses is insufficient for reconciling an old event.

Marketing permissions deserve their own check. Ask whether the export preserves permission records and withdrawals, rather than assuming a contact's presence proves permission to advertise. Our event email consent guide explains the buying and sending decisions behind that requirement.

RFP section six: security, privacy, and accessibility evidence

Keep this section proportionate to the information and services you're buying. Ask your security or data adviser to review the requirements that matter for your business. Sending a copied questionnaire nobody can assess gives you little protection.

Request named responsibilities for account access, staff removal, authentication, incident reporting, backups, and recovery. Ask suppliers to explain the scope and date of any independent assessment they provide. A certificate should identify the service covered, and its existence doesn't answer every question about your intended configuration.

The CISA vendor assessment guide provides structured security questions for smaller businesses assessing technology suppliers. Use relevant questions to identify evidence you need, then assign someone capable of reviewing the answers.

For payment handling, ask which organisations process or store card information and what your own responsibilities remain. The PCI Security Standards Council's merchant guidance is a starting point for understanding payment security. Ask your payment provider which validation applies to your arrangement. Don't accept a supplier's payment security claim as a complete assessment of your business.

Include privacy questions about processing locations, other companies handling the information, retention, deletion, incident assistance, and the contractual purpose of processing. Identify which information the supplier processes for you and which it processes for its own purposes. Those roles can differ between activities.

Where relevant, the ICO's controller and processor contract guidance explains required contractual provisions under the UK GDPR. Have the appropriate reviewer check your proposed agreement, including what happens to information when the contract ends.

For accessibility, state the standard and level your organisation requires and ask for evidence covering the buyer journey you will use. The W3C WCAG reference explains accessibility success criteria. Request a dated assessment, known limitations, and remediation plans, then test relevant tasks such as keyboard purchase, understandable form errors, and ticket retrieval.

Keep accessibility commitments specific. A report covering the supplier's marketing website doesn't establish that your checkout, embedded forms, or configured communications meet your requirement. Ask which components were assessed and what changes your team could make that affect the result.

RFP section seven: the complete price and cash arrangement

Request a price for the same contract period and operating assumptions from every supplier. Separate the amount your business pays from charges ticket buyers pay, while showing both. Neither figure tells the whole commercial story alone.

Write:

"Provide all compulsory charges for our stated volumes and services. Identify one-time setup, recurring subscription, per-order and per-ticket charges, payment processing, equipment, support, integrations, training, and taxes. Explain minimum commitments, overage charges, and any items excluded from the proposed total."

Ask each supplier to price your expected activity and a lower-sales case using assumptions you provide. Add a higher-volume case if crossing a threshold could change the bill. These are planning scenarios, not forecasts or market benchmarks. Keep the assumptions identical across proposals.

Check charges for refunds, disputes, failed payments, complimentary tickets, and cancelled events. Ask what happens to charges the buyer paid when you issue a refund. If another provider controls the answer, request its applicable terms rather than an assurance from someone who cannot make the commitment.

Payout timing needs a separate response. Ask when funds become available, which checks or conditions can delay them, whether reserves or holds apply, and what changes after a cancellation or dispute. Put the proposed cash dates into your event budget, alongside deposits and supplier payments.

Also ask how prices change. Record the renewal method, notice period, permitted price increases, currency conversion arrangements, and charges for adding events or users. A proposal can look affordable at launch while leaving the renewal decision expensive or rushed.

Don't count a refundable reserve as an ordinary software expense if you expect its return. Record the cash restriction and the conditions for release separately. Equally, don't treat a promised early payout as unconditional cash until you've checked the terms that govern it.

RFP section eight: implementation, support, and exit terms

Ask the supplier to work backwards from your first on-sale date. You need time for configuration, migration, training, testing, and corrections, with someone responsible for each dependency.

Write:

"Provide an implementation plan showing supplier tasks, our tasks, prerequisites, decision dates, and acceptance checks. Identify what must be complete before tickets go on sale. State what happens if either party misses a dependency and whether proposed fees change."

For migration, specify which records must move and which will remain accessible in the previous system. Ask how the supplier checks completeness and handles unmatched records. Avoid moving a live sale midway through its run without understanding ticket validity, payment history, refunds, and buyer communications.

Require a support schedule covering the hours your events actually operate, including timezone and holiday treatment. Ask how urgent incidents are classified, which channel to use, when a human responds, and how an unresolved incident escalates. An initial response target doesn't promise a working resolution.

Then request the actual contract documents. Include the order form, service terms, support commitments, processing agreement where applicable, and any third-party terms you would accept. Ask the supplier to identify precedence when documents disagree, because an attractive proposal may not override standard terms.

Review cancellation, suspension, renewal, liability, termination, and exit assistance with the appropriate adviser. Ask what happens to events already on sale if the relationship ends, how long you can access reports, what exports cost, and when records are deleted. You should understand leaving before you commit to joining.

Compare evidence before assigning scores

Start by separating essential requirements from preferences. An essential requirement must be necessary to deliver your event or meet a genuine obligation. Explain why it matters and what evidence confirms it. Keep the list small enough that your team can defend every item.

A supplier unable to meet an essential requirement needs an accepted change to the arrangement before you consider selection. Extra marketing tools or a lower subscription don't compensate automatically. If your team accepts an alternative, document the changed responsibility and price it.

For proposals that remain, compare the same demonstrated work, complete costs, implementation demands, support, and contract conditions. A score can help summarise the discussion, but choose your categories and weights around your purchase. There is no universal percentage that makes security, ticketing, or support matter the right amount for every event business.

Agree what each score means before the demonstrations. For example, your strongest rating might require the supplier to complete the task in the proposed plan with evidence your reviewer accepts. A weaker rating might mean a documented manual workaround your team can operate. Keep unavailable and untested answers visible instead of averaging them into a reassuring total.

Ask reviewers to record observations independently before the group discussion. One person may notice a refund permission problem while another likes the dashboard. Both observations matter, but they answer different requirements. Tie each comment to the task and consequence so the conversation stays useful.

Run a demonstration your team can challenge

Send the sample event and required tasks in advance. You aren't trying to catch a salesperson unfamiliar with your event. You're checking whether the proposed arrangement works when the supplier has enough information to configure it properly.

Give your own staff some of the controls during a trial where available. Someone who will reconcile payouts should try finding a refunded order. Someone managing admission should test the approved exception process. Ask what training is needed when the person using the software isn't the specialist presenting it.

Record the plan, configuration, additional products, and assumptions used in the demonstration. If a supplier demonstrates a capability from a higher-priced plan, request a revised proposal or repeat the task using the proposed plan. Evidence needs to match what you're buying.

Use fictional customer and payment details in demonstrations. When a later pilot needs real information, agree the processing arrangements and permissions first. Buying a tool shouldn't require casually handing every shortlisted company your attendee database.

A reference conversation can resolve remaining delivery questions. Ask about a comparable event format and implementation, with the customer's permission to speak. Explore what required more staff time than expected, how support behaved during an incident, and whether reporting matched their finance process. Treat the answer as one customer's experience, not a performance guarantee.

Example response you can ask suppliers to complete

Here's how a requirement becomes something you can review. This fictional example describes a refund reporting task, without assuming that every event needs the same permissions or reporting structure. Change the task to match the people who actually manage your money.

Your request could read:

"FINANCE-A: Our authorised event manager must refund a selected ticket from a group order. The remaining tickets must stay valid. Show the buyer notification, changed ticket status, refund record, fee treatment, and the entries our finance lead uses to reconcile the payout. State the proposed plan, required permissions, extra charges, and any manual work."

Ask the supplier to complete these fields against that reference:

• Availability: [choose the response label that describes the proposed arrangement].

• Delivery: [describe the staff action and what the system does afterward].

• Evidence: [identify the demonstration task, documentation, and sample records].

• Limitations: [state restrictions, dependencies, and exceptions].

• Responsibility: [name the supplier role and customer role responsible for setup or operation].

• Price reference: [identify the relevant charge or confirm inclusion in the proposed price].

Suppose the supplier answers that the refund is included, but staff must calculate one charge manually and enter it into accounting. You haven't received a complete automatic workflow. You have received an offer containing a specific manual responsibility. Ask your finance lead whether that work is acceptable, how often it would occur, and how they would check it.

If they accept it, record the workaround in the agreed process. If they cannot accept it, ask for another supported arrangement or reject the proposal against that requirement. Changing a score doesn't remove the task somebody still has to perform.

A good response can also reveal that your request is unnecessarily restrictive. Perhaps you named a particular report format when your real need is to reconcile each transaction. Let the supplier demonstrate another format, then have your finance lead test whether it answers the same question. Keep the underlying requirement consistent across suppliers even when their methods differ.

Keep commercial assumptions visible during negotiation

Negotiation often changes more than price. A supplier might offer a lower rate if you commit to more events, move your on-sale date, handle migration yourself, or accept a longer term. Ask for each condition in writing and update the comparison before treating the revised offer as a saving.

Consider a proposed volume commitment. Your expected programme might support it, but what happens if you cancel a date or postpone expansion? Ask whether unused volume carries forward, whether a minimum bill remains payable, and whether different event types count toward the same allowance. Then compare the commitment against the programme you're prepared to fund.

If your team takes on implementation work, name who has time to do it. Removing a supplier's setup charge doesn't remove data cleaning, configuration, testing, or training. Record that work alongside the revised price so the people approving the purchase understand what changed.

Keep optional services distinct. You can ask for a separate price for an attendee app or additional reporting without adding either to your required offer. The supplier should still return one complete price for the agreed main requirement. That lets you make the purchase decision first and consider upgrades on their own merits.

Keep a version date on your requirements and ask suppliers to identify that version in their final response. Otherwise, a negotiated price may still refer to tasks your team has changed.

Finally, check the revised offer's expiry. If contract review or testing will run past it, ask for an extension before relying on the price. Approval should refer to an offer the supplier still agrees to deliver.

Turn the final proposal into a delivery agreement

Send shortlisted suppliers a concise clarification list with requirement references. Ask for updated prices and terms when an answer changes the offer. Keep promises that affect your decision in the accepted documents, including who supplies any extra work.

Before signing, reconcile the selected response with the order form, implementation plan, and contract. Check the proposed plan name, included volumes, compulsory services, payment arrangements, and unresolved exceptions. Ask the people responsible for launch and finance to confirm they can deliver their assigned work.

Ask each supplier how it handles changes after approval. Your event team may add another ticket type, change a date, or need a new staff role. Find out which changes your account administrator can make, which need supplier assistance, and which trigger a revised charge. Include the normal notice required for that assistance.

Also record where your team will find the accepted instructions. The person answering buyer questions may never read the original proposal, but they still need the agreed refund process and support contact. Translate those commitments into your operating notes and have the relevant staff, including temporary staff working on admission, check them during training before the first live sale begins.

Your final decision record can be short. State which requirements the chosen offer meets, what evidence you reviewed, what the business will pay, and which conditions or workarounds you accepted. Name the owner of each remaining action and its deadline.

Then book the acceptance checks before launch. Reuse the purchase, refund, admission, reporting, and export tasks you evaluated so your staff can confirm the delivered configuration matches the agreement. If it doesn't, resolve the difference before putting a live event through it.

An RFP has done its job when you can explain the purchase in those concrete terms. You know what you're buying, how your team will use it, what it costs under your event assumptions, and who takes responsibility when something needs fixing.