7 tips for selecting the right abstract and speaker management for your meeting
One of the most important components of my job is abstract and speaker management, because our meetings wouldn’t be anything without the invited speakers and the submitters interested in presenting their research at our meetings. There is a trick to finding the most efficient and intuitive way to collect your submitter and speaker materials while still getting everything your planning team needs. And while I think I have room to grow, here are a few things I’ve learned:
1. Revisit your contract and review any new or updated features
Revisiting your vendor contracts is important to see if you have features that you were contracted for the previous year but never used, or if there was a feature you wished you had previously. Also check with your vendor to see if there are any new features you should know about, because their technology is always being updated. Consider how these changes to your contract impact the build of your system. For example, this year we are using a feature that allows system access to volunteers so that they can schedule the abstracts into the program. And while it slightly changed the meeting timeline, this is going to be a HUGE time saver for everyone in the long run.
2. Consider the requirements and the type of people who are submitting
Do you have an extensive application where each question requires a text box with character limits, or do you have something as simple as one file upload? Do you need to have header validation in a text box because there are five criteria that a submission must respond to? Does it make sense to ask award questions on the "author information" step because the awards are author-specific or separately because it is submission-specific? Do you need skip logic that only asks certain questions dependent on speaker roles or do you need separate submission portals for each speaker type?
I don’t really have a roadmap to figure this out; I just know that this forward thinking is crucial for your submission system from start to finish. The magic lies within creating an intuitive system that asks the submitters the questions your organization or committee wants to ask, while being mindful of limitations your vendor might have.
3. Have your colleagues/committee test
I work in our abstract management systems day in and day out, so sometimes I gloss over steps that might appear confusing for submitters because I understand how the system works (and I’ve already tested it 18 times). One of our clients had pretty significant changes to their submission site this year, so I had six people in my office test the new version. This was extremely helpful because the associate director tested from the perspective of what the committee wanted, another colleague tested from the perspective of functionality, while yet another looked for spelling or grammar errors, and they collectively made the submission site better with the variety of edits and suggestions they provided.
4. Do not launch until your submission site is complete
This seems self-explanatory but in an effort to meet deadlines, we’ve made this mistake. Some systems allow you to make live edits but I’ve learned that this isn’t in our best interest. This might be my best piece of advice (next to having everyone and their brother test) for those working with a new vendor, doing a complete overhaul of the submission system, or creating a new submission process for a new meeting. In our case, we were creating a new submission system for a new meeting with a new vendor from the ground up. We realized as we went along that there were items that we would have wanted our submission site to collect and when our vendor updated the site live, it impacted those who had already submitted. It all worked out in the end but that experience now impacts how early I build and/or review the submission site before opening.
5. Build your review system in tandem with your submission system – or at least keep the review process in mind
I’ve said it once and I’ll say it again: Forward. Thinking. Even though review comes after submissions are received, it behooves you to either build the review system side-by-side or at least know your review process. Why? Because this will help you determine if there are any crucial questions your submitters need to answer during the submission process to pair them with an appropriate reviewer.
We pair submissions to reviewers based on topics or keywords and we determine those lists prior to opening the submission site and build them into the submission process. Once our submission site launches, we also promote our “Call for Reviewers” and request the reviewers to indicate which topics/keywords they feel qualified to review. This helps us prepare for when the submission site closes and automatic review assignments are made, which saves us time.
6. Keep track of withdraws outside of the system once the submission system closes.
You can track withdraws in your abstract management system and you should. However, in addition I keep an Excel document to track withdraws so that I can include a date, reason, session they were originally scheduled to, and any other information I know my colleagues and Board will want to know. This is also a helpful tool to reassign presentation dates or times because I know where there is space. But I think the biggest reason I do this is so that I can double check my work in the abstract management system, as well as in any meeting publications or mobile app.
7. Think about output: mobile app, proceedings, web apps
Unless you’ve found the unicorn vendor that does it all and does it well for your meeting, this is important because what you gather during the submission process is ideally what is used for everything after that point: mobile app, proceedings, web app, website, etc. For example, one of my vendors allows me to collect speaker information in a speaker portal after a submission is accepted, while another requires all information to be collected during the submission system and this determines how each system is built. Just keep in mind what you may want to appear in the meeting materials so that your vendor can provide thorough reports or API feeds for any other third-party vendors you may have.