A mobile event app RFP template

Nothing event-specific ranks for this search. What ranks instead is generic app-development agency content written for someone commissioning custom software, which is the wrong document for a conference organizer buying a product. This is the event-specific version. Copy it, cut what does not apply, send it.

Two pieces of advice before the template. First, ask for pricing as a formula, not as a number — “your price for 800 attendees” is answerable in four different ways and none of them compare. Second, score the written responses before you take a demo. A demo before scoring is a sales meeting; a demo after scoring is a verification of the three answers you doubted.

How to use this

1. Replace everything in [SQUARE BRACKETS].
2. Delete requirement lines that do not apply to your event. A shorter RFP gets better answers.
3. Set the weights in the scoring sheet before you send it, not after the responses arrive.
4. Send to five vendors maximum. Beyond five, response quality falls and so does your reading time per bid.

The template

Copy everything between the rules.

---

REQUEST FOR PROPOSAL — MOBILE EVENT APP

1. Organization and event

• Organization: [ORGANIZATION NAME]
• Event name: [EVENT NAME]
• Dates: [START DATE] to [END DATE]
• Venue and city: [VENUE, CITY]
• Format: in person / hybrid / multi-site — [SELECT]
• Expected attendance: [NUMBER] registered, [NUMBER] expected onsite
• Sessions: [NUMBER] across [NUMBER] tracks
• Speakers: [NUMBER]. Sponsors: [NUMBER] across [NUMBER] tiers
• Prior app used, if any: [NAME OR NONE]

2. Timeline

• RFP issued: [DATE]
• Questions due: [DATE]
• Responses due: [DATE]
• Shortlist demos: [DATE RANGE]
• Decision: [DATE]
• Content build begins: [DATE]
• App must be live to attendees: [DATE]

3. Scope

We are buying an attendee-facing mobile application and an organizer console for the event above. We are not buying [registration / ticketing / badge printing / streaming — DELETE AS APPLICABLE], which is contracted separately with [VENDOR OR TBD].

4. Requirements

Answer each line Yes / Partial / No / Roadmap. For Partial and Roadmap, describe the limit in one sentence. Answers of “customizable” or “available” without a description are scored as No.

Schedule and content

1. Multi-day, multi-track schedule with filtering by track, room and day.
2. Personal agenda: attendees can save sessions to their own schedule.
3. Session detail with speaker bio, room and description.
4. Capacity limits on individual sessions, enforced at the point of sign-up.
5. Automatic waitlist promotion when a place is released.
6. Live schedule changes reach attendees who already saved the session.
7. Speaker profiles with photo, bio and their session list.
8. Sponsor listings ordered by tier, with logo, description and link.
9. Content updated by the organizer without vendor involvement.
10. Content entry via bulk import as well as one at a time.

Networking

11. Searchable attendee directory.
12. Attendee controls what appears on their own profile.
13. Attendee-to-attendee connection request and acceptance.
14. In-person connection method that does not require typing a name.
15. Attendees can opt out of the directory entirely.
16. Direct messaging between attendees, with a block or report control.

Live engagement

17. Live Q&A during a session, with upvoting.
18. Moderation queue for questions before they are displayed.
19. Live polls, created and launched during the event.
20. Poll results visible to the room in real time.
21. Session-level feedback or rating from the attendee.
22. Free-text feedback routed to the organizer, not published.

Notifications

23. Push notification to all attendees.
24. Push notification to a segment (track, ticket type, day).
25. Notification scheduled in advance for a specific time.
26. Notification deep-links to the specific item it refers to.
27. In-app announcement feed retaining history.
28. Delivery reporting: how many devices received each notification.

Branding and store presence

29. Organizer’s logo, colours and typography applied throughout the app.
30. App published under the event’s or organization’s own name.
31. Published to the Apple App Store as a native app.
32. Published to Google Play as a native app.
33. Web version accessible without installing anything.
34. State explicitly who submits to each store and under whose developer account.
35. State the total elapsed time from content freeze to app live in both stores.

Organizer console

36. Multiple administrator accounts with distinct roles.
37. Moderator role limited to Q&A and content approval.
38. Audit trail of administrative actions.
39. Attendee import from CSV.
40. Invitation sending with per-recipient delivery status.
41. Onsite check-in against the guest list.
42. Live arrivals count during the event.
43. Engagement analytics available during the event, not only afterwards.
44. Post-event export or archive of Q&A, polls and feedback.

Security, privacy and accessibility

45. Name the data centre region where attendee data is stored.
46. State your data retention period and the deletion process after the event.
47. Describe how an attendee requests deletion of their own data.
48. Confirm whether attendee data is used for any purpose beyond this event.
49. Confirm whether attendee data is shared with sponsors, and on what basis.
50. Provide any current third-party security assessment or certification.
51. Provide an accessibility conformance report or equivalent VPAT.
52. State the WCAG version and level the attendee app is tested against.
53. Confirm screen reader support on iOS and Android.
54. Confirm minimum supported OS versions for both platforms.

Support

55. Support hours during the event, in our time zone.
56. Named contact during event days, with a response time commitment.
57. Escalation path for a live incident during a keynote.
58. Content build support: what you do versus what we do.

Commercials

59. State your pricing as a formula, with every variable named.
60. State every add-on with its published price, including badging, streaming, integrations and additional administrator seats.
61. State the price at [YOUR NUMBER] attendees and at [YOUR NUMBER × 2] attendees.
62. State whether there is a maximum total charge per event, and what it is.

5. Response format

• Answers to the numbered lines, in order, in a document or spreadsheet.
• One page of company background, maximum.
• Two references from events of comparable size and format.
• Pricing on a separate page.
• No slide decks. No video.

6. Evaluation

Responses are scored on the sheet below. Shortlisted vendors are invited to a 45-minute demo driven by our agenda, not theirs.

7. Contact

Questions to [NAME], [EMAIL], by [DATE]. Answers will be circulated to all bidders.

---

The scoring sheet

Set weights before you read a single response. The weights below are a starting point for a mid-size in-person conference; move them, but move them now rather than after you have a favourite.

Category	Weight	Why this weight
Schedule and content	20	The schedule is what attendees open the app for. Everything else is secondary to it being correct and current.
Live engagement	15	Q&A and polls are where an app either changes the room or does not.
Branding and store presence	15	Determines whether attendees experience your event or the vendor’s.
Organizer console	15	You will spend more hours here than attendees spend in the app.
Security, privacy, accessibility	15	The only category that can stop a purchase after it is agreed.
Networking	10	High value, but the feature set is fairly uniform across vendors.
Notifications	5	Nearly universal. Score the deep-linking and the segmentation, not the existence.
Support	5	Weight this higher if your event runs across a weekend or a holiday.

Score each line 2 for Yes, 1 for Partial, 0 for No or Roadmap. Divide the category score by the number of lines in the category, multiply by the weight, and total. Pricing sits outside the score and is compared separately, because a weighted price score lets an expensive product buy its way past a functional gap.

The four answers worth re-reading

Line 34, who submits to the stores. If the vendor submits under their own developer account, your app’s listing belongs to them and moves when you move. If you submit under yours, you need an Apple Developer Program membership and someone who has done it before. Neither is wrong; not knowing which one you bought is.

Line 45 and 46, data location and retention. These are the two questions your legal or IT reviewer will ask, and they arrive late. Getting them answered in the RFP moves that conversation off the critical path.

Line 51, the accessibility conformance report. Most vendors in this market will not have one. Asking still works, because the shape of the answer tells you whether accessibility has ever been tested or is being described from memory.

Line 62, the maximum charge. A per-attendee price without a ceiling is an open-ended commitment on your biggest event. Ask for the number, in writing, in the bid.

What we would answer

For transparency, since this template names criteria we are also scored against: event67 publishes its pricing formula on the pricing page — free to 50 activated attendees, then $5 each, with a hard ceiling of $4,750 per event and no add-on catalogue. It publishes branded native apps to both stores under the event’s own name. It does not do registration, ticketing, badge printing, streaming, or exhibitor lead retrieval, so lines about those should be scored against us as No. Our answer to line 51 is that we do not currently publish an accessibility conformance report; the theme editor checks every colour pair against WCAG AA and surfaces the result, which is not the same thing and should not be scored as if it were.