Template · free
Event app RFP template
A 40-line requirements sheet for buying a branded event app, grouped by audience, modules, data, security, delivery and commercials. Each line carries a priority so vendors answer the same questions in the same order and you can score the replies side by side.
Everything below is free to read and copy. A person from our team emails you the editable working file (CSV, opens in Excel or Google Sheets) within one working day.
Got it.
We'll reply by email with the template within one working day. If it has not arrived by then, check spam or message us on WhatsApp.
Request received ·
Prefer to talk first? Contact the team.
Who it is for
- Association secretariats comparing two or three conference app vendors
- Corporate event managers whose procurement team insists on a written RFP
- PCOs and agencies who must respond to a client-issued app tender
How to use it
- Fill the three cover lines at the top of your own copy: occasion name, dates, expected headcount.
- Delete rows that do not apply, then change any Priority you disagree with. Keep at least 15 Must rows so the scoring means something.
- Send the sheet to each vendor with the Vendor response, Score and Notes columns blank.
- Score every reply 0 to 5, multiply by priority weight (Must 3, Should 2, Could 1) and compare totals only after reading the Must rows.
The contents
| # | Area | Requirement | Priority |
|---|---|---|---|
| 1 | Scope | Name the occasion, dates, venue city and expected headcount in the response | Must |
| 2 | Scope | List every audience the app serves (delegates, speakers, sponsors, staff, guests) | Must |
| 3 | Scope | State whether one branded app can host several occasions or years | Should |
| 4 | Scope | Confirm the app works on current iOS and Android plus a browser fallback | Must |
| 5 | Login | Describe every login option offered (OTP, code, QR, delegate ID, email) | Must |
| 6 | Login | Explain how people without the app can still join polls or registration | Should |
| 7 | Login | State how duplicate or shared accounts are detected | Should |
| 8 | Agenda | Show how multi-track agendas, speakers and room changes are published | Must |
| 9 | Agenda | Confirm attendees can build a personal schedule and get reminders | Should |
| 10 | Agenda | Describe how last-minute changes reach only the affected groups | Must |
| 11 | Engagement | Describe live polls, quizzes and Q&A, including moderation | Should |
| 12 | Engagement | Confirm a feedback form can be attached to each session | Must |
| 13 | Engagement | Explain how points and a leaderboard are configured, if offered | Could |
| 14 | Networking | Describe the delegate directory and what each person can hide | Should |
| 15 | Networking | Describe meeting or slot booking and its capacity rules | Could |
| 16 | Exhibition | Explain exhibitor stall pages, scanning and lead capture, if relevant | Could |
| 17 | Communication | List channels for announcements: push, WhatsApp, SMS, email | Must |
| 18 | Communication | State who sends WhatsApp messages and who pays the per-message charge | Must |
| 19 | Communication | Show delivery logs by recipient and channel | Should |
| 20 | Hospitality | Describe how flights, rooms and pickups are collected and shown to each guest | Should |
| 21 | Branding | Confirm full control of colours, logo, splash, navigation and icons | Must |
| 22 | Branding | State who owns and publishes the store listing and under which account | Must |
| 23 | Admin | Describe organiser roles and what each role can change | Must |
| 24 | Admin | Confirm bulk import of members from a sheet with error reporting | Must |
| 25 | Admin | Show an activity log of who changed what and when | Should |
| 26 | Data | List every data field collected from attendees and why | Must |
| 27 | Data | State where data is hosted and which sub-processors are used | Must |
| 28 | Data | Describe export formats and who can export what | Must |
| 29 | Data | State retention period and how deletion on request is handled | Must |
| 30 | Security | Describe encryption in transit and at rest, in plain terms | Must |
| 31 | Security | Describe how access is removed when a team member leaves | Should |
| 32 | Security | Confirm the incident notification process and timeline | Must |
| 33 | Security | Share any independent audit or certification, stating exactly what it covers | Should |
| 34 | Delivery | Give a timeline from signed scope to a store-ready build | Must |
| 35 | Delivery | Name the people who will work on the occasion and their roles | Should |
| 36 | Delivery | Describe the test plan and who signs off before launch | Should |
| 37 | Support | State support hours in IST and the channel used during the event | Must |
| 38 | Support | Describe on-site or remote command-centre support on event days | Could |
| 39 | Commercial | Provide pricing by occasion with each cost driver itemised | Must |
| 40 | Commercial | List what is excluded: SMS, WhatsApp, payment fees, translation, custom builds | Must |
Where it has been used
The structure follows the questions secretariat teams asked while scoping conference and member-meet apps. No vendor names, prices or scores from any real tender appear in it.
Questions people ask
Should the RFP ask vendors for a fixed price?
Ask for a price per occasion with the cost drivers listed separately (headcount, modules, languages, WhatsApp volume). A single fixed figure hides what changes it, and you will want to know before the agenda grows.
How many vendors should receive it?
Three is enough. More than that gives you more reading than comparison, and the Must rows quickly show which vendors cannot meet the basics so you can drop them early.
Is this written for Sociana specifically?
No. The rows describe what any branded event app should answer, including questions Sociana is happy to be asked about login, data deletion and who holds the store listing.
Want this running inside your event app?
Sociana turns lists like this into live screens, requests and reminders for your guests and your desk. A 20-minute walkthrough shows how.