Write down the experience you are selling
The first document should explain the event's promise in concrete terms: whom it is for, what it includes and how it runs. Define the format, schedule, interaction and later access. This allows the team to distinguish a real requirement from an interesting feature that does not belong to the experience participants were promised.
An event with consecutive presentations needs different organisation from a gathering with exercises in small groups. A live session also raises different questions from a library of recordings. Calling all these situations online events does not mean they require the same combination of tools, people and preparation to work well for the intended audience.
When organising earlier editions of AdSummit, I had to connect the presentation page, purchase, access, broadcast and interaction. Solutions changed between editions, but the functions still needed to fit together. That experience reinforces the usefulness of explaining what each part must enable before starting to choose platform names or build the technical arrangement.
Imagine a hypothetical event with a morning of content and a question session. If the promise includes access to a recording, someone needs to prepare that delivery after the broadcast. If it includes answered questions, the programme should reserve time and a way to collect them, instead of leaving those decisions until the day itself.
To prepare your next step, explore Online events as part of a business.
Define how someone moves from registration to access
The team needs to know what confirms a registration, how participants receive instructions and how they find the event. In a paid format, purchase confirmation and access assignment must be consistent. Predictable exceptions also need an owner and an understandable response for the person experiencing a difficulty on the way to attending.
Describe the journey in simple language: someone chooses to participate, completes registration, receives confirmation and enters the right space. Then add the situations that might interrupt that journey. An unconfirmed payment, an incorrectly entered address or an access difficulty should not depend on the memory of whoever happens to be available at that moment.
You do not need to automate every exception before starting. You need to know where exceptions are detected, who handles them and how the person receives a response. Manual work may suit a particular volume, provided it is planned and the team can carry it out without abandoning the rest of the event operation.
The same concern appears when building a funnel the sales team can work with. A handover is only well defined when the person's status and next action are clear. For an event, this prevents confusing purchase intent with confirmed registration, or an email that has been sent with access that has actually been tested.
Separate broadcasting, participation and recordings
Broadcasting picture and sound, enabling participation and delivering recordings are related but distinct needs. Decide which belong to the event and how they work together. Only then should you assess whether one platform covers everything or whether several solutions need connecting to fulfil what has been communicated to the people taking part.
For the live broadcast, consider who appears on screen, who shares content and who controls changes. For participation, decide whether there will be questions, moderation, participant conversations or exercises. Every choice changes the team's work and may require preparation by guests, even when the software lets you activate the feature with only a few clicks.
Recordings also need a decision of their own. Establish whether they will be available, for how long and who checks the material before delivery. Having a recorded file does not make it ready to share: sound, content, beginnings and endings may need checking, alongside the conditions agreed with the people whose contributions appear in it.
In the hypothetical example, a question session might contain information that should not remain in the delivered recording. The organisers need to anticipate that before promising immediate access to everything. Communicating a deliverable you can prepare is more useful than adding a commercial convenience that later creates incompatible work requirements and expectations for the team.
Assign responsibilities before the rehearsal
An event needs identified owners for content, operations, support and decisions during the broadcast. Even when one person fills several roles, making them explicit helps. You can then see where overload exists and who can act when a difficulty requires a quick response without interrupting the entire experience for those who are attending.
I have organised events with more operational tasks on my own side and have also used studio support to concentrate on presentation and content. These are different options requiring different resources. Planning means recognising the work within each role, without assuming it disappears because you have selected a platform with a more complete feature set.
Someone presenting may be unable to resolve access problems, guide a guest and control the broadcast at the same time. If the format depends on combining those tasks, the rehearsal should make that visible. You can simplify the experience, redistribute duties or hire support, but the choice needs to happen while preparation is still possible.
The approach to defining who approves each project decision applies here too. Decide who can change the programme, communicate an interruption or authorise an access change. People doing the work need to know their limits and whom to consult when a situation arises that the plan did not anticipate or explicitly assign to them.
Choose tools through a complete journey test
Once the journey and responsibilities are defined, compare tools against the event's needs and test the selected combination. The test should go beyond opening a broadcast. Include registration, confirmation, entry, participation and later delivery, using the conditions you can reproduce before inviting the audience to take part in the real experience you have planned.
A platform's capabilities and the selected plan's conditions need current confirmation when you reach the selection stage. Prices, limits, integrations and permissions change. A combination used at an earlier event can offer ideas, but it does not replace verification or show that your format will behave identically with a different number of participants.
The logic resembles planning an application before starting to code: describing expected behaviour lets you assess whether the build fulfils it. During rehearsal, record what was tested, what failed and what remains unconfirmed. A working demonstration does not amount to validating every condition of use that the audience and team may encounter during delivery.
By the end, I want to explain how someone participates and how the team delivers each part. Technology then has a concrete function within that explanation. When a choice still depends on “we will see later”, I return to the plan, where I can resolve uncertainty before it reaches someone who has paid for the event.