Conference Run of Show Template for Digital Poster Sessions

Conference organizer reviewing a digital poster session schedule beside display boards

A well-built conference run of show template gives organizers, venue staff, presenters, and technical support the same view of what happens next. For a digital poster session, it should do more than list start times: it should show setup milestones, presenter access windows, room and equipment checks, transition cues, escalation contacts, and teardown responsibilities. Use the framework below to create a working schedule for your event, then confirm every time and handoff with the people responsible for it.

Request an RFP

What should a digital poster session run of show include?

A run of show is the operational timeline for an event or event segment. It places tasks in sequence, assigns an owner, and makes dependencies visible. It is different from a public agenda: an attendee agenda might say that poster viewing begins at 2:00 p.m., while the run of show says who opens the room, when displays are tested, when presenters may load or verify their content, what cue starts the session, and whom to contact if something fails.

For a digital poster session, the document should connect five kinds of information:

Time: scheduled start and finish, plus realistic working windows for setup and transitions.
Action: a clear verb describing what must happen.
Owner: the person or role accountable for completing or confirming it.
Handoff: the person who receives the space, information, or responsibility next.
Confirmation: a visible indication that the task is done, or a named escalation path if it is not.

Keep the plan event-specific. The number of displays, room access rules, poster count, session format, venue policies, and contracted technical scope will vary. Do not assume that every event has the same equipment configuration or that every optional service is part of the order. The organizer's job is to turn the agreed plan into actionable rows, not to copy a generic sequence and treat it as confirmed.

How do you build the schedule before filling in the template?

Start with fixed event commitments, then work backward to find the preparation windows they require. Confirm the venue access time, doors-open time, session start and end, breaks, room turnover, and any restrictions on equipment deliveries or setup. Add the poster schedule and presenter availability only after the organizer has reconciled them with the conference program.

Collect the inputs that control timing

Room access, loading route, setup deadline, and any venue supervision requirements.
Room layout, display positions, power availability, internet arrangements, and safe paths for attendee movement.
Expected poster and display count, session blocks, changeovers, and whether content changes between blocks.
Presenter check-in or verification windows and the instructions presenters must receive beforehand.
Who provides equipment, who operates it, and what support is included in the event plan.
Named organizer, venue, and technical contacts, including an alternate contact for each critical role.
Room-release time, equipment breakdown plan, and the venue's required condition at handback.
Approved program version, content cutoff, and the person authorized to approve a late change.
Any dependencies on registration, security, building access, venue IT, or other room users.

Where a task depends on a decision that is not yet settled, mark it as an open item rather than silently choosing an assumption. For example: “Internet method: venue network or approved alternative; owner: venue IT; confirm by [date].” The run of show should expose unresolved dependencies early, not make them look complete. Add a due date and consequence to each open item: if the decision is late, which test or handoff is affected, and who decides what to do?

Work backward from doors open

Set the room-ready deadline first. Then allocate time for the final technical check, content verification, physical setup, and room access. The exact durations should come from the people performing the work and the venue's rules. A schedule with made-up precision is less useful than a realistic time block that the owner has accepted.

Include buffers where a delay could affect the next activity. A buffer is not unassigned time to fill; it is protection for a specific dependency, such as a late room handoff or a display that needs another test. Decide who can use the buffer and who must be notified if it is consumed.

Build a dependency chain, not just a list

For each fixed milestone, ask what must be true before it can begin. If presenters may enter only after equipment is tested, the presenter window depends on an explicit readiness call. If attendees cannot enter until the organizer checks room circulation, that check must precede doors open. Write these relationships into the sequence or notes so that a delay has a visible impact.

One practical method is to mark each row with a predecessor. “Presenter verification begins after room release and representative content test” tells the team more than a clock time alone. A predecessor is especially useful when venue access can shift, because staff can see which tasks move with the access time and which public commitments remain fixed.

What fields belong in a reusable run-of-show template?

Use one row per action or decision point. If a row contains several independent tasks, split it so each can have a clear owner and completion status. The following fields work for planning and for live operations:

Date and time: include the time zone if staff are coordinating remotely.
Duration or deadline: specify whether the time is a start, finish, or latest-complete point.
Activity and cue: say what happens and what signals it should begin.
Location: room, loading area, registration point, or remote coordination channel.
Lead owner: one role or named person accountable for the row.
Supporting roles: people who assist without obscuring who makes the completion call.
Handoff recipient: who accepts the room, files, information, or next decision.
Verification: what observable condition confirms completion.
Escalation: first contact, backup contact, and the decision owner if unresolved.
Status and notes: planned, confirmed, complete, blocked, or changed, with concise live updates.
Dependency: prerequisite row, approval, or decision needed before this action.
Audience impact: whether the task affects presenters, attendees, or only the working team.

A useful owner is a role, not a vague group. “Technical support lead” is clearer than “AV team”; “organizer program lead” is clearer than “conference.” Add the actual person's name and preferred on-site contact method in the operational copy once assigned. Avoid assigning two people as joint leads unless the row also says who makes the completion call.

Write completion criteria that can be observed

Replace vague status words with a concrete test. “Displays ready” might mean that power is confirmed, the correct poster is visible at the assigned position, and the organizer has checked the label. “Presenter notified” might mean the organizer sent the approved arrival instructions and received an acknowledgment through the chosen channel. These are different outcomes; record only the one the row is meant to verify.

Separate “task performed” from “task accepted.” A technician can report that a display is operating; the organizer can then confirm that the correct content and schedule are shown. The schedule should preserve both facts without making either role responsible for the other's decision.

How should the organizer assign handoffs?

Many schedule problems are handoff problems: one group believes it has finished, while the next group does not know that responsibility has transferred. State the handoff explicitly, including what is being handed over and how acceptance is confirmed.

Venue staff to technical support: venue staff confirm room access and communicate venue constraints; technical support checks that the room and planned connection points are ready for the agreed setup.
Technical support to organizer: support reports equipment and content readiness; the organizer confirms the room is released for presenter access or attendee entry.
Organizer to presenters: the organizer communicates arrival windows, instructions, and any rules for the session; presenters follow the instructions and report content issues through the stated channel.
Presenters to technical support: presenters identify the relevant poster or display and describe the issue; technical support confirms the content or setup status with the organizer when a schedule or program decision is needed.
Organizer to venue staff at close: the organizer confirms the room can be cleared; venue staff receive the room according to the venue's handback requirements.

Use a closed-loop handoff: the sender states what is ready, the recipient acknowledges receipt, and any exception has an owner. Do not rely on a message being sent as proof that the next person has seen it. If a change affects a presenter window or attendee-facing time, have the organizer approve and communicate it.

A useful handoff has four parts

State the object: identify the room, display, file set, responsibility, or decision being transferred.
Describe the condition: report what is complete and what remains open; do not use “ready” if a known exception exists.
Name the recipient: direct the update to a role or named person who can accept it.
Get acknowledgment: record acceptance or route an unaccepted handoff to the backup contact.

For example, “Venue lead confirms room access at the scheduled time; technical lead acknowledges access and starts the layout check; organizer receives the room-ready report before presenter entry.” If access is delayed, the technical lead reports the impact to the organizer rather than moving presenter arrival independently. The organizer decides whether to adjust a presenter window and sends any revised instruction.

Distinguish operational fixes from program decisions

Some issues can be corrected within the agreed technical plan, such as checking a connection or confirming a display assignment. Other issues alter the event program: replacing a poster after the cutoff, changing a presenter's time, extending a session, or moving activity to another room. The run of show should identify which role may make each decision. Technical support can explain the operational options; the organizer owns program choices unless the event has assigned that authority elsewhere.

Use a decision note with the issue, available options, decision owner, deadline, and people to notify. This prevents a helpful on-site adjustment from becoming an unapproved schedule change.

What setup milestones should the template cover?

Plan setup as a sequence with checkpoints, not as a single “install equipment” line. The milestones below are a planning pattern; assign actual times and owners after confirming venue access, equipment scope, and room conditions.

Access and room release: venue contact confirms the room is available, the agreed entry route is open, and any restrictions are understood.
Room and layout check: organizer and technical lead verify display positions against the current floor plan, circulation needs, power locations, and session plan.
Equipment placement: technical support positions the agreed displays, stands, kiosks, or other contracted components. Keep paths and venue rules in view.
Power and connection check: assigned technical and venue contacts confirm the planned power and internet arrangements. Record any unresolved dependency and its escalation owner.
Content and navigation check: confirm that planned posters are assigned to intended displays or menu structure and that the appropriate files are available.
Functional test: test representative interactions and the session's expected workflow, including planned transitions or content loading.
Organizer acceptance: organizer reviews the room-ready state and authorizes presenter access or opening.

Keep the scope of a check precise. “Internet works” is not a useful completion note unless the team has agreed what connection is used and what test is relevant. Likewise, do not mark content ready solely because files were received; identify who checks that the correct poster is associated with the correct session and display.

Use a milestone-to-proof checklist

For every milestone, decide in advance what proof will be recorded. The proof can be a short note in the run of show, a sign-off from the owner, or an entry in the issue log. It should be available to the next role without exposing private information or creating a second, conflicting schedule.

Access: record the time the room was released and any restriction that affects the setup path.
Layout: identify the current floor-plan version and note any approved deviation.
Placement: confirm that the agreed equipment is positioned and that the organizer knows which positions correspond to poster assignments.
Connections: record the agreed arrangement and the result of the relevant check, without implying a guarantee beyond the test performed.
Content: verify a sample or the required set according to the event's agreed process; record missing or mismatched items as open issues.
Acceptance: name who authorized presenter access and when the call was made.

If a check is not applicable, label it “not in scope” and identify who confirmed that boundary. Leaving a blank can be mistaken for an overlooked task.

How do you schedule presenter windows?

Presenters need clear instructions about when they may enter, what they are expected to do, and where to go for help. The run of show should use the same windows communicated in presenter materials. If there are several groups, assign each a window or check-in process that avoids crowding and preserves time for technical verification.

A presenter window may be used to verify a poster's title, author details, assigned display, and any agreed media or navigation behavior. The scope depends on how content is prepared and what the event has contracted. If the event uses a presenter-owned device or a particular upload workflow, document that separately and confirm it with the technical lead; do not assume the same process applies to every setup.

For each window, identify:

Who is eligible to arrive and the exact room or check-in point.
What the presenter should bring or have ready.
What can be checked during the window and what requires organizer approval.
How long the window lasts and what happens if the presenter arrives late.
Who records a verified issue and how it is routed.
When the room must be cleared for testing, doors, or the next session.

Do not promise that every content problem can be corrected during a brief check-in. The organizer should define a cutoff for changes, a decision-maker for late revisions, and a fallback for unresolved items. Communicate those rules before the event.

Design windows for different presenter groups

There is no single best schedule for every poster program. A compact session with one shared arrival period may work when the room and event design allow it. Multiple waves can reduce congestion when authors are numerous or access is limited. A staggered approach also gives staff a manageable sequence for checking assignments, but it requires clear arrival instructions and a way to handle early arrivals.

Use the following decision sequence:

Estimate how many presenters may need an in-person verification, rather than assuming every author will need the same support.
Confirm how many staffed check-in points or technical contacts are actually available.
Determine whether all presenters can safely and practically be in the room at once under venue requirements.
Choose one shared window, multiple blocks, or a self-directed verification method that matches the event's setup.
Set an arrival cutoff that leaves time for any approved correction before the final test.
Tell presenters how to report an absence, delay, or content mismatch.

Do not use a window that overlaps a room test requiring quiet or restricted access unless the technical lead and organizer agree on how both activities will work. If presenters enter in waves, state whether the first group must leave before the next arrives or whether the room remains open.

Handle late arrivals and content changes consistently

A late presenter should not have to guess whether to interrupt a technical test or approach a technician while another issue is being handled. Provide a named check-in point and a fallback contact. The run of show can say that the support person logs the arrival, confirms whether the room is open to presenters, and refers any deadline exception to the organizer.

For a requested content change, record the presenter, poster identifier, requested change, time received, and status. Do not circulate a replacement file or alter an assignment without the event's approved process. The organizer decides whether the change is allowed; technical support verifies the approved version or explains what can be checked before the cutoff. This sequence is especially important when a poster title, author list, or session assignment also appears in program materials.

Which technical checks belong before doors open?

Build a checklist around the actual event configuration. A practical readiness check confirms that the installed setup matches the plan and that the people responsible know how to respond. It should include room-level checks, representative content checks, and communication checks.

Confirm displays and stands are in their planned positions and are stable according to the setup plan.
Verify power and the agreed network or offline arrangement with the designated venue and technical contacts.
Open representative poster content and check that it appears on the intended display or interface.
Confirm that navigation, touch interaction, or other contracted controls behave as planned.
Check brightness and legibility in the room's actual lighting, making adjustments within the agreed configuration.
Confirm session labels, poster assignments, and changeover cues against the approved program.
Test the route for reporting a problem: who receives it, how it is logged, and who decides whether the schedule changes.
Confirm the attendee-facing room is ready under venue requirements, with circulation and access maintained.

Record the result, not just a tick. “Tested: poster A displayed on board 3; organizer confirmed assignment” is more actionable than “done.” If a check fails, record the issue, owner, next action, and decision deadline. Do not leave the room-ready decision implied.

Test representative cases without overstating coverage

Choose test cases that reflect the session's actual use. For example, verify a standard poster, a poster with any agreed media component, a menu or navigation path, and a planned transition if those elements are part of the order. If the event has several display types or content workflows, identify the cases that matter for each. A sample check is evidence about the sample, not proof that every item has been tested.

For a larger program, use a list with poster identifier, display or menu destination, check status, and exception owner. Keep the identifier consistent with the event's approved schedule. If a mismatch is found, pause the readiness sign-off for that assignment, correct it through the approved process, then repeat the relevant check. Avoid editing the public program ad hoc while testing.

Separate technical readiness from room opening

Technical readiness and authorization to open are related but distinct calls. The technical lead reports the result of the agreed checks. The organizer considers program timing, presenter access, and attendee readiness, then authorizes the room to open. Venue requirements remain under the venue's procedures. Put the calls in separate rows so one role's report is not mistaken for another role's approval.

If one check remains incomplete, identify whether the organizer can proceed under an agreed contingency or whether the room must remain closed. The run of show should not make that decision automatically. Name the decision owner and a latest decision time so the team does not debate authority at the doorway.

How should session transitions be cued?

Transitions need an agreed signal, a responsible caller, and a defined next state. For a session with several poster blocks, note whether displays change, presenters rotate, attendees move, or the room remains open while content changes. State the sequence and who communicates it.

A transition row can cover a notice to presenters, a content or menu change by technical support, confirmation by the organizer, and the cue that the next block is ready. Build in time for the activity that actually occurs. If the next session cannot begin until content has been checked, schedule that check before the public start rather than treating it as an informal task during the session.

Use consistent cue language in staff instructions. For example, “At the organizer's room-ready call, technical support loads the next approved block; the organizer verifies the assignment; the program lead announces the next session.” This makes the sequence understandable without implying that technical staff can change program decisions on their own.

Map the transition from current state to next state

For each changeover, describe the starting state and ending state. “Block A ends” is not enough. Specify whether attendees remain in place, presenters leave or rotate, and whether displays change immediately or after a confirmation. Then identify the signal that begins each step and the signal that tells the next owner to proceed.

A written transition sequence might be:

Organizer calls the end of the current block and communicates the presenter movement instruction.
Presenters follow the stated route; the room lead confirms the space is ready for the next planned action.
Technical support changes content or navigation only according to the approved sequence.
Organizer or assigned reviewer checks the next block's labels and assignments.
Program lead gives the public cue once the organizer confirms readiness.

These are example roles, not mandatory staffing levels. If one person fills more than one role, preserve the order and make the conflict visible: that person cannot acknowledge a handoff while performing a task that prevents them from checking the result.

Protect transition time from unrelated work

Changeover time often gets consumed by questions, late file requests, room movement, and unrelated messages. Assign a route for each type of work. The organizer handles program exceptions; the designated support contact receives technical issues; venue staff address access or facilities matters. If a task cannot be handled within the transition window, log it and give it an owner rather than letting it delay the next block without a decision.

When the planned transition cannot finish on time, the technical lead reports the current state and the remaining work. The organizer decides whether to delay the next cue, use an approved fallback, or proceed with a disclosed limitation. Record who approved the choice and who communicates it to presenters and attendees.

What should escalation contacts and decisions look like?

List a primary and backup contact for each function, but also identify who has authority to make each type of decision. The technical contact can diagnose an operational issue; the organizer may own a schedule change, presenter exception, or decision to proceed. Venue staff control venue-specific matters under their procedures.

Use a compact contact block in the live document:

Organizer lead: name, on-site location or approved contact method, backup, and decisions owned.
Venue contact: name or role, contact method, venue escalation route, and access or facilities decisions.
Technical lead: name or role, contact method, backup, and technical issue intake method.
Presenter support point: where presenters report issues and who routes them to the right owner.
Program or communications owner: person who approves and communicates attendee-facing changes.
Emergency procedure: refer to the venue's established instructions and the event's applicable emergency contacts.

Avoid publishing personal contact details in attendee-facing materials unless the people involved have approved that use. The operational run of show can contain restricted contact information and should be distributed to the working team through an appropriate channel.

Route issues by impact and decision type

Not every issue should reach every contact at once. A routing rule helps the team respond quickly without interrupting unrelated roles:

Room access, power location, or venue restriction: contact the venue lead; notify the organizer if timing or room readiness changes.
Display, content loading, or interaction concern: contact technical support; include the poster or display identifier and observed result.
Presenter arrival, assignment, or approved-file exception: contact the organizer's presenter point; the organizer decides whether a program exception applies.
Session timing or attendee instruction: contact the program lead; only the authorized organizer communicates a change.

For each route, state a response expectation in operational terms, such as “acknowledge at the next check-in” or “call the lead immediately if doors are affected.” Do not invent universal response times. Choose a rule that fits the event and the staff available.

Use an issue record that supports decisions

A concise issue record should include time observed, reporter, location or poster identifier, description of the expected and actual state, immediate action, owner, decision needed, due time, and current status. If the problem is resolved, record what changed and who verified the result. This makes it possible to distinguish a fixed issue from one that was merely passed along.

Keep operational notes factual and appropriate for the audience that can access the file. Avoid adding sensitive information or personal details that are not needed to resolve the issue. If a separate incident process applies, follow it rather than treating the run of show as the only record.

How can teams keep the live document usable?

Choose one controlled version as the source of truth. Give it a version date and identify who may make changes. A single document owner can collect updates, but each row's lead owner must still confirm their own task. Share a view that staff can access at the venue, and have a fallback way to reach the current schedule if a device or connection is unavailable.

During operations, use short status notes with timestamps. Record changes to timing, room access, content, and handoffs. If the public agenda changes, designate the organizer or communications owner to update attendee-facing materials; the operations document alone does not notify presenters or attendees.

For a change, capture four facts: what changed, why it changed, who approved it, and who needs to know. Remove obsolete instructions from the active view or clearly mark them superseded. This avoids parallel versions that send different teams to different times or locations.

Set a simple version and update routine

Before the event, name the document owner and establish a cutoff for routine edits. The owner records the version date, distributes the approved copy, and archives or labels replaced versions so they are not mistaken for current instructions. At the live briefing, point staff to the authoritative copy and explain how corrections will be announced.

During the event, do not silently overwrite a significant change. Add a timestamp, the approving role, and the affected rows. Tell the people who need the update through the agreed channel and ask the new owner to acknowledge a changed handoff. For urgent changes, use the event's established communication method first, then update the document so the record matches the decision.

Plan for access failure. Keep a permitted offline or printed copy for essential roles if appropriate, and specify how it will be reconciled with the live version. A backup copy is useful only if staff can identify which version is current.

Reusable conference run of show template

Copy this structure into your event planning document. Replace bracketed fields, confirm owners, and adjust the order to match the venue and session design. Times below are placeholders, not recommended durations.

Event and contact header

Event and date: [event name] — [date]
Venue, room, and time zone: [details]
Organizer lead and backup: [names and approved contact method]
Venue contact and escalation route: [details]
Technical lead and backup: [details]
Presenter check-in point: [location and instructions]
Approved version and owner: [version/date/person]
Key dependencies still open: [item, owner, due date]
Program version and content-change cutoff: [reference and deadline]
Room access, doors, session, and handback commitments: [times]

Run-of-show row template

[Date/time/time zone] — [action and cue] — [location] — Lead: [role/name] — Support: [roles] — Predecessor: [dependency] — Handoff to: [role] — Complete when: [observable test] — Escalate to: [primary/backup] — Audience impact: [who needs notice] — Status/notes: [timestamp and update]

Example sequence to adapt

[Access time] Venue contact confirms room access and restrictions; technical lead acknowledges receipt and begins only the agreed setup work.
[Layout window] Organizer and technical lead check the current layout, poster count, session blocks, power plan, and internet arrangement.
[Placement complete] Technical support reports the equipment and connection checks; organizer records any open exception and decides whether the next milestone can proceed.
[Presenter window] Presenters follow the communicated check-in route; support logs exceptions; organizer decides any schedule or content exception.
[Before doors] Technical lead completes representative content and interaction checks; organizer authorizes room opening.
[Session start] Organizer or program lead gives the agreed opening cue; support monitors the defined issue channel.
[Between blocks] Organizer calls the transition; support makes approved changes; organizer confirms the next block.
[Session close] Organizer gives the close cue and confirms presenter and attendee departure sequence.
[Teardown] Technical support follows the agreed breakdown scope; venue contact receives the room; organizer records unresolved follow-up.

Example worked sequence for a hypothetical event

Consider a one-day research meeting with two poster blocks in one room. The example below is not a recommended duration or a promise about any particular event; its purpose is to show how to make dependencies and handoffs visible. Replace all times and roles after checking the venue and the contracted scope.

Room access: At the confirmed access time, the venue lead releases the room and notes any restriction. The technical lead acknowledges the handoff; if the room is not available, the organizer receives the delay and assesses the impact on setup and presenter instructions.
Layout confirmation: The organizer and technical lead compare the actual room with the approved plan. Any changed display position is recorded and checked against circulation and power arrangements before placement continues.
Setup report: Technical support reports placement and the result of agreed connection checks. The organizer reviews open issues and makes the room-access decision for presenters.
Presenter verification: A first group arrives at the stated check-in point. Support logs a title or assignment mismatch; the organizer determines whether it may be corrected under the event's cutoff rules.
Ready call: Technical support tests representative content and the planned interaction. The organizer checks the session labels and gives the authorization to open, or names the remaining issue and decision deadline.
Block one: The program lead gives the opening cue. Staff use the defined issue route rather than handling requests through informal side conversations.
Changeover: The organizer calls the transition, presenters and attendees follow the stated movement plan, technical support applies the approved next block, and the organizer verifies the resulting assignment.
Close and handback: The organizer calls the end, confirms that the room may be cleared, and hands it to the technical lead for the agreed breakdown. The venue lead accepts the room under its requirements.

In this example, the schedule should not hide the decision moments inside a generic setup block. The separate room-release, acceptance, presenter-window, transition, and handback rows show who may proceed and when. If a delay occurs, the team can identify the affected dependency instead of treating every time as independently movable.

How should teardown and room handback be planned?

Teardown begins with a clear close cue, not with equipment removal while presenters or attendees still expect access. Schedule the final session end, any presenter departure or file follow-up, the point at which displays may be taken out of service, breakdown, and venue handback. Confirm who authorizes each step.

The technical lead should follow the agreed equipment and content handling process. The organizer should confirm whether any optional gallery or post-event access is part of the separate scope, rather than assuming that dismantling onsite displays ends or includes a hosted collection. Venue staff should state any room condition or timing requirements. At completion, record the handback and list any equipment, room, or program issue requiring follow-up.

Use a final checklist that covers attendee and presenter departure, approved content follow-up, equipment breakdown, removal route, room condition, venue acceptance, and closure of open issues. Assign each item to a role and make completion visible.

Sequence breakdown so the room remains controlled

Write the teardown sequence with the same care as setup. The organizer gives the close cue and confirms that attendee and presenter activity has ended or moved to the approved next location. Technical support confirms that the equipment can be taken out of service. Venue staff clarify access, removal routes, and any room condition requirements. Do not assume that the last scheduled session time automatically means the room is available for breakdown.

Organizer calls the close and confirms the room is clear for the next step.
Technical lead identifies any content or equipment items that must remain available under the agreed scope.
Technical support follows the contracted breakdown and removal plan.
Organizer and venue contact check the room against the venue's handback expectations.
Each lead reports completion or records an open follow-up with an owner and due date.

If a presenter needs to raise a post-session issue, the organizer should provide the appropriate route rather than allowing the presenter to interrupt a safety- or venue-directed breakdown. If follow-up hosting or a gallery is in scope, record the separate owner and next step; it is not automatically part of onsite teardown.

What should organizers confirm before the event?

Review the run of show with the organizer, venue, and technical support leads together. Read it from the first room-access task through handback. At each point, ask who acts, who confirms, what happens if the task is late, and who owns the decision. Then verify that presenter instructions and the public program use compatible times and locations.

For an event-specific plan, organizers can review ePosterBoards' conference services and request an RFP to discuss the proposed scope, venue details, poster schedule, and support responsibilities. Keep the final run of show aligned with the services and equipment actually agreed for the event.

Frequently asked questions

How is a run of show different from a conference agenda?

An agenda communicates public sessions and times. A run of show records operational actions, owners, cues, handoffs, checks, and escalation decisions that allow the event team to deliver those sessions.

Who owns the run of show?

The organizer should name a document owner and an event decision-maker. Individual rows still need accountable owners, such as the venue contact for access, technical lead for agreed equipment checks, and program lead for schedule cues.

Should presenter arrival times appear in the run of show?

Yes, when presenter access affects setup, verification, or the room schedule. Use the same time and location in the presenter instructions, and define how late arrivals and requested changes are handled.

How often should the run of show be updated?

Update it whenever an approved change affects timing, location, responsibilities, or readiness. Use one controlled version, timestamp important changes, and notify each affected role rather than assuming a revised document has been seen.

Does every digital poster event use the same technical sequence?

No. Equipment, venue access, content workflow, session format, and contracted services vary. Use the template as a planning framework, then confirm each milestone with the organizer, venue, presenters, and technical support responsible for that event.

Discuss your event requirements

A run of show is ready when every critical action has an owner, a realistic time, a confirmation method, and a clear next handoff. Review it with the people doing the work, update it when plans change, and keep one approved version available during the event.