Um CRM para eventos é uma base das pessoas em volta dos seus eventos, e não dos eventos em si. A distinção parece pequena e decide tudo, porque uma ferramenta de evento é comprada pelo desempenho no dia do show e julgada, meses depois, pela facilidade de encher a data seguinte.
Para lembrar
- O software de gestão faz o evento acontecer. O CRM faz a relação depois dele.
- O teste de compra é o segundo evento, não o primeiro: ele tem que custar menos para encher.
- Entre duas datas, uma boa ferramenta continua trabalhando, separando as pessoas pelo motivo que as trouxe.
O que é de verdade um CRM para eventos
Um CRM cuja chave é a pessoa. É a definição inteira, e todo o resto sai daí.
Cada sistema em volta de um evento tem uma chave diferente, e é ela que decide o que sobrevive à noite.
| Chave | O que sobra no dia seguinte | |
|---|---|---|
| A bilheteria | A transação | Um pagamento, e um contato que fica com a plataforma |
| O sistema de gestão de eventos | O evento | Um evento encerrado, planejado e com equipe |
| Um CRM comercial genérico | A negociação | Uma etapa de funil que não serve para quem compra ingresso |
| Um CRM para eventos | A pessoa | Uma ficha por pessoa, com o motivo de ter vindo e o direito de escrever para ela |
Quatro campos formam essa ficha, e uma ferramenta a que falte um deles não está nesta categoria:
- A identidade. Uma entrada por pessoa, não uma por ingresso nem uma por evento.
- A origem. Qual superfície a captou, e qual evento a trouxe.
- O comportamento. O que abriu, tocou, frequentou e comprou, gravado na hora em que acontece.
- A permissão. O consentimento, o texto que ela leu, a marca de tempo, exportáveis junto com o resto.
O quarto é o que se descobre tarde. Uma lista de participantes não é uma lista de marketing: o consentimento no RGPD precisa ser específico e demonstrável, então uma exportação da bilheteria que traz um número raramente traz o direito de usá-lo.
O que o dia do show esconde
No dia do show tudo funciona. O leitor lê, a lista de convidados abre, o bar cobra, o cronograma segura. Toda ferramenta na casa parece competente, porque o dia do show é um problema de logística e software de logística é um campo maduro.
Aí as luzes acendem e o software se cala. O evento acabou, e com ele a única coisa que a maioria desses sistemas sabia acompanhar. Sobra uma linha num relatório: 1.842 participantes.
Esse número é o resíduo de uma relação, não a relação. Não dá para escrever para ele, nem segmentá-lo, nem fazer uma pergunta. Sete meses depois você anuncia a próxima data e anuncia, de novo, para os mesmos seguidores na mesma plataforma, com o alcance que aquela plataforma quiser te dar.
Os quatro trabalhos dos meses parados
É isto que a ferramenta deveria estar fazendo enquanto nada acontece.
Guardar cada pessoa uma única vez. Quem veio em março, comprou merchandising em maio e abriu três emails desde então é uma ficha, não três. Deduplicar parece faxina e é, na verdade, a diferença entre uma lista e um monte.
Lembrar por que vieram. A noite de techno e o stand-up não são o mesmo público, mesmo na mesma casa. Se a origem de cada contato foi escrita na captação, essa diferença já é um segmento e ninguém precisa construí-lo depois.
Enriquecer sozinha. Cada abertura, clique, presença e compra deveria cair no perfil no momento em que acontece. Uma base que exige alguém para atualizá-la não será atualizada, e depois de duas temporadas ela mente.
Continuar alcançável. Um endereço, um número e um rastro de consentimento por pessoa, portáveis, exportáveis, não presos dentro de uma plataforma. Sua lista é também a entrada de todo o resto: é o que as plataformas de anúncio chamam de segmentação por lista de clientes, e não dá para alimentar isso com um contador de cliques.
O teste que decide a compra
Não uma lista de recursos. Uma pergunta, dita em voz alta:
Conseguimos escrever hoje à noite para quem veio ao último evento, e só para essas pessoas, sem pedir autorização a ninguém e sem pagar por alcance?
Se a resposta precisa de uma ressalva, a ferramenta é um sistema de gestão com exportação de contatos, o que é ótimo de se ter e outra coisa bem diferente de se comprar.
A segunda versão da pergunta é mais dura e melhor: você consegue escrever para quem veio ao último evento e não veio ao anterior? É esse segmento que enche casa, e ele só existe se a origem e o histórico de presença estiverem no mesmo perfil.
Onde isso leva na prática
O formato que funciona é chato. Fique com a bilheteria que você tem, porque pagamento e acesso são problemas resolvidos e trocar custa mais do que devolve. Some uma camada que guarda a pessoa, não a transação. É isso que a HIIPE chama de Fanbase, com a segmentação junto: cada superfície de captação escreve a própria etiqueta de origem, então qualquer parte da lista vira um segmento sem um profissional de marketing no meio. Como as peças se encaixam e os recursos construídos em cima são o produto inteiro, e a bilheteria fica onde está.
É também por isso que o preço desta categoria não deveria crescer com quantas pessoas você lembra. Um sistema cujo custo sobe com o seu arquivo te empurra em silêncio a apagar aquilo que ele foi comprado para proteger, argumento desenvolvido em quanto custa de verdade uma base de 10.000 contatos.
As três listas que deveriam levar dez segundos
Um bom jeito de avaliar qualquer ferramenta da categoria é pedir três listas, em voz alta, e ver quanto tempo a resposta leva. Nenhuma é exótica, e as três são impossíveis sem a pessoa como objeto central.
| A lista | Por que vale dinheiro | O que a torna difícil |
|---|---|---|
| Veio ao último evento, não comprou para o próximo | A mensagem que melhor converte numa casa | Dois eventos comparáveis num mesmo perfil |
| Veio duas vezes ou mais, alguma vez | O seu núcleo real, e quem merece um preço melhor | Um histórico que sobrevive à exportação de cada ano |
| Se inscreveu por este parceiro, este post, esta noite | Diz qual canal vale repetir | Uma etiqueta de origem escrita na captação, nunca depois |
Se alguma das três levar mais de um minuto, a restrição não é a interface. É que o modelo de dados guarda eventos e não pessoas, e nenhum relatório conserta isso por cima.
O que migrar primeiro, e o que deixar quieto
O instinto é mover tudo de uma vez, e é a razão pela qual quase todos esses projetos morrem no segundo mês. A ordem que funciona é quase o contrário.
- Deixe a bilheteria exatamente onde está. Pagamento e acesso estão resolvidos. Movê-los não traz nada e põe em risco a única coisa que não pode quebrar.
- Comece pelo próximo evento, não pelo arquivo. Uma superfície, um texto de consentimento, uma etiqueta de origem. Você aprende mais em três semanas do que em três meses de planejamento.
- Importe o arquivo como histórico, marcado assim. Participantes antigos são contexto útil e não uma lista de email, pelas razões da FAQ acima.
- Só acrescente a segunda superfície quando a primeira ficar chata. Um ponto de captação que ninguém lembra de usar é pior que nenhum, porque faz os números mentirem.
- Monte as três listas acima e deixe à vista. São a única prova de que a migração valeu, e levam uma temporada para ficar interessantes.
No fim de um ciclo você terá uma lista menor do que a inicial, e será a primeira que você consegue de fato usar.
Por onde começar
Pelo último evento, não pelo próximo. Exporte os dados de participantes que ainda existem, etiquete com o nome do evento e veja que parte tem um canal alcançável e consentido. Essa parte é o seu público inicial real, e costuma ser bem menor que o número de presença. A distância entre esses dois números é para o que serve um CRM para eventos. O resto do argumento sobre de quem é essa distância está em o que é um fan CRM.
Para ler depois : O que é um fan CRM, e o que não é · Encher o próximo evento com a lista do anterior