Calling for abstracts without the email chaos

Almost every first conference runs its call for abstracts out of an inbox. Submissions arrive as attachments, someone maintains a spreadsheet, reviewers get forwarded copies, and the accepted list is retyped — once for the programme, once for the badges.

It works, until it does not: two versions of the same abstract, an author whose affiliation changed between submission and acceptance, a reviewer's verdict that never made it back to the sheet.

What a submission has to carry

Collect these at submission, not later:

• Title — the thing that goes in the programme.
• Presenting author, with an email that reaches them in three months.
• Institution — this ends up on the badge and the certificate.
• Co-authors — as submitted, because the author list is not yours to edit.
• Category or track — how you will sort two hundred of these.
• The abstract text, and optionally a document, for the ones with tables or figures that do not survive a plain-text box.

The single most valuable field is the email, and the most commonly wrong one is the institution — people submit from a personal address and give the department they are about to leave. Ask both, and ask again at registration.

Status is the whole workflow

An abstract is not accepted or rejected; it moves through states, and everyone involved needs to see the same one:

Submitted → Under review → Accepted (oral or poster) → or Rejected, with Withdrawn as the state an author can reach themselves.

Splitting acceptance into oral and poster matters more than it looks. It is the field the programme is built from, and if it lives only in a reviewer's head you will rebuild the schedule by hand.

Review notes belong on the abstract. Not in the reply email — on the record, where the next reviewer and the chair can both see them.

Let authors check their own status

The single biggest source of inbox traffic during a call for abstracts is "has mine been reviewed yet?"

Give each submission a reference and a private link the author can open without an account. Most submitters are not registered delegates yet, and making them create an account to see one word of status is how you generate the emails you were trying to avoid.

Deadlines are a social problem

Two practical things that have nothing to do with software:

Publish the review timeline, not just the submission deadline. Authors plan travel around acceptance, not around submission. A call that says "submissions close 15 October" and nothing else produces a month of status emails.

Expect a third of submissions in the last 48 hours. That is not a failure of your reminders; it is how deadlines work. Plan reviewer capacity for the spike rather than the average.

Carry the data forward

The point of collecting a structured submission is that nothing gets retyped:

• the accepted author becomes a speaker on the programme;
• their name, institution and role produce a badge;
• their role produces the right certificate wording — they delivered a presentation, they did not merely attend;
• and none of it required a second spreadsheet.

That is the whole argument for doing this in one place. Not that the submission form is nicer, but that the accepted author never has to be typed in again.