How an event runs, end to end

One record, end to end

Conferences don't break in the software — they break between it. A society's program passes through six stages between the call opening and the doors opening, and when each stage lives in a different tool, the gaps get bridged with spreadsheets, re-keyed data and email. That bridging is where content goes missing and deadlines slip.

Rostrum spans the whole path with a single record. A submission arrives through the call, is assigned to reviewers, scored, accepted, converted into a presentation, placed in a session, and shown on the sign outside the room — the same record the whole way. Nothing is retyped at a hand-off. Move a talk on the schedule and the room sign, the attendee app, and the speaker's own upload deadline all follow it. The span is the product: a society that begins its cycle here never hands the program off to anyone.

Twelve modules, switched on per event

Rostrum is a small catalog of products, enabled per event (Chapter 01, Chapter 05). A spring workshop that needs a schedule and file collection turns on nothing extra; a 2,000-abstract annual congress with an open call, poster hall, signage and a delegate app turns on five or six. Both run on the same platform, and the workshop never pays for machinery it will not open. Products can be switched on mid-flight — signage can be added the week of the show.

The program layer — and nothing else

Rostrum does not sell audiovisual production, onsite staffing, or registration. That is not a posture; it is a description of what the product is — and it means Rostrum can never become the reason you keep a supplier you would otherwise replace. Your AV partner is your business. Your registration system is your business. If either changes next year, the program doesn't move and the price doesn't move.

The price is published on the website, and so is this manual — you can evaluate the platform, its settings and its defaults without booking a demo. And your data is never held hostage: the program leaves in a spreadsheet the same way it can arrive in one.

Deadlines live in the venue's timezone

Every schedule time and every deadline in Rostrum is evaluated in the event venue's timezone — a midnight deadline in Vienna is midnight in Vienna, wherever the speaker or the server happens to be. Reminders go out on the intervals you choose, deduplicated to one email per person per day, and the sweep runs automatically every hour whether or not anyone is watching (Chapter 18). Chasing the eleven people who haven't uploaded stops being somebody's late-night job.

Most participants never see a password

Late speaker content has one cause above all others: a login nobody remembers. So for the people around the program, Rostrum doesn't ask for one. Speakers upload through a personal link; reviewers and attendees sign in with a short code sent to their email (Chapter 03). The program committee stops chasing passwords, and the people who touch a conference once a year have nothing to learn.

An assistant that proposes — never acts alone

Athena, the built-in assistant, answers questions grounded in this documentation and drafts the genuinely tedious work — a complete program from a plain-language description, session groupings from a pile of unplaced talks, event setup pre-filled from your website (Chapter 24). Everything is a proposal you review before anything is created; it reads titles and abstracts, never author identities; and when it is off, the platform simply works as it always did.

Organizations own events

An organization is the society, association or company that runs meetings. Everything else hangs beneath it: its people, its venues, its contact book, its email templates, and its events.

An event is a single meeting — a congress, a workshop, a webinar. Inside it live tracks, sessions, presentations, posters, speakers and files. Almost every screen in Rostrum is scoped to one event, and permission to work on one event grants nothing on another.

Capabilities are products you turn on

Rostrum is not one monolithic feature set. It is a small catalog of products, switched on per event. An event that only needs a schedule and file collection turns on nothing extra. A scientific congress with an open call, poster hall, digital signage and a delegate app turns on five or six.

This is the single most important thing to understand about the platform, and the reason this guide is organized the way it is:

Turning a product off hides its tab, its settings and its participant-facing pages. The data stays; nothing is deleted. You can switch products on mid-flight — a call for abstracts can be added to an event that already has a venue and dates, and signage can be added the week of the show.

It is tempting to ask "does my program come from a call for abstracts, or do I already have it?" — but that collapses two separate questions, and collapsing them is how people end up assuming Rostrum is only for the first case.

The two questions are:

• Where do the talks come from? A call for abstracts you run, a file you already hold, or your own committee typing them in.
• Where does the schedule get built? Which sessions exist, in which rooms, at what times, containing which talks.

Rostrum answers the second one in every case. A meeting with an entirely invited program and no abstracts at all still has tracks to define, rooms to fill, sessions to lay out and a running order to settle — and that work belongs here, not in a spreadsheet you later import.

Time is always venue time

Every date and time you see or type in Rostrum is wall-clock time at the event's main venue — never your browser's local time, and never the reader's. A session at 09:00 in Vienna reads 09:00 to a manager in Chicago.

This has one practical consequence during setup: the main venue must have a timezone recorded before you can import a schedule, and reminder emails are scheduled against venue hours. Pick the venue early.

Staff see the event dashboard

Managers, coordinators and committee staff sign in and land on a list of their events. Opening one gives the event dashboard: a left-hand rail of tabs — Overview, Sessions, Presentations, Speakers, Agenda, Team, Products, and one tab for each product you have switched on.

Which tabs a person sees depends on their permissions and on which products are enabled. A coordinator with no signage permission never sees the Beacon tab even when Beacon is on; nobody sees it when Beacon is off.

Participants see the hub

Submitters, speakers, poster authors and reviewers sign in and land on the participant hub instead. It shows what they personally owe the event: a to-do list with deadlines, a card per event they are involved in, and a record of what has been emailed to them.

The hub is built from ownership, not permission. You appear there because you hold a draft, a presentation, a poster or a review assignment — not because someone granted you access to a screen.

Attendees see the Attendee App

Delegates are a third group again, and they never touch either of the above. They get the mobile web app at the event's own address. See Chapter 19.

Staff sign-in

Email and password, with a Forgot your password? link on the sign-in page. Reset links last one hour and can be used once; using one signs the account out everywhere.

There is no public sign-up. Staff accounts are created by an administrator, who sets the password directly.

Magic links for speakers and reviewers

From the Faculty tab you can send a participant a magic link — a one-click sign-in that needs no password. It is deliberately narrow:

• It grants access to that one event and nothing else. Even an administrator who clicks one gets an event-scoped session.
• It expires at the end of the event's last day, in venue time.
• It cannot be used to set or change a password.

This makes it safe to send to a speaker who will never sign in again — they click, they upload, they are done.

Codes for participants and delegates

Submitters, authors and reviewers sign in to the hub by entering their email address and receiving a six-digit code. Delegates do the same in the Attendee App. In both cases, an account is created automatically on first use — participants never register, and never have a password to forget.

For the Attendee App you can decide whether anyone with an email address may sign in, or only addresses on a list you upload.

Organization manager  Creating events is an organization-level action. Event managers run events; they do not create them.

Two ways in

The Events page offers two create buttons. Create Event is the classic form — every field at once, described below. Create with Wizard opens the guided setup: a short interview that asks one question at a time, skips whatever cannot apply to your answers, and ends with a plan you confirm before anything is created. Both paths produce the same kind of event; the wizard simply carries you further before you land in the dashboard.

What the form asks for

What you configure afterwards

Everything else. Branding (logo and banner), the status as the event progresses, satellite venues, tracks, rooms, the team, and — the subject of the next chapter — which products you are using.

Rooms and venues

A venue is a building; a room is a space inside it. Rooms belong to the organization, so they are reusable across that society's events, and each event can give a room a display name of its own — Hall 2 can appear as Hall 2 — sponsored by Acme for one meeting without renaming it everywhere.

Rooms matter more than they first appear: the agenda grid is laid out as rooms against time, signage is addressed per room, and Open Mic issues its moderator links per room.

Guided setup: the interview

The guided path asks its questions one at a time, and the tree is deliberate: answer no to collecting posters and it never asks about the Poster Viewer; skip the venue and it never asks about rooms. Every question can be skipped and finished later — the interview's job is momentum, not completeness.

Its opening question is the most useful one: "Do you have an event website I can look at?" Give it your event's public site and Rostrum reads the page and pre-fills what it finds — the event name, the dates, the venue, the topic areas, and whether the site mentions collecting submissions. Everything it reads arrives as a suggestion you confirm, never as a silent fill; and if the named venue already exists in your venue catalog, it is selected for you with a note saying so. This question only appears when AI assistance is enabled for your organization — see Chapter 24; without it, the interview simply starts at the event name.

The interview ends at a setup plan — name, dates, venue, rooms to create, and the modules to enable, all on one screen. Nothing exists until you confirm it. On confirmation the event is created and you land in the setup wizard to finish.

The setup wizard

The wizard walks a new draft event through five steps — Basics, Venue, Branding, Products, Review — with a rail that shows what is done, what is skippable, and what launch still needs. It is a guide, not a second set of forms: each step writes through the same settings the dashboard uses, so anything you do in the wizard holds if you abandon it, and anything you configure elsewhere is reflected when you come back. A draft event with an unfinished wizard shows a resume banner on its dashboard.

The final step launches the event — Draft becomes Published in one reviewed action. Required steps must be complete first; the optional ones can be skipped and revisited any time before or after launch.

Building the team

The Team tab lists everyone with a role on this event and lets you add more — an event manager, a read-only observer, or a person you want on the roster ahead of time. Adding somebody who has never used Rostrum creates their account as part of the same step.

Remember from Chapter 02 that most participants never need to be added here. Speakers, authors and reviewers acquire their access automatically.

Products are offered to your organization first — your agreement determines the catalog available to you — and then switched on per event. Switching one on reveals its tab and its settings. Switching it off hides them again without deleting anything.

You can configure a product when you enable it or come back later; almost every setting is editable while the event is running.

Where each one is configured

Most products open their settings in a side panel from the Products tab. Three send you elsewhere, because their settings belong with their working screens:

• Call for Abstracts — settings live on the Abstracts tab, as its first sub-tab.
• Review & Approval — settings live in the Review Center.
• Beacon — the real configuration is per screen template, on the Beacon tab.

The three viewers configure from their side panels too, but their look comes from templates: your organization keeps a library of gallery templates, and each event publishes one instance from a template with per-event overrides. A template can also be scoped to a single event, and promoted to the library when it earns reuse.

One opening date and one closing date, both in venue time. Outside the window nobody can submit; drafts can still be worked on but not sent.

A grace period in minutes can be allowed after the close, which absorbs the usual flood of last-minute submissions without you having to sit and move the deadline by hand.

This is the single most consequential setting on the page, and it defaults to the safer of the two.

What a submission consists of

You define the shape of an abstract yourself:

• Sections — one or more named text blocks, each with an optional word limit. A simple call has one section called Abstract with a 300-word limit. A structured clinical call might have Background, Methods, Results and Conclusion, each limited separately.
• Presentation types — whether submitters may ask for an oral slot, a poster, or express no preference.
• Tracks — which of the event's tracks a submitter may file under. Tracks drive reviewer expertise, scoring comparability and capacity targets, so define them before the call opens.
• Submission limit — how many abstracts one person may submit.
• A submitter questionnaire — optional extra questions asked at submission time (funding, ethics approval, presenting-author status). Answers are visible to staff only, never to reviewers.

Whether submitters may edit after sending

Off by default. When it is on, a submitted abstract stays editable until the window closes — convenient, but see the warning under review assignment in Chapter 09: the first reviewer assignment locks an abstract regardless of this setting.

Review settings

• Blind review — hides author names, affiliations and the submitter's identity from reviewers. Disclosures are hidden too. It holds in the reviewer's email as well as on screen.
• Reviewers per submission — one to five. Used as the target when auto-assigning.
• Scoring questionnaire — the form reviewers fill in. You can set one for the whole event, and override it per track. Build it from scratch, or start from one of your organization's saved templates — see Chapter 16.
• Assign reviewers automatically on submit — off by default. When on, each incoming abstract is immediately distributed to the least-loaded qualified reviewers.

Capacity targets

Per track, you can record how many oral slots and poster slots you expect to fill. These are shown against your running acceptance count on the selection board as guidance. They are advisory — Rostrum will not stop you exceeding them.

Supporting files

Off by default. Switch it on and submitters can attach figures, tables or supplementary data to an abstract. You set how many files (three by default), how large each may be (10 MB), and which types are accepted — images and PDF by default, with Office documents and MP4 video also available.

One setting here is easy to miss and matters a great deal on a blind call: files under blind review. Files can carry identifying content that the abstract text does not, so you choose whether reviewers see them at all.

Revision rounds

The committee can send an abstract back once, asking for changes rather than accepting or rejecting it. Two settings govern it: how long submitters get to revise (14 days by default, overridable per batch), and who re-reviews the resubmission — the same reviewers, reset to pending with their earlier answers kept as a starting point, or fresh reviewers you assign by hand.

One round is the maximum. After a revision has been requested, the next decision on that abstract must be final; Rostrum refuses a second request.

Session proposals

Off by default. When on, a chair can propose a whole session rather than a single abstract — a set of linked talks, each with its own title, abstract and speakers. You choose which formats to offer (coordinated papers, roundtable, panel, workshop), how many talks a session must contain (three to four by default), and a word limit per talk abstract (300).

Submitters choose which kind of thing they are submitting at the moment they start, and the choice is fixed from there.

The public submission link

Only relevant on an open call. Generating a public link gives you a shareable web address anyone can use to reach the call without an invitation — see Chapter 07.

Deadline reminders

One switch governs all three of the call's automatic nags: the deadline reminder to invitees and draft-holders, the reminder to reviewers with outstanding scores, and the reminder to accepted submitters who have not yet confirmed. You choose the days-before schedule and the hour of day, in venue time.

Note what is not on that list: there is no automatic reminder for an overdue revision. See Chapter 11.

The contact book

Invitations are sent to contacts — people your organization emails who are not necessarily Rostrum users. The contact book lives at organization level, so a society's membership list is built once and reused for every call it runs.

Contacts can be organized into named lists (past presenters, members, a specialist interest group) and imported from a spreadsheet. When you compose an invitation you pick one or more lists, paste additional addresses directly, or both.

What the recipient gets

An email with a personal link. What happens when they click it depends on who they are:

• Most people are signed straight in — one click, no password, no code — and land in the participant hub ready to start a draft.
• Anyone who already holds management rights over that event is instead asked for an emailed code. This is deliberate: a one-click link in an inbox should never be able to open a staff account.

The link works repeatedly until the submission window closes, so a recipient can come back to it. Every send is tracked — you can see who was invited, when it was last sent, whether it was opened, and whether it was accepted.

Managing the invitation list

From the invitations panel you can resend to individuals, add late invitees at any time, and revoke an invitation — which immediately stops that address from submitting on an invite-only call.

The other route in — a public link

Invitations are how a closed call works. An open call has a second route: a public submission link you generate on the Abstracts settings screen and put wherever you like — a society newsletter, a conference website, social media.

The link leads to a landing page showing the event name, whether submissions are open, the formats you accept, and the sections an abstract will need. There is a single button, and it does not ask anyone to register: the visitor enters an email address, receives a six-digit code, and lands in the hub ready to draft.

The address itself is a long random token rather than anything guessable, so the page cannot be found by trying event names.

When the submission window closes the link keeps working, but the page says submissions are closed and the button disappears — which is usually better than a dead link for anyone arriving late.

Unsubscribes

Every invitation and deadline reminder carries an unsubscribe link. Unsubscribing suppresses that address from all bulk mail from your organization, on every list and every event. It is honored immediately and mid-campaign.

Where they work

Submitters live in the participant hub. Their event card lists every abstract they hold, its status, the deadline counting down in venue time, and — later — the decision. There is no separate submission website to remember; the same address serves drafting, confirming and, if they are also a reviewer, reviewing.

The form

Four steps, saved as a draft continuously and on every step change. A submitter can leave and come back as often as they like.

If you configured a submitter questionnaire, it appears as an extra step before the final review.

Session proposals are a different shape

Where you have enabled them, the submitter first chooses whether they are submitting an individual abstract or a session proposal. The choice is fixed once made.

A proposal is submitted by the chair and describes a whole session: a title, a format, a description of why these talks belong together, and then the talks themselves. Each talk is a full abstract in miniature — its own title, its own abstract text within your word limit, and its own author list with one presenting author and disclosures for everyone. The chair completes their own disclosure at the session level; the talk speakers complete theirs on their own talks.

The configured abstract sections do not apply to a proposal, and neither does the preferred-format question. The talks are the content.

What is checked at submission

• Every configured section is present, non-empty and within its word limit.
• The preferred type is one you allow, and the track is one you opened.
• Exactly one presenting author.
• Every author's disclosure is complete.
• Required questionnaire answers are answered.
• The window is open — or within the grace period.
• The submitter is under their submission limit, and on an invite-only call, invited.

On success they receive an immediate confirmation email.

Changing or withdrawing

• A draft can be edited or deleted freely while the window is open.
• A submitted abstract can be edited only if you enabled editing after submission — and only until a reviewer is assigned, which locks it permanently.
• An abstract sent back for revision becomes editable again, whatever the lock and whether or not the window has closed. See below.
• A submitter can withdraw at any point, including after the window closes and including mid-revision. Withdrawal is available right up until a decision has been sent; a waitlisted submitter keeps the option.

Revising and resubmitting

When the committee asks for changes, the submitter's dashboard says so, shows the deadline, and offers an Edit & Resubmit button. The wizard reopens with a banner, the final button reads Resubmit, and the same completeness checks run again. Files can be changed too — text and attachments unlock and lock together.

The revision deadline replaces the submission window for that abstract, so a revision can legitimately arrive after the call has closed. Once the deadline passes the abstract locks again and the note changes to say the committee will decide on the version it has.

Their to-do list

The hub surfaces the things a submitter owes you, with the deadline attached and overdue items called out. For an abstract submitter that is: finish the disclosures, submit before the deadline, revise and resubmit if the committee asks, and later, confirm your acceptance.

Building the reviewer pool

Add people to the event's reviewer pool from the Abstracts tab. Being in the pool is bookkeeping only — it grants nothing and sends nothing. Reviewers become reviewers when work is assigned to them.

Tag each reviewer with the tracks they are qualified for. Tags are what make automatic assignment sensible: a cardiology abstract goes to reviewers tagged for cardiology before it goes to anyone else.

Three ways to assign

Conflicts of interest

A reviewer who opens an abstract and recognizes a conflict declares it with a reason. This:

• marks the review as conflicted and clears any partial answers;
• keeps the record as an audit trail — you can see who declared what, and why;
• permanently excludes that pairing. The abstract will never be offered back to that reviewer, by any assignment mode.

Your progress view shows conflicts as gaps to fill, so you can top up the missing coverage.

The reviewer's experience

Reviewer A reviewer signs in to the hub with an emailed code and sees a queue of everything awaiting them across every event. Abstract reviews are scored inline, without leaving the queue.

Each review asks for two things:

• The scoring questionnaire — the rating scales and questions you configured.
• A recommendation — Oral, Poster or Reject on an individual abstract; simply Accept or Reject on a session proposal, where the format is the chair's proposition rather than the reviewer's. This sits outside the questionnaire and is always required, so every completed review carries a clear verdict even when the questionnaire is all free text.

They may also write comments to the author, which you can choose to forward with the decision, and committee notes, which never leave staff under any circumstances.

Reviewing a session proposal shows the session description and then each talk in turn with its own authors, judged as one unit. Where supporting files are allowed and permitted under your blind setting, they appear alongside the abstract for reading and download.

Reviewing a resubmission

While an abstract is out for revision it leaves the reviewer queue entirely — nobody is asked to score a version that is being rewritten, and its files are unavailable in the interim. When it comes back, the reviewers you chose get it again, and the scoring screen marks which sections changed and offers the previous version alongside.

If you kept the same reviewers, their earlier answers and comments are still there as a starting point rather than a blank form.

Keeping reviewers moving

Assignments carry a deadline. Rostrum emails reviewers when work is assigned and again as the deadline approaches, on the schedule you set. The progress and workload views show who has finished, who has not started, and how the load is distributed — useful before you assign another hundred abstracts to the same three people.

The board is grouped by track

Abstracts are presented track by track and ranked within each track, highest normalized score first, unscored items last. There is no single all-tracks league table, and this is deliberate: when tracks can use different scoring questionnaires, a 78% in one track and a 78% in another are not the same quantity.

Each track shows your acceptance count against the capacity targets you set, so you can see when a track is full without being prevented from going over.

What the board flags for you

• Split votes — where completed reviews reach no majority recommendation. These are the ones that need a human conversation, and they are marked so you can find them without reading everything.
• Undecided — nothing staged yet.
• Coverage — abstracts still short of their reviewer target.
• Every statistic across the top doubles as a filter: click "Waitlist" to see only waitlisted items, click it again to clear.

The decisions

Which options a row offers depends on what was submitted. An individual abstract can be accepted as an oral, a poster or a paper on demand; a session proposal is accepted as a session, because its format is the chair's proposition rather than the committee's choice. The rest apply to both.

Rescuing a talk from a rejected proposal

A session proposal is judged as a unit, but committees frequently want one talk out of a session they are otherwise declining. Where a proposal is staged as rejected or waitlisted, each talk carries an Extract to pool action that lifts it out as a new individual abstract — its title, its abstract text, and its full author list intact — landing in the general pool as submitted and undecided, to be judged like any other.

This is deliberately a salvage path: an accepted proposal cannot be split, and each talk can only be extracted once.

Deciding in bulk

Per track, you can accept the top N — set a number, see exactly which abstracts that will affect in a live preview, and be warned if it would overwrite decisions already staged. The bulk action always operates on the whole track group as ranked, not on whatever filter you happen to be looking at, so a filtered view cannot mislead you into deciding the wrong set.

The abstract book

From the same screen you can export an abstract book — the proceedings document societies print, publish or circulate to delegates. It comes as a typeset PDF with a cover, a contents page, one section per group, and an index of presenting authors; or as a spreadsheet if you would rather work with the data.

You choose whether to include everything accepted or only those who have confirmed, whether to group by track or by presentation type, and whether to print keywords, session and board placement, and author disclosures.

Sending a batch

Choose a decision type — accepted oral, accepted poster, accepted paper on demand, accepted as session, revisions requested, waitlisted or rejected — and send to everyone currently holding that staged decision who has not already been told. Each type has its own email template, which you can customize for the event or for the whole organization.

Options at send time, which change with the type you chose:

• Include reviewer comments. The comments-to-author from completed reviews, attached unattributed. Committee notes are never included. Off by default — except on a revisions-requested batch, where it defaults on, because the feedback is the request.
• Confirmation deadline. Acceptances only — the date by which the submitter must confirm they will present.
• Revision deadline. Revisions-requested batches only — the date by which the revised abstract must be back. Leave it blank to use the event default of fourteen days.

How a submitter confirms

The email does not contain accept and decline buttons. It contains a link to the hub, and the submitter signs in to answer. This is intentional: a one-click "decline" sitting in a forwarded inbox is a liability, and an authenticated answer is a defensible record of who accepted what.

They confirm or decline; unanswered acceptances become overdue once the deadline passes. Rostrum reminds them automatically in the days before the deadline.

Asking for revisions

Sending a revisions-requested batch does more than deliver a message: it reopens the abstract. The submitter can edit and resubmit until the deadline, whatever the review lock said and whether or not the submission window has closed. Rostrum keeps a copy of the version you sent back, so reviewers can see exactly what changed when it returns.

What happens to the existing reviews depends on the setting you chose in Chapter 06 — the same reviewers get it again with their earlier answers intact, or you assign fresh ones and the originals cannot be re-added.

Promoting from the waitlist

There is no automatic promotion. When a slot frees up, stage the new decision — Accept oral, say — over the waitlist decision the submitter already received, and send the acceptance batch. Rostrum treats any abstract whose staged decision differs from the one last sent as needing to be told again, so promotions naturally appear in the next batch.

Re-notifying resets their answer: a promoted submitter is asked to confirm the new outcome.

What conversion produces

• Accepted oral becomes a presentation in draft, not yet scheduled into a session. The presenting author becomes its speaker; other authors become co-presenters.
• Accepted poster becomes a poster in draft, carrying its track across. The presenting author becomes the primary author.
• Accepted paper on demand becomes an on-demand paper in draft, carrying its track across. The presenting author becomes the primary author, and every author gets upload access — any of them may supply the video.
• Accepted session proposal becomes a session — unscheduled, chaired by the proposer, carrying the session description — containing one presentation per talk, in the order the chair arranged them. Each talk's presenting author becomes that presentation's speaker and the rest become co-presenters.

The abstract's sections are flattened into the new item's abstract text, keeping the section headings, so the accepted text travels with the item.

Any supporting files attached to the submission travel too, as a file group called "Abstract Materials" on the new item. They are kept separate from the presented file, so a figure submitted with an abstract can never be mistaken for the poster itself.

Everyone named as an author gets an account if they did not have one, and the appropriate role. From that moment they appear in their own participant hub with the next thing they owe you — usually uploading a file.

Who can be converted

An abstract is eligible when all of these hold:

• It is submitted, not withdrawn.
• Its decision is an acceptance.
• That decision has actually been sent to the submitter, and the staged decision still matches what was sent.
• The submitter has not declined.

Notably, a submitter who has not yet confirmed can still be converted. Confirmation is a soft gate — you are warned, not blocked — because programs frequently have to be built before every last acceptance has been answered.

Converting is a one-way door

Once converted, an abstract's decision is locked and the submitter can no longer decline it — they are in the program. The link between the abstract and the presentation, poster or paper it became is permanent and unique, so the same abstract can never be converted twice, even by two people clicking at the same time.

What happens next

Converted items are ordinary program content from here on. Schedule the presentations into sessions, give posters their board numbers, and let the file collection, review and delivery products in the following chapters do their work. Nothing downstream knows or cares that the content arrived through a call for abstracts.

Import is not a product; it is part of every event. Find it on the Imports tab, which also keeps the history of every import you have run.

There is no template to download

This surprises people, and it is a feature. Rostrum reads whatever column headings your spreadsheet already uses and proposes a mapping — Session Title, Session Name and Track Session all map to the same field without you renaming anything. You confirm or correct its guesses in step four.

Accepted formats are .xlsx, .xls and .csv, up to 50 MB.

Two kinds of import

• Agenda — sessions, their presentations, and the speakers who give them. Rooms are created automatically from the room names in your file.
• Posters — posters and their authors.

Delegate lists and contact books are imported separately, from the Attendee App tab and the organization contact book respectively.

Your progress is saved continuously. If you leave halfway through mapping a 4,000-row file, the Imports tab offers to resume exactly where you stopped.

Session types are Keynote, Presentation, Workshop, Panel, Break, Networking and Exhibition. Presentation types are Oral, Poster, Keynote, Panel, Workshop, Lightning, Demo and Case Study.

If a presentation carries no times of its own it inherits its session's date, and the session is treated as ordered rather than timed — presentations run in sequence within the slot instead of each having a clock time. Supply presentation times and it becomes a timed session automatically.

Errors and warnings are different

Both are shown in the preview grid before anything is written, and again in the log afterwards. From the import history you can download three spreadsheets: the file as processed, the rows that were skipped, and the rows that errored — so a colleague can fix them and you can re-import just those.

Undoing an import

Every import can be rolled back. Rollback deletes what that import created — the sessions, presentations, posters, rooms and user accounts it made — in the correct order.

What the import quietly does for you

• Creates accounts for speakers who have none, and grants them the Speaker role on their presentation — so they can be sent a magic link and upload their file the same afternoon.
• Creates rooms it has not seen before, on the main venue.
• Matches people by email address, so the same speaker across twelve rows is one person.
• Converts every date and time from venue wall-clock into the correct underlying instant.

The building blocks

Starting from nothing

A meeting with an entirely invited program — no call for abstracts, nothing to import — starts here, and the order of operations is worth stating plainly because it is not obvious:

Timed or ordered sessions

Each session declares how its presentations are arranged:

• Timed — each presentation has its own clock time. Use for parallel sessions where delegates room-hop between talks.
• Ordered — presentations simply run in sequence within the session's block. Use for panels, symposia and anything where the internal timing is the chair's business.

The choice matters more than it looks, because it decides whether a talk carries a clock time at all. An ordered session holds a running order; a timed session holds a timetable.

The Session Builder

Laying out a four-day, six-room program one session at a time is the most tedious hour in conference planning, and it is arithmetic rather than judgement: given the days, the rooms and how long a session runs, the grid is largely determined. The Session Builder does that arithmetic.

You reach it from a Build sessions button on the Agenda toolbar, or from the prompt on an event that has no sessions yet. It asks a short, fixed set of questions:

1. Which days, and what hours each day

   Defaulted from the event's dates, in venue time.

2. Which rooms are hosting

   Picked from the venue's rooms. How many you pick is how many sessions run in parallel.

3. Schedule by track?

   Offered only if the event has tracks, with the option of giving a track its own room.

4. How long a session runs

   An hour by default. The number of sessions per day follows from the daily window once the fixed blocks are taken out.

5. How long a presentation gets

   Per presentation type, plus a buffer for questions and changeover. This is what produces the times inside a timed session, and what tells you when a session is over-full.

6. Timed or ordered

   For the sessions about to be generated. Ordered unless you choose otherwise.

7. Fixed blocks

   The things that must be reserved before anything else can be placed: lunch, refreshment breaks, a daily keynote. Each gets a name and a time range, and they are created as sessions in their own right.

Then it shows you the grid it is proposing, before anything is created. Rename a session, remove one, and commit when it looks right — at which point the whole layout is created in one action.

What it does and does not do

• The sessions come out empty. The builder makes the skeleton; the talks are placed afterwards. It is deliberately not trying to guess which presentation belongs in which session.
• Names are generic and editable — "[Track] — Session 2" where you have tracks, otherwise "Session 1A", "Session 1B" by day and room. Rename them inline afterwards, as you always could.
• It adds; it never overwrites. Running it on an event that already has sessions will not touch them. It checks for room clashes against what is already there and tells you which sessions collide rather than quietly double-booking a room.
• It is not a gap-filler. It generates the layout you described; it does not inspect a half-built agenda and infer what is missing.
• It needs permission to manage sessions on the event, like every other change here.

Filling the sessions: the placement tray

The agenda carries a tray down its side with two tabs. Presentations lists every talk not yet placed — drag one onto a session block to place it, or use fill by track to distribute abstract-derived talks into the matching track's sessions, with a preview before anything is written. Sessions lists sessions that are not fully placed — missing a time, a room, or both — and they drag onto the grid the same way, landing where you drop them with a confirmation first. The Presentations tab also works for any size of program from the Presentations tab itself: assign a presentation to a session and set its order or time there.

The agenda grid

The Agenda tab lays the day out as rooms down the side, time across the top, one day at a time, with sessions as colored blocks. It is the fastest way to see a clash, a gap, or an overloaded room. An event with no rooms yet is not a dead end: the empty agenda offers to add rooms on the spot and points at the Session Builder, and an empty day always shows every room so there is something to drop onto.

Drag a session to move it — to another room, another time, or both. Rostrum then asks you to confirm, showing the old and new room and the old and new time, and offering to snap to the hour, the half hour, or leave it exactly where you dropped it. Nothing moves until you confirm, so a mis-drag costs nothing.

Drag a session's edge to change its start or end without moving it. The live preview works in five-minute steps; the confirmation offers the same snap choices as a move. For a timed session whose start moved, Rostrum asks what to do with the talks inside — shift them with the session, or leave their clock times alone — and warns when leaving them alone would strand a talk outside the session's new window. Presentation lengths are never scaled: a thirty-minute talk stays thirty minutes whatever happens to its session.

Edit the running order inside a timed session from its details drawer: Edit timeline opens a one-lane editor where the session's talks sit back-to-back in order. Drag a talk to reorder, type a new length in minutes, or use the bulk tools — distribute evenly across the session window, or apply default lengths from your agenda settings. Everything is local until you save, and talks pushed past the session's end are flagged rather than silently truncated.

Filter by track to untangle a busy day, and open the grid full-screen for planning meetings.

Making the program public

There is no single "publish" button, and that is deliberate — visibility is layered so you can expose part of a program while the rest is still moving:

• The event status moves Draft → Published → Live → Completed.
• Individual sessions and presentations each have a visibility switch, which controls whether they appear on signage and in the app.
• The Attendee App only serves an event that has the product enabled and a web address set.
• Posters have their own draft, published and withdrawn states, plus their own viewer window.

A practical consequence: you can put the whole skeleton in weeks early, keep the unconfirmed sessions hidden, and reveal them individually as speakers are confirmed.

Running late on the day

A session can be marked as running late by a number of minutes. This is picked up by digital signage, so the screens outside the room show the adjusted time without anyone editing the program itself.

What you configure

The speaker's experience

Speaker A speaker either signs in to the hub with an emailed code, or clicks a magic link you sent them and skips signing in entirely. Their to-do list says which presentation is waiting for a file and when it is due, with overdue items marked. They upload, and receive a confirmation email a couple of minutes later.

Co-presenters can be given file-editing rights individually, so a professor can nominate their fellow to do the uploading.

Files are versioned — a re-upload does not destroy what was there before.

Chasing the stragglers

Reminders run automatically on your schedule, once per person per day, and stop when the event is over or the file arrives. For everything else there is the Send email wizard, which can target speakers directly with a file request, and the magic link, which removes the "I can't log in" excuse entirely.

Use this where the slides themselves must be checked before they are shown — accredited education, regulated therapeutic areas, sponsor compliance, or simply a scientific committee that wants sight of the decks.

How it differs from abstract review

The two coexist happily. A congress can review abstracts in the spring to build its program and review the resulting slide decks in the autumn, with the same or entirely different reviewers.

The workflow

• Assign reviewers, individually or as a review team, at whatever level suits — an entire track to one panel, a single sensitive presentation to a named expert.
• Reviewers are notified when a file is uploaded against something assigned to them, so they review current material rather than an empty placeholder.
• They record an outcome, with feedback for the speaker.
• On revision requested, the speaker is emailed, sees the request in their hub, uploads a new version, and a new round opens.
• On approved with changes, the speaker is asked to acknowledge the changes, and you are told when they do.

Settings worth knowing

• Exemptions — a whole track, a session or a single presentation can be marked exempt. Use it for keynotes and anything a committee has already cleared.
• Blind review — hides speaker identity from reviewers.
• Lock after approval — prevents a speaker replacing an approved file with something unreviewed. Recommended wherever review is a compliance requirement rather than a courtesy.
• Reviewer decline — reviewers may decline individual items, or the entire event; a manager can clear an event-level decline.
• Automatic reassignment — off by default. When on, an assignment untouched for N days is moved to another reviewer, and both the original reviewer and the managers are told.
• Reminders and overdue notices — the same shape as upload reminders, plus an optional daily digest to managers of what is late.
• Speaker withdrawal — whether a speaker may withdraw their own presentation, and whether they must give a reason.

One questionnaire system, four uses

Questionnaires are not specific to content review. The same builder produces every scored or structured form in Rostrum, and each one is typed by what it is for:

• Content review — what reviewers answer about a presentation (this chapter).
• Abstract scoring — what reviewers answer about a submission (Chapter 09).
• Submitter questions — extra questions asked at abstract submission (Chapter 06).
• Session feedback — what delegates answer about a session (Chapter 21).

An event's questionnaires are gathered on their own Questionnaires tab, so you can see and manage all of them in one place rather than hunting through the product that uses each one.

The organization template library

Above the event sits a library of reusable templates belonging to your organization. Build a scoring form once — your society's standard six criteria — save it as a template, and start from it on every event afterwards. Rostrum also ships read-only starter templates for abstract scoring, submitter questions, content review and session feedback, which you can duplicate and adapt.

Templates are copied, never linked. Starting from a template gives an event its own independent questionnaire, so editing it never disturbs the template or any other event that used it. That is deliberate: a live event's scoring form should never change because someone tidied up the library.

Seeing where you stand

The Review Center's control center lists every presentation with its review state, who holds it, and how long it has been there. Reports summarize progress by track, session and reviewer, and export for the committee meeting.

Where posters come from

• Converted from accepted abstracts (Chapter 12).
• Imported from a spreadsheet (Chapter 13).
• Created by hand.

What you set up

Board numbers and poster sessions

Posters carry a board number and a location, and can be attached to a session of type Poster so they appear in the program at a particular time. Digital signage has a dedicated poster-session screen that lists what is on which board.

The author's experience

Poster author Authors work in the hub exactly as speakers do. Their to-do list carries upload, revision and unanswered-question items, each with its deadline.

Papers on Demand — the third content line

On-demand papers run exactly the way posters do, with a video where the poster file would be. They arrive the same three ways — converted from acceptances (the committee's accepted — paper on demand decision), or created by hand — carry authors with one marked primary, and collect their upload against their own window. Two differences matter: every author may upload, not only the primary; and the primary file is strictly a video (MP4, MOV or WebM), with its own size cap set on the module, separate from the Internet Uploads limit.

Paper authors work in the hub like everyone else: an upload to-do until the video is in, then nothing. There is no review step for papers — quality control happened upstream, in the call.

Publishing: the three galleries

What the outside world sees of abstracts, posters and papers is decided by the three viewer modules — Abstract Viewer, Poster Viewer and Paper Viewer. Each one publishes a branded, searchable gallery from a template: your organization keeps a template library, an event publishes one live instance with its own header, dates and overrides, and a template can be scoped to a single event and promoted later. Each gallery has its own viewing window and its own public-versus-attendees decision, entirely separate from upload windows.

The galleries show only what is genuinely ready: communicated acceptances in the abstract collection, published file-carrying posters (approved ones, while review is on), and published papers with a ready video. Where an abstract became a talk, a poster or a paper, its gallery entry links through, and the destination links back. The full settings for all three live in the companion catalog.

Three kinds of email

Customizing the wording

Rostrum ships sensible default wording for every automatic email. On the Communications tab, the Automated list shows all of them, grouped by who receives them — speaker, poster author, abstracts, reviewer, manager — and lets you customize any of them for this event, or set an organization-wide default that every future event inherits. Each one can be reverted, and a test copy sent to yourself.

Merge fields put the person's name, the event, the deadline and the relevant link into the text.

Composing your own

The Send email wizard targets an audience — speakers, poster authors — and sends either a free-form message or one of the templates that makes sense to send by hand, such as a file request or a review reminder. Abstract invitations have their own dedicated panel because they do more than send mail: they confer eligibility.

The to-do list

Email is unreliable; a to-do list is not. Every participant's hub carries a list of what they owe, assembled fresh each time they look:

Each item carries its deadline in venue time and is marked overdue or due-soon. Clicking it goes straight to the thing that needs doing.

What people can see of their own mail

Participants get a notifications panel listing what has been sent to them — subject and date only. Staff have an inbox on the event overview showing messages addressed to them, with unread counts, and a preferences dialog for switching reminder categories off.

Knowing whether mail landed

Every message's send status is recorded per recipient. When the email provider's delivery webhook is configured, Rostrum also learns whether each message was delivered, opened or clicked, and those outcomes feed the Email panel in analytics (Chapter 23) — campaigns, invitations, decisions and automated mail each on their own line. Without the webhook, sending works exactly the same; you just see sent rather than read.

Setting it up

Enable the product, then set the event's web address — a short slug that gives your event its own URL. The Attendee App tab shows the finished address and a QR code to put on badges, signage and the program book.

What a delegate can do

• Browse the agenda by day, and open any session or presentation.
• Search across the program — sessions, faculty, abstracts and papers.
• Browse the faculty and their profiles, each listing what that person is presenting.
• Bookmark sessions and abstracts into a personal schedule.
• Browse the poster gallery and ask authors questions.
• Read the accepted abstracts, and follow one through to its session, poster or on-demand paper.
• Watch the on-demand papers, streamed inline with scrubbing.
• Leave session feedback.
• If they are also presenting, see their own presentations and posters.

Why it works when the venue wifi does not

The app remembers what it has already loaded, so a delegate who opened the agenda in the lobby can still read it in a basement session room. An offline indicator tells them when they are looking at cached content.

How it works

You design templates — the layout and content of a screen — and then create instances of those templates for particular places. Each instance has its own web address; point any browser-capable screen, stick, or smart display at it and the screen is live. No software to install.

Screens are paired using a short code, so a technician can set up a display without being given an account.

Kinds of screen

• Welcome — branding and general information.
• Room screens — what is on in this room now and next, drawn from the session list.
• Wayfinding — directional and orientation information.
• Poster sessions — what is on which board.

Screens can be put on a rotating schedule, so one display cycles through several layouts.

Running late, and announcements

Two things make signage worth having on the day. Marking a session as running late adjusts what the screens show without touching the program. And announcements — informational, warning or emergency — can be pushed to screens immediately, which is the fastest broadcast channel you have in a building.

Knowing when a screen has died

Beacon checks its screens every five minutes and can email managers when one stops reporting in. Set the threshold in the alert settings. This is the difference between finding out from a delegate and finding out from Rostrum.

Build a questionnaire, then decide where it applies

Write one questionnaire and apply it broadly, rather than authoring one per session — starting from an organization template if you have one saved (Chapter 16). A questionnaire can be assigned:

• to every session of a type — all workshops, all keynotes;
• to every session in a track;
• to one specific session.

Where more than one applies, the most specific wins: a session-level assignment beats a track assignment, which beats a session-type assignment. So you can run one general form across the meeting and a specialized one for the accredited track.

Settings

How delegates reach it

Two routes: the feedback section inside the Attendee App, and a QR code per session — printed on the room card or shown on the closing slide. The QR route is the one that actually gets responses. A signed-in person may respond once per session, and re-submitting replaces their earlier answer.

Reading the results

A dashboard across the event, per-session detail with response counts and rating breakdowns, the free-text answers gathered per question, and a full export for reporting.

How it runs

Open Mic works per room, not per session — a room has a question channel that runs all day, and whoever is chairing at the time moderates it.

1. Delegates scan a QR code or open the room's public address on their phone.
2. They type a question and send it.
3. The moderator sees the queue on their own screen and works through it.

Moderator access without accounts

Moderators are given a moderator link for their room, which works without a Rostrum account. Hand it to the session chair or the AV operator. Links can be revoked and reissued per room.

Settings

• Require sign-in — whether askers must identify themselves. With it on, a delegate who is not signed in is routed through the email-code login — the same passwordless flow the Attendee App uses — and returned to the question page. Because that flow belongs to the app, this switch needs the Attendee App product enabled; without it the requirement cannot be set.
• Colors — primary and accent, so the public page matches the event.

Analytics is readable by anyone with view access to the event — it exists precisely so a board member or committee chair can see the numbers without being handed an editing role. The tab is organized as sections, and a section only appears when the modules behind it have run: an event that never ran a call for abstracts simply has no Abstracts section, rather than a page of zeros.

What the sections show

Every panel exports its rows as CSV, and charts follow the venue's timezone and your light-or-dark theme.

The post-event report

Download report produces a typeset PDF of the whole story — the funnel, the program shape by day and track, uploads, engagement and email — built from the same numbers the panels show, so the report can never disagree with the screen. Sections appear only where the module ran, and a report generated before the event is marked Completed carries a caveat on its cover saying so. It is the artifact to put in front of a program committee.

AI assistance is enabled per organization by your administrator. When it is off, every AI surface in this chapter is simply absent — no grayed buttons, no upsell — and everything else in this guide works exactly as described. When it is on, three surfaces gain an assistant:

Reading your event website

The guided setup interview (Chapter 04) can read your event's public website and pre-fill the name, dates, venue and topic areas it finds — each shown for your confirmation, never silently applied. It reads only the page you give it.

Building the program conversationally

Build my program on the agenda opens a conversation. Describe what you want — "five rooms, an opening keynote on day one, lunch at noon every day, done by 11 on the last day" — and the assistant asks what it genuinely needs to know, then proposes a complete schedule: the rooms to create and every session with its title, day, times and room, laid out day by day for review. Follow-up messages revise the proposal; Create sessions applies it through the same validated scheduling machinery as the Session Builder, conflicts checked and all. You can also hand it a past year's program — its website, or the program text pasted in — and build from that.

Suggesting sessions for unplaced talks

With a tray full of unplaced presentations, Suggest sessions groups them by topic and proposes named sessions to hold them. The assistant reads titles and abstracts only — never author names or emails — and its groupings arrive as proposals you apply, adjust or ignore.

The rules it works under

• Review before write. Every AI proposal is shown to you in full before anything is created, and anything in a proposal that fails validation — an unknown room, an impossible time — is dropped and counted visibly rather than smoothed over.
• Your permissions, not its own. Applying a proposal uses the same permission-checked actions you would use by hand. The assistant can never do something you could not.
• Scheduling arithmetic stays deterministic. Where AI contributes, it contributes judgement — names, groupings, drafts; validation and conflict checking are code.
• No delegate-facing AI. Attendees, submitters and reviewers never interact with an AI surface.
• A monthly budget per organization caps spend; when it is reached, AI features rest until the next month and say so plainly.

One-day workshop

Six sessions typed in by hand, files collected from four speakers, questions taken from the floor, and an evaluation form at the end for the CPD record. Nothing else is switched on and nothing else is needed.

Scientific congress

The full Path A chain: an invite-only call, per-track review panels, a committee selection board, decision letters, and conversion into a program of orals and posters. Signage in the building, an app in delegates' pockets, and content review on the accepted decks.

Accredited meeting

The program is fixed and imported. The work is compliance: every deck reviewed and approved before it is shown, locked against replacement afterwards, and evaluation data collected per session as evidence.

Returning annual meeting

Last year's fixed items imported as the skeleton, this year's open slots filled from a call, posters converted from accepted abstracts, and the app carrying it all. No signage, no content review — the committee trusts its speakers.

The one that is easy to overlook

Notice that in every column above, the schedule is built or edited in Rostrum — even the imported ones, because a program never survives contact with reality unchanged.

The setup most often assumed to be a poor fit is the large invited congress: four days, six parallel rooms, two hundred talks, and no call for abstracts at all because the scientific committee invites everybody. That event needs nothing from chapters 06 to 12 — and it is the setup that gains most from Chapter 14, because the work it cannot avoid is exactly the work this platform does: rooms, tracks, a grid, running order, file collection from two hundred speakers, and signage that stays right when something moves.

If you are running one of those, you are not an awkward fit for Rostrum. You are the case the schedule builder exists for.