Conference Abstract Management Software Problems: The 6 That Break Review and the Program Build, and How to Avoid Them

Why does abstract software get scoped as a submission form?

Because submission is the deadline everyone can see. The window opens on a fixed date, the requirement gets written around collecting files and metadata cleanly, and the review, ranking and program build are described as later phases. Those later phases are where, in the societies Digital Heroes has worked with, four to seven weeks of one senior staff member's year disappears.

The object the meeting actually runs on is much larger than a submission. It is a submission that knows its authors and their institutions, the reviewers who must not see it, the scores it received and how harsh those particular reviewers are, the decision rule that accepted it, the session it lands in, the room and slot that session occupies, the presenter who cannot be in two rooms at once, and the embargo date attached to a press release. Build the submission form first and every one of those becomes a spreadsheet.

What the first release should contain is submission plus conflict aware routing plus scoring and decisions. That is the half with an immovable external deadline, and it is also the half that produces the data everything else depends on. Sequence the session builder for the following cycle. Societies that try to ship both before one meeting usually ship neither properly.

What goes wrong when you migrate reviewer and submission history?

The reviewer roster is the obvious migration and the least valuable one. Expertise keywords are self declared, years old, and were written by people describing what they wish they reviewed rather than what they actually review well. Import them, then plan to replace them with observed behaviour: what a reviewer has actually scored, what they declined, where their scores agreed with the eventual decision.

The migration that genuinely matters is prior submissions, because that is where your conflict graph comes from. Co authorship, shared institutions and repeated collaborations are visible in three years of your own submission data and nowhere else, and most real conflicts hide there rather than in a declaration. Importing that history is what turns conflict rules from a policy into something enforceable.

The failure is name matching. The same person appears as an author with three initial formats, two institutional affiliations after a move, and a surname change. Merge those wrongly and you either block a legitimate reviewer permanently or fail to block a real conflict, and the second is the expensive direction. Use scored matching with human adjudication for the reviewer population, which is small enough to be worth doing properly, and keep author identity resolution as an ongoing queue rather than a one time exercise. Persistent researcher identifiers help where authors supply them, and a meaningful proportion will not.

The third migration decision is decisions themselves. Import prior accept and reject outcomes as a labelled archive for reference, and do not re evaluate them under new rules. A committee pick from two years ago was a committee pick, and a rules engine that reinterprets it is producing fiction.

Why do the association system and meeting app feeds break after launch?

The association management system integration breaks on identity and on timing. iMIS, Fonteva and Personify are three genuinely different integration projects, and in all three the recurring failure is that a submitter is a member in one system and a person record in the other, with no shared key, so member pricing applies to the wrong account or fails to apply at all. Agree the key before scoping, let the association system own the person record, and have the abstract platform reference rather than copy it. Where a copy is unavoidable, make the direction one way and never write back on the same field.

The meeting app feed breaks on state, and this is the failure with the sharpest consequence. Apps such as EventPilot and Whova are commonly fed by an export taken several weeks out, which means the app holds a version of the program that stops matching yours the moment a presenter withdraws. Worse, an export sent before an embargo lifts can be published on the app vendor's schedule rather than yours. Feed rather than export: one source of truth, a feed the app reads, and publication state carried on the abstract itself so nothing visible can appear before its embargo timestamp.

The print vendor is the third and it breaks on the last mile. A program that requires a human to reformat an export every time it changes will be reformatted once, and every subsequent change will be applied by hand to the document rather than to the system. From that point the printed program and the platform disagree, and nobody knows which is right.

What happens when disclosure evidence and embargo state are not covered?

If your meeting awards continuing education credit, the ACCME Standards for Integrity and Independence require you to collect financial relationships from everyone in a position to control content and to mitigate relevant relationships before the activity. That is an evidence trail, not a form. It has to attach to the person, follow them into every role they hold at the meeting, appear on the slide and in the app, and be retrievable two years later.

Most societies run this in a spreadsheet fed by an email chase, and the chase is brutal because the people least likely to answer email are the senior clinicians giving the keynotes. Built properly, disclosure is a record attached to a person with a validity window, propagating to every role automatically, blocking the program export until the mandatory ones are complete. The one place where document extraction genuinely helps is narrow: normalising the company names people paste in from their own institution's system, so the same firm does not appear under five spellings in your audit pack.

Embargo is the second uncovered gap and it is the one that damages a relationship rather than a process. If abstracts publish in a journal supplement with registered identifiers, and press releases go out under an embargo date, a single abstract visible in the app before the embargo lifts is a real problem with a journal and a sponsor. Publication state belongs on the abstract, with every consumer reading a feed that respects it, rather than depending on a staff member remembering to flip a folder to public at the right hour.

The third gap is accessibility, which societies discover when an author using a screen reader cannot complete a submission or a delegate cannot read the program. Treat it as design work on the submission and program surfaces rather than as a check at the end.

Should you build custom or configure what you already own?

If you run one meeting a year, take under roughly six hundred abstracts, use a single review round without a formal conflict policy, and build a program of under sixty sessions, buy. Ex Ordo and Oxford Abstracts are good products for exactly that, and ConfTool has genuinely capable bidding if reviewer self selection suits your culture. Cvent Abstract Management makes sense when you are already deep in Cvent for registration and housing and your review process is simple, because the integration you avoid rebuilding has real value.

Configure harder first in one specific case. A great many societies have never written their decision rules down, so they blame the tool for a ranking argument that is actually an unresolved policy question. Write down what happens after scoring: top N per track, floors for underrepresented topics, committee picks, the quality bar for demotion to poster. Sometimes the product then does the job.

Build when two or more of these hold. Your conflict policy has rules a self declaration cannot express, such as co authorship within a defined window or shared grant investigators. The session and room build takes more than three weeks of senior staff time. You award credit and assemble the disclosure trail by hand each year. You run late breaking and regular submissions under different rules, numbering and program inserts. Or your meeting revenue is large enough that a scheduling error is measured in refunded registrations rather than embarrassment.

How do hidden costs get into the quote?

Multiple meetings on one platform is the first and it sounds like reuse. It is configuration depth: different review rounds, different decision rules, different credit requirements and different program shapes, all needing to coexist without one society staffer holding the differences in their head.

The association system is the second, and a line item reading integration covers one of iMIS, Fonteva or Personify, not the category. The journal supplement pipeline with identifier registration is the third and is a publishing workflow rather than a feature.

The program builder is the fourth and the most commonly underestimated, because it is a constraint problem rather than a screen, and the constraints are yours: room capacities, presenter availability windows, sponsor contractual slots, chair assignments, track adjacency preferences and a poster hall with a fixed board count. Enumerating those is your staff's time and it sits on the critical path. Accessibility conformance is the fifth. And the sixth is support during the submission window, because two weeks of high volume author questions land on somebody, and it will be your team.

What separates a build that works from one that fails here?

Do not redesign the review process and the software in the same year. Run the first cycle with your existing decision rules encoded exactly as they are, however awkward, and change them the following year when you have data. Societies that reform both at once cannot tell which change caused which outcome, and the committee blames the software.

Make conflict rules hard constraints applied before assignment, derived from your own submission history rather than from declarations. Self reporting remains useful as a backstop, but it should be the second line of defence.

Normalise scores within reviewer and route discordance automatically. A mean of a six and a nine is not a ranking when one reviewer never exceeds seven and the other never goes below eight, and every program chair already knows this and compensates with instinct at the meeting they trust least. Send any abstract whose spread exceeds a threshold to a third reader before the ranking meeting rather than during it.

Build the program as constraints, not as a grid. The test is what happens when a presenter withdraws in week five: the system should re solve and report which sessions moved and who needs an email. If the answer is that staff edit the schedule, you have paid for a better spreadsheet.

Start the project right after a meeting closes, not in the quarter before the next window opens. The submission date is external and immovable, and a first release needs a real cycle of internal use before it takes live traffic.

Finally, settle ownership in writing before kickoff: the repository, the cloud accounts and the right to hire anyone else next year. At Digital Heroes the society owns the code from the first commit. A meeting platform you cannot move is a renewal negotiation you lose every year.