Abstracts in the inbox and scores in six spreadsheets
The programme committee opens the call for papers for next year's conference. Abstracts arrive by email as Word documents, PDFs and text in the body of the email. Some are over the word limit. Some forget to say which theme they are for. The events officer files them in a folder and builds a spreadsheet listing each one.
Six reviewers, all volunteer members, are sent a bundle each. They are meant to review blind, but author names are in the documents. Scores come back in their own spreadsheets, a couple late. The officer merges them by hand. At the committee meeting, there is confusion about which version of an abstract was reviewed. Afterwards, accepted speakers are emailed individually for biographies, photos and slides, and chased for weeks.
Why the call for papers is so laborious
Submission, review and programme building each happen in different tools, with the events officer copying between them.
- Submissions arrive in varied formats with missing information.
- Anonymising for blind review is done by hand, or not at all.
- Reviewers score in their own ways, which makes comparison hard.
- Conflicts of interest are handled informally.
- Decisions are sent individually by email.
- Speaker details are collected separately after acceptance.
The underlying problem is that the abstract is not a single record that moves through the stages.
What a messy call costs
The events officer spends a large part of the conference cycle on admin. Reviewers are volunteers whose goodwill matters, and a clumsy process tests it. Inconsistent scoring and weak anonymisation undermine confidence in how papers were chosen, which matters to members who submitted and were not selected.
Late speaker details delay the programme, the app and the printed materials.
How we build the abstract process
- Authors submit through a form with your themes, formats, word limits and required fields, and co-authors are added as named people.
- The abstract is stored as text, so the system can hide author names and affiliations for blind review.
- Reviewers declare conflicts, and the allocation avoids giving them papers from their own organisation or co-authors.
- Reviewers score on your criteria in a structured form, with comments to the committee and optional feedback to authors.
- Scores are combined automatically, and the committee sees a ranked list by theme, with disagreements between reviewers highlighted.
- Decisions are recorded and sent from templates, with feedback where you choose to give it.
- Accepted authors complete a speaker profile, upload slides by a deadline and are reminded if they have not, and the programme is built from accepted papers.
| Stage | What the system does |
|---|---|
| Submission | Checks word limit, theme and required fields |
| Allocation | Hides author details, avoids declared conflicts |
| Review | Structured scoring and comments |
| Decision | Ranked list for the committee, templated outcome emails |
| Programme | Speaker profiles, slides and session placement |
Scoring criteria and final decisions belong to your programme committee. The system gives them consistent, comparable information.
The call for papers afterwards
Authors submit complete abstracts because the form will not accept incomplete ones. Reviewers log in, see their allocation without author names, and score against the criteria. The committee meets with a ranked list and highlighted disagreements. Decisions go out the next day, and accepted speakers complete their profiles without being chased individually.
The programme, app and printed guide are all built from the same accepted paper records.
Does your call for papers look like this?
- Abstracts arrive by email in different formats.
- Blind review is hard to achieve in practice.
- Reviewer scores are merged from spreadsheets.
- Decisions are emailed one by one.
- Speaker biographies and slides are chased for weeks.