Conference management software: a practical evaluation checklist

What should you define before you look at any software?

Write a one-page outline of your event before you book a single demo. List each phase in order, the person or team who owns it, and what that phase produces for the next one. A typical sequence is call for abstracts, review, agenda build, registration, exhibit sales, on-site check-in and post-event reporting.

This outline becomes your evaluation script. Without it, demos tend to follow the vendor's strongest path rather than the parts of your program that are actually hard.

1. List every phase of your event and its owner.
2. Note the output of each phase, such as accepted abstracts, a published agenda or a badge list.
3. Mark the handoffs that currently rely on spreadsheets, email threads or re-keying.
4. Rank those handoffs by how much stress they caused at your last event.

Which capabilities should be on the checklist?

Group requirements by phase so gaps are easy to see. The questions below are editorial suggestions; remove any that do not apply and add the ones specific to your audience.

1. Registration: Can you define tiers for different audiences, such as members, students, exhibitors or faculty? Can a department or company register a group together and manage its seats?
2. Program: Can sessions be revised after publication without breaking speaker assignments?
3. Abstracts: Can you open a call, assign reviewers, collect scores and record decisions, and does accepted work flow into the agenda?
4. Exhibits and sponsors: Are halls, booths, exhibitors and sponsorships connected, or tracked in separate lists?
5. On site: How does check-in work at the door, and can you record attendance per session?
6. After the event: If you award continuing-education credit, does it come from recorded attendance?

How should accessibility factor into the evaluation?

Accessibility is easier to deliver when it is collected and planned early. The W3C Web Accessibility Initiative guidance on accessible presentations recommends asking participants about accessibility requirements during registration, choosing accessible venues and digital materials, arranging captioning, and scheduling breaks.

In practice, check that your registration form can include an optional accessibility question, that the people who need those answers can see them, and that your public agenda and attendee-facing pages are usable with a keyboard and screen reader.

Source: W3C WAI: How to Make Your Presentations Accessible to All

How do you run a demo that tells you something?

Send the vendor two or three scenarios in advance and ask them to show those, end to end. Good scenarios include a stressful handoff, such as a speaker withdrawing after the agenda is published, or an exhibitor moving booths a week before the show.

Score each scenario on the same simple scale across vendors, and write down anything that was described rather than shown.

1. Share scenarios at least a week before the demo.
2. Ask to see the data entered once and then reused in later phases.
3. Note every answer that begins with 'you could export it and...'.
4. Ask directly what the product does not do today, and record the answer.

What should you confirm before you commit?

Confirm scope, data ownership and support in writing. Ask how you export your records, who supports you during show week, and how pricing is scoped to your program. If a capability you need is not available, it is better to know before contracting than during setup.

Frequently asked questions