Uma pessoa preenche um formulário de inscrição e os dados ficam guardados numa folha de cálculo.
À primeira vista, o trabalho parece terminado.
Temos nomes, emails, empresas e todas as respostas às perguntas colocadas no formulário. Basta importar a base para a plataforma utilizada no evento.
Na prática, existe uma etapa intermédia muito importante:
transformar uma lista de inscritos numa base de participantes preparada para ser utilizada.
Emails incorretos, duplicados, campos desnecessários, empresas escritas de diferentes formas ou várias versões do mesmo ficheiro podem parecer pequenos problemas enquanto estamos a olhar para um Excel.
No dia do evento, alguns desses pequenos problemas deixam de ser pequenos.
Uma base de inscrições não está necessariamente pronta a utilizar
Quando recebemos uma base de participantes, começamos por perceber o que realmente temos.
Verificamos, entre outros pontos:
- nomes;
- endereços de email;
- duplicados;
- campos disponíveis;
- tipo de participante, quando relevante;
- informação necessária para a acreditação;
- estrutura e formatação do próprio ficheiro.
Por vezes, o primeiro passo é ainda mais básico: criar uma versão de trabalho mais simples.
Um Excel pode chegar com filtros, fórmulas, formatações e dezenas de campos que foram úteis durante a preparação do evento, mas que não têm qualquer utilidade para a operação.
Não precisamos de transportar toda essa complexidade para a plataforma de acreditação.
Menos dados pode significar uma base melhor
Uma base de origem pode ter 20 ou 30 campos.
Isso não significa que todos devam ser importados.
Para uma acreditação simples podemos precisar apenas de:
- nome;
- empresa;
- email;
- tipo de participante.
Noutros eventos podem existir informações adicionais necessárias, como restrições alimentares, transferes, lugares reservados ou outro dado com uma função operacional concreta.
O critério é sempre o mesmo:
para que precisamos deste campo durante o evento?
Se não existe uma resposta, provavelmente não precisamos de o levar para a operação.
Além de simplificar o trabalho, evitamos colocar informação desnecessária nas plataformas e nos equipamentos utilizados no evento.
Os problemas mais frequentes são bastante simples
As bases de participantes raramente chegam com problemas tecnologicamente complexos.
São normalmente coisas muito mais banais:
- endereços de email incorretos;
- dois emails colocados na mesma célula;
- emails genéricos em vez de individuais;
- participantes duplicados;
- empresas escritas de diferentes formas;
- campos desnecessários;
- ficheiros Excel com formatação difícil de tratar.
Individualmente, nenhum destes problemas parece particularmente grave.
Mas imagine uma campanha em que o mesmo participante aparece duas vezes, uma pessoa tem dois endereços dentro da mesma célula ou o email utilizado para enviar o QR Code está incorreto.
A qualidade da experiência final começa também na qualidade destes dados.
Um formulário bem construído ajuda — mas não elimina a validação
Quando acompanhamos a própria inscrição, conseguimos controlar melhor a estrutura dos dados desde o início.
Podemos, por exemplo, recomendar:
- uma inscrição por endereço de email;
- campos claramente definidos;
- opções fechadas quando fazem sentido;
- recolha apenas da informação necessária.
O resultado tende a ser uma base mais uniforme.
Nome está na coluna de nome. Email está na coluna de email. Empresa está na coluna de empresa.
E não temos dezenas de campos que apareceram ao longo do processo sem uma finalidade clara.
Mas mesmo uma base proveniente de um formulário bem construído não deve ser assumida como perfeita só porque foi gerada automaticamente.
As pessoas continuam a escrever os próprios dados.
Um formulário pode organizar a recolha. Não consegue garantir que alguém não escreve mal o endereço de email ou introduz uma designação inesperada.
Por isso, a validação continua a fazer parte do processo.
O badge também começa na base de dados
Quando os dados vão ser impressos numa etiqueta ou badge, existe outra camada de preparação.
Um nome que parece perfeitamente normal numa folha de cálculo pode não funcionar tão bem quando tem de caber num espaço limitado.
O mesmo acontece com empresas, funções ou outros campos.
Sempre que existe tempo e abertura por parte do cliente, podemos ajudar a uniformizar a informação e testar:
- comprimento dos nomes;
- designações das empresas;
- utilização de maiúsculas e minúsculas;
- número de campos impressos;
- tamanho de letra;
- disposição da informação;
- diferentes tipos de badge.
E testamos casos reais da própria base.
Não interessa apenas perceber como fica uma etiqueta com “João Silva”.
Interessa perceber como fica o nome mais comprido que efetivamente temos de imprimir.
Os tipos de participante podem mudar todo o processo
Nem todos os participantes precisam necessariamente de receber o mesmo tratamento.
O tipo de participante pode determinar:
- comunicação diferente;
- QR Code diferente;
- cor ou formato do badge;
- entrada a utilizar;
- sessões a que pode aceder;
- informação específica;
- lugar reservado;
- outras regras do evento.
É por isso que um campo aparentemente simples como tipo de participante pode ser operacionalmente muito mais importante do que vários outros campos existentes na base.
A preparação dos dados deve ter em conta aquilo que vai acontecer depois.
Importar e testar antes de abrir as portas
Depois de preparada a base, importamos os participantes e testamos o processo completo.
Não nos limitamos a verificar se o Excel foi aceite pela plataforma.
Testamos aquilo que o participante e a equipa vão realmente utilizar.
Por exemplo:
- envio das campanhas para endereços de teste;
- receção do QR Code;
- leitura do QR Code;
- pesquisa de participantes pelo nome;
- informação apresentada no sistema;
- impressão das etiquetas;
- disposição dos campos no badge.
Quando existe comunicação antecipada, estes testes são especialmente importantes.
Depois de enviarmos milhares de QR Codes, corrigir a origem dos dados torna-se naturalmente mais complexo.
A última versão do Excel
Um dos problemas mais delicados não é tecnológico.
É saber qual é a versão correta da base.
Os eventos continuam a evoluir até muito perto da abertura. Entram novos participantes, existem desistências, mudam lugares ou alteram-se determinados dados.
Já recebemos atualizações uma hora ou até meia hora antes de um evento.
Conseguimos tratá-las, mas não é o cenário ideal.
Sempre que possível, para eventos de manhã procuramos receber a última atualização até ao final do dia anterior. Num evento à tarde, duas ou três horas de antecedência já permitem trabalhar com muito mais segurança do que receber alterações no momento da abertura.
Quando existem apenas novos participantes, preferimos também receber apenas os novos registos, em vez de uma nova cópia de toda a base.
Isso reduz uma pergunta perigosa:
O que mudou entre estes dois ficheiros?
Alterar não é o mesmo que acrescentar
Adicionar 20 novos participantes a uma base é relativamente simples.
Receber uma nova versão em que alguns participantes foram acrescentados, outros apagados e dezenas de lugares alterados é completamente diferente.
Se já existiram comunicações anteriores, a situação torna-se ainda mais sensível.
Um participante pode já ter recebido um QR Code associado a determinada informação que entretanto foi modificada.
É nestas situações que o controlo de versões assume particular importância.
Quanto mais perto estamos do evento, menos tempo existe para comparar centenas de linhas e perceber exatamente aquilo que foi alterado.
As alterações de última hora não são necessariamente um problema. As alterações de última hora que não conseguimos identificar claramente podem ser.
E se aparecer um novo participante no próprio evento?
A base não precisa de ficar congelada quando abrimos as portas.
Quando autorizado pelo cliente, conseguimos introduzir novos participantes diretamente durante o evento.
Esses registos ficam integrados na mesma base, em vez de serem apontados numa lista paralela que posteriormente terá de ser reconciliada.
No final conseguimos também identificar quais foram os participantes acrescentados no próprio dia.
Isto mantém uma única fonte de informação ao longo de todo o processo.
Nem toda a base precisa de estar disponível no evento
Existe outro princípio importante na preparação:
levar para a operação apenas os dados necessários.
O cliente pode fornecer uma base muito mais completa porque precisa dessa informação para outras finalidades.
Isso não significa que toda ela deva ficar disponível nos equipamentos utilizados na acreditação.
Podemos não importar determinados campos ou simplesmente não os disponibilizar na operação.
Se naquele posto precisamos de nome, empresa e tipo de participante, não existe razão operacional para expor mais dez campos apenas porque estavam no Excel original.
Além de tornar a utilização mais simples, reduzimos a circulação desnecessária de dados pessoais.
A base continua a produzir informação depois da entrada
Depois da acreditação, conseguimos devolver ao cliente informação útil sobre aquilo que aconteceu.
Consoante o projeto, pode incluir:
- participantes que chegaram;
- participantes que não compareceram;
- horário de entrada;
- participantes acrescentados no próprio dia;
- presenças por tipo de participante;
- períodos de maior afluência.
Em alguns eventos, os horários permitem inclusivamente construir gráficos com os picos de entrada e compreender melhor o comportamento das chegadas.
Essa informação pode depois ajudar a preparar uma edição futura.
O Excel que começou por ser uma lista de pessoas passa, no final, a contar também como aconteceu o evento.
Uma base acionável, não apenas uma folha de cálculo
É fácil olhar para uma base de participantes como um ficheiro administrativo.
Mas aqueles dados vão alimentar comunicações, gerar QR Codes, imprimir badges, determinar acessos, indicar lugares, apoiar refeições ou transferes e, finalmente, registar quem esteve presente.
Por isso, existe trabalho entre “temos as inscrições” e “estamos preparados para o evento”.
É um trabalho pouco visível e que, muitas vezes, nem é particularmente valorizado quando tudo corre bem.
Mas é precisamente esse o objetivo.
No dia do evento já é tarde para descobrir que a base não estava preparada para aquilo que queríamos fazer com ela.
Preparar uma base não significa torná-la maior ou mais sofisticada.
Na maioria das vezes significa exatamente o contrário:
corrigir, uniformizar, retirar o que não precisamos e transformar os dados existentes em informação que conseguimos realmente utilizar.