Running a conference with 200 abstract submissions

Two hundred abstract submissions sounds like a good problem to have. It means your conference has demand, your CFP reached the right people, and your programme committee has real choices to make. But it also means you're about to run a pipeline that touches six distinct stages, dozens of reviewers, and hundreds of individual communications. If your tools aren't connected, this is where things start falling apart.

This is a walkthrough of what that pipeline looks like from open CFP to published schedule — and what changes when the whole thing runs in one place instead of five.

Opening the CFP

The call for papers is your front door. It needs to collect the right information without scaring people off with a 45-field form.

In ema, you configure submission forms with the fields that matter for your review process: title, abstract, topic track, preferred format (talk, panel, workshop), speaker bio. You set requirements — maybe a 300-word abstract limit, mandatory topic selection, optional supporting materials. You publish the form with a deadline, and it's live.

The old way: a Google Form that dumps responses into a spreadsheet. It works for 20 submissions. At 200, that spreadsheet becomes the single most fragile document in your entire event.

Managing the review process

This is where the spreadsheet model breaks down completely.

With 200 submissions and a review committee of, say, 8 people, you need structure. Who's reviewing what. Whether anyone has conflicts of interest. How scoring works. Where comments live.

In ema, you assign reviewers to submissions — either manually or by topic track. Reviewers score against criteria you define (originality, relevance, speaker experience, whatever matters for your event) using a structured peer review process. They leave comments in context, attached to the submission, not buried in an email thread that three people were accidentally left off.

You can see review progress at a glance: how many submissions have been scored, which reviewers are behind, where there's disagreement that needs discussion.

The alternative is a shared spreadsheet with a scoring column, a separate email thread per submission (or worse, one enormous thread for all of them), and a programme chair manually reconciling everything. At 200 submissions, that's not a process. It's a prayer.

Making decisions

Once reviews are in, you need to accept, reject, or waitlist every submission. At scale, this means bulk actions.

In ema, you sort by average score, filter by track, and make decisions in batches. Accept the top 60. Waitlist the next 20. Reject the rest. Each decision triggers an automated notification to the submitter — personalised, branded, sent from your event, not from a generic noreply address.

No more drafting 200 individual emails. No more copying rejection templates into Gmail and hoping you didn't accidentally send the acceptance version to the wrong person. (It happens. It's happened to most of us.)

Building the programme

Here's where connected tools earn their keep.

Accepted submissions flow directly into the schedule builder. They arrive with their metadata intact: title, abstract, speaker, format, track. You're not re-entering anything. You're not copy-pasting from a spreadsheet into a separate scheduling tool.

From there, you assign rooms and time slots. Drag a session into the 2pm slot in Room A. The system checks for conflicts — is the speaker already scheduled elsewhere at 2pm? Is the room over capacity? Is there a track clash that means your attendees have to choose between two talks they both want to see?

For a 200-submission conference, you're probably building a multi-track, multi-day programme. That means dozens of sessions across multiple rooms with overlapping constraints. Doing this in a spreadsheet or a standalone scheduling tool that doesn't know about your speakers or submissions is how you end up with a keynote speaker double-booked against their own workshop.

Coordinating speakers

Acceptance is not the end of the speaker workflow. It's the beginning of a new one.

Accepted speakers need to upload their presentation materials. They have AV requirements — "I need a confidence monitor" or "my demo requires a hardwired internet connection." They have questions about logistics, timing, and room setup.

In ema, each speaker has a discussion thread tied to their session. Materials upload into a tracked document store with version history. AV requirements are captured in structured fields, not scattered across email chains where the production team has to hunt for them the week before the event.

This replaces the familiar pattern: an email to the speaker asking for their slides, a reply saying "I'll send them next week," a follow-up two weeks later, another follow-up, a panicked upload the night before, and a production manager who's lost track of which speakers have actually submitted and which are still "planning to."

Going live

The published schedule is the part your attendees see. In ema, it goes live when you're ready — and updates in real time when things change.

Last-minute room swap because of a burst pipe? Update it once. Attendees see it immediately. Speaker cancellation? Remove the session, notify affected attendees, adjust the schedule. No PDFs to re-export, no "please refresh your app," no version confusion.

This matters more than it sounds. Conferences with 200 submissions typically have 40-80 sessions in the final programme. Changes happen. A tool that treats the schedule as a living document rather than a static export saves hours of scrambling on event day.

The old way vs. the connected way

The traditional pipeline looks like this: Google Form, then a review spreadsheet, then an email chain, then a separate scheduling tool, then a website update, then hope. Each handoff is a place where data gets lost, duplicated, or mismatched.

ema connects the whole pipeline. Submissions become reviews become accepted sessions become scheduled talks become the published programme. One data model, no re-entry, no handoff gaps.

For conferences with 200 or more submissions, the difference between a managed process and chaos is whether your tools talk to each other. A spreadsheet can hold data. It can't run a pipeline.