Nobody Wants to Review 400 Session Proposals in a Shared Inbox

There’s a moment in every call for papers cycle, usually around week three of review, when somebody on the programming committee says out loud: “Wait, isn’t this the same talk as number 112?” And it is. Same speaker, same content, two different titles, submitted eleven days apart because the first one didn’t get a confirmation email and they assumed it hadn’t gone through.

Nobody designed this process. It accumulated. Someone built a form one year, someone else added a scoring spreadsheet the next, and the whole thing is now held together by one staff member who knows where everything lives and takes their vacation in August for a reason.

The call goes out

The form is usually either a Word template people email back, or a free-text web form that asks for a title, an abstract, and a bio with no structure underneath any of it.

Both produce the same result, which is four hundred submissions in four hundred different shapes. Abstracts run from 40 words to 1,200. Half your submitters pick a track, the other half leave it blank or invent one. Learning objectives arrive as bullet points, paragraphs, or not at all.

And because none of it is structured, you can’t answer basic questions without reading everything. How many submissions came in for the clinical track? Nobody knows until someone reads every abstract and tallies them in a notebook. The data you need to manage the process is locked inside prose.

Submissions pile up in a shared inbox

This is where that duplicate gets born. Your submitter doesn’t get an acknowledgment, so they resubmit. Or they spot a typo in their abstract and email a corrected version, which now exists alongside the original with no indication of which is current.

Meanwhile nobody can tell at a glance who has responded to what. Two people on your team reply to the same question in different ways. A submitter asks for a deadline extension and gets one, informally, in a reply nobody else sees, so when their late submission lands there’s a brief argument about whether to accept it.

Assigning reviewers

Now you split four hundred proposals across six reviewers, usually in a spreadsheet with one tab each.

Several problems start here and compound. Workloads come out uneven, because splitting by submission number doesn’t account for the fact that tab four happens to contain eleven ninety-minute workshop proposals that each take real time to assess. Conflicts of interest get handled by someone remembering that a reviewer works for the company behind proposal 207. And reviewers can see who submitted, which means a recognizable name gets read more generously than an unknown one, every single time, by people who would sincerely tell you they’re being objective.

A process that shows reviewers the author’s name and affiliation is a process that will keep selecting the people who were on last year’s program.

Scoring, where the math stops working

Each reviewer scores in their own tab. One uses the 1-to-5 scale you specified. One uses half points. One stopped scoring on Tuesday and wrote comments instead.

Then you average everything and sort descending, which feels rigorous and isn’t, because your reviewers didn’t score the same proposals. Reviewer A gave out an average of 3.1 across her set. Reviewer D gave out 4.4 across his. A proposal that scored 3.8 from A was in her top tier. A proposal that scored 3.8 from D was in his bottom half. Sorting them together on a single column treats those two as identical.

There’s a second problem underneath the arithmetic. Most rubrics score things like clarity, originality, and speaker credentials, which are all measures of proposal quality. Very few score fit, meaning whether this specific audience, at this specific event, needs this talk. So the process reliably surfaces the most impressive submissions and only accidentally surfaces the most useful ones.

Telling everyone

Acceptances are the easy part. The rejections are where this gets painful, and where teams tend to run out of steam at exactly the wrong moment.

Hundreds of notifications, mail-merged if you’re organized and copy-pasted if you aren’t, with the inevitable one that goes out addressed to the wrong name. Nobody is tracking who’s been told, so a week later somebody emails asking about their submission and you have to go check whether they were ever notified at all.

Chasing speakers for things they already agreed to send

Your accepted speakers now owe you a bio, a headshot, a session description, AV requirements, and slides. You ask by email. Some send everything immediately. Most send one thing, at the wrong size, three weeks late.

So you chase. You maintain a spreadsheet of who’s outstanding on what, which goes stale the moment someone replies to a different person on your team. You get a headshot that’s 400 pixels wide and will look like a thumbnail printed in the program. You get a 600-word bio when you asked for 100, and now somebody has to edit it, which means someone has to approve the edit, which is another email chain.

None of this is hard. All of it is time, and it lands in the same six weeks as everything else.

The sticky notes

Eventually someone covers a wall or a conference table and starts building the agenda by hand, which is genuinely the most enjoyable part and also the one that creates the most downstream work.

You’re solving real constraints: room capacity against expected draw, keeping competing sessions out of the same slot, making sure your keynote speaker isn’t also moderating a panel ninety minutes later. Sticky notes are good for that. What they can’t do is tell you that the title on the wall doesn’t match the title in the submission system, which doesn’t match the title that went to the website, which doesn’t match what’s in the mobile app.

The actual problem is the handoffs

Look back at those seven stages and notice that most of them work fine in isolation. Your form collects proposals. Your spreadsheet holds scores. Your sticky notes build an agenda.

Every stage ends with somebody copying data into the next container by hand, and every copy is a place where a title changes, a speaker name loses its accent, a track gets reassigned and nobody updates the website. The errors your attendees eventually see almost never originate in a stage. They originate in a handoff.

Which is why a better spreadsheet never solves it. You have to remove the places where somebody has to retype something.

What a connected process looks like

Structured submission forms do more than tidy the inbox. When submitters pick a track from a list and fill defined fields instead of writing prose into a box, you can sort, filter, and count from day one without reading a thing.

Draft saving removes most of your duplicate problem at the source, because people can come back and finish rather than starting over or resubmitting. Deadline and progress tracking means the system holds the cutoff instead of a person adjudicating it by email.

Assigning reviewers inside one system with defined scoring rubrics gets everyone on the same scale, with notes and feedback in the same place. You can see progress without asking, and report on reviewer behavior afterward, which is how you find out that one person has been scoring two points below everyone else all along.

Then approved proposals convert straight into scheduled sessions, carrying presenter, topic, and format with them. That single step removes the biggest handoff in the whole process, the one where someone re-keys every accepted talk into a schedule.

And a speaker hub replaces your chase spreadsheet. Speakers see their own sessions and tasks, upload bios, headshots, and materials themselves, and you get completion tracking that shows who’s missing what before the deadline instead of after it.

One thing to try this cycle

Before you change any software, run this check. Take ten accepted sessions from your last event and compare the title and speaker name across your submission records, your internal agenda, your website, and your app. Count the discrepancies.