Escreve a experiência que estás a vender
O primeiro documento deve explicar a promessa do evento em termos concretos: para quem é, o que inclui e como decorre. Define o formato, os horários, a interação e o acesso posterior. Com isso, a equipa consegue distinguir uma necessidade real de uma funcionalidade interessante que não faz parte da experiência prometida.
Um evento de apresentações seguidas pede uma organização diferente de um encontro com exercícios em pequenos grupos. Uma sessão em direto também coloca questões diferentes de uma biblioteca de gravações. Chamar evento online a todas estas situações não significa que precisem da mesma combinação de ferramentas, equipa e preparação para funcionar.
Na organização de edições anteriores do AdSummit, tive de ligar página de apresentação, compra, acesso, transmissão e interação. As soluções foram mudando entre edições, mas as funções precisavam de continuar a encaixar. Essa experiência reforça a utilidade de explicar primeiro o que cada parte tem de permitir, antes de escolher nomes de plataformas.
Imagina um evento hipotético com uma manhã de conteúdo e uma sessão de perguntas. Se a promessa inclui acesso à gravação, alguém precisa de preparar essa entrega depois do direto. Se inclui perguntas respondidas, a programação deve reservar tempo e uma forma de as recolher, em vez de deixar essas decisões para o dia.
Para preparar o próximo passo, consulta Eventos online como parte de um negócio.
Define como uma pessoa passa da inscrição ao acesso
A equipa precisa de saber o que confirma uma inscrição, como o participante recebe instruções e de que forma encontra o evento. Num formato pago, a confirmação da compra e a atribuição do acesso têm de ser coerentes. As exceções previsíveis também precisam de um responsável e de uma resposta compreensível para a pessoa.
Descreve o percurso com linguagem simples: a pessoa escolhe participar, conclui a inscrição, recebe a confirmação e entra no espaço certo. Depois acrescenta as situações que podem interromper esse percurso. Um pagamento por confirmar, um endereço mal introduzido ou uma dificuldade de acesso não devem depender da memória de quem estiver disponível naquele momento.
Não precisas de automatizar todas as exceções para começar. Precisas de saber onde são detetadas, quem as trata e como a pessoa recebe uma resposta. O trabalho manual pode ser adequado num determinado volume, desde que esteja previsto e que a equipa tenha capacidade para o executar sem abandonar o resto da operação.
A mesma preocupação aparece ao montar um funil que a equipa comercial consegue trabalhar. Uma passagem só está bem definida quando o estado da pessoa e a ação seguinte são claros. No evento, isto evita confundir uma intenção de compra com uma inscrição confirmada ou um email enviado com um acesso efetivamente testado.
Separa transmissão, participação e gravações
Transmitir imagem e som, permitir participação e entregar gravações são necessidades relacionadas, mas distintas. Convém decidir quais fazem parte do evento e como funcionam em conjunto. Só depois faz sentido avaliar se uma plataforma cobre tudo ou se precisas de ligar várias soluções para cumprir aquilo que foi comunicado ao participante.
Para o direto, pensa em quem entra em cena, quem partilha conteúdos e quem controla as mudanças. Para a participação, decide se haverá perguntas, moderação, conversas entre participantes ou exercícios. Cada escolha altera o trabalho da equipa e pode exigir preparação dos convidados, mesmo que o software permita ativá-la com poucos cliques.
As gravações também precisam de uma decisão própria. Define se ficam disponíveis, durante quanto tempo e quem verifica o material antes da entrega. A existência de um ficheiro gravado não significa que esteja pronto a ser disponibilizado: pode ser necessário confirmar som, conteúdo, início e fim, assim como as condições combinadas com os intervenientes.
No exemplo hipotético, uma sessão de perguntas pode incluir informação que não deve ficar na gravação entregue. A organização precisa de prever esse tratamento antes de prometer acesso imediato a tudo. É mais útil comunicar uma entrega que consegues preparar do que acrescentar uma conveniência comercial que depois cria trabalho e expectativas incompatíveis.
Atribui responsabilidades antes do ensaio
Um evento precisa de responsáveis identificados para conteúdo, operação, apoio e decisões durante a emissão. Mesmo que algumas funções fiquem na mesma pessoa, convém torná-las explícitas. Assim consegues perceber onde existe sobrecarga e quem pode agir quando uma dificuldade exige uma resposta rápida sem interromper toda a experiência do participante.
Já organizei eventos com mais tarefas operacionais do meu lado e também recorri a apoio de estúdio para me concentrar na apresentação e no conteúdo. São opções diferentes, com recursos diferentes. O importante para planear é reconhecer o trabalho que existe em cada função, sem assumir que desaparece porque escolheste uma ferramenta mais completa.
Uma pessoa a apresentar pode não conseguir, ao mesmo tempo, resolver acessos, orientar um convidado e controlar a emissão. Se o formato depender dessa acumulação, o ensaio deve torná-la visível. Podes simplificar a experiência, redistribuir tarefas ou contratar apoio, mas a escolha precisa de acontecer enquanto ainda há tempo para a preparar.
O critério de definir quem aprova cada decisão num projeto também se aplica aqui. Decide quem pode alterar a programação, comunicar uma interrupção ou autorizar uma mudança de acesso. As pessoas que executam precisam de saber os seus limites e a quem recorrer quando surge uma situação que não estava prevista.
Escolhe ferramentas a partir de um teste completo
Com o percurso e as responsabilidades definidos, compara ferramentas pelas necessidades do evento e testa a combinação escolhida. O teste deve ir além de abrir uma transmissão. Inclui inscrição, confirmação, entrada, participação e entrega posterior, usando as condições que consegues reproduzir antes de convidar o público para a experiência real.
A capacidade de uma plataforma e as condições do plano escolhido precisam de confirmação atual quando chegares à seleção. Preços, limites, integrações e permissões mudam. Uma combinação usada num evento anterior pode dar ideias, mas não substitui essa verificação nem demonstra que o teu formato terá o mesmo comportamento com outro volume de participantes.
A lógica é semelhante a planear uma aplicação antes de começar a programar: escrever o comportamento esperado permite avaliar se a construção o cumpre. No ensaio, regista o que foi testado, o que falhou e o que ficou por confirmar. Ter uma demonstração a funcionar não equivale a validar todas as condições de utilização.
No fim, quero conseguir explicar como alguém participa e como a equipa entrega cada parte. A tecnologia passa a ter uma função concreta dentro dessa explicação. Quando uma escolha ainda depende de um «logo vemos», volto ao plano, porque é aí que consigo resolver a incerteza antes de ela chegar a quem comprou o evento.