Duas permissões diferentes se confundem toda noite em toda casa. Uma é a permissão de entrar. A outra é a permissão de ser contatado depois. Uma lista de convidados carrega a primeira e quase nunca a segunda, e a distância entre as duas tem exatamente a largura de um campo.
Para lembrar
- Dar o nome para entrar não é um ato afirmativo de consentimento ao marketing.
- O campo que separa os dois é uma escolha guardada, com data e com o texto exibido.
- Acompanhantes e nomes acrescentados por terceiros não consentiram absolutamente nada.
O momento em que os dois se misturam
A lista de porta fecha à meia-noite. Quatrocentos e doze nomes, quase todos com email porque o convite funcionava assim. Na manhã seguinte alguém exporta, cola na ferramenta de envio, e a casa tem um público maior.
Nada nessa sequência parece errado, e é por isso que ela acontece. Mas volte ao que aquelas quatrocentas e doze pessoas de fato fizeram. Digitaram o nome para atravessar uma porta, numa noite específica. O ato tinha uma finalidade e a finalidade se cumpriu quando elas entraram.
O considerando 32 do GDPR diz sem rodeio: o consentimento precisa ser um ato afirmativo claro, livre, para uma finalidade determinada. Entrar numa lista é um ato afirmativo. É só um ato afirmativo sobre outra coisa.
O que cada lista é de verdade
| Lista de convidados | Lista de contatos | |
|---|---|---|
| O que a pessoa fez | Pediu para entrar, uma vez | Aceitou ouvir de você, continuamente |
| Para o que vale | Uma noite, uma porta | Até dizer o contrário |
| O que prova | O registro da porta | Uma escolha guardada, com hora e texto |
| Quem mais pode estar | Acompanhantes, nomes postos por um produtor | Só quem agiu por si |
| Quanto vale em março | Nada para quem escrever | Tudo |
| Quanto custa errar | Reclamações, denúncias de spam, domínio queimado | Nada, se o registro existir |
Leia a quarta linha duas vezes. A lista de convidados é o único documento do seu negócio que pessoas que não são o titular preenchem rotineiramente. Um produtor acrescenta doze nomes. Alguém traz dois amigos. Nenhum desses quatorze viu um formulário, muito menos uma linha de consentimento.
O campo único, e o que ele precisa conter
Não uma caixinha. Um registro.
Três coisas precisam estar na pessoa: a escolha que ela fez, o momento em que fez, e o texto exato que lhe foi mostrado então. O último é o que todo mundo pula e o único que te ajuda dois anos depois, quando alguém pergunta por que está recebendo isto. «Ela marcou uma caixinha» é uma afirmação. «Em 17 de setembro às 21h14 ela marcou uma caixinha que dizia esta frase» é um registro.
Ele também precisa ser separável. Aceitar notícias das próximas noites desta casa não é aceitar notícias dos outros três produtores que usaram a mesma ferramenta de porta. Se o dado não os distingue, juridicamente são a mesma coisa, e manda o mais fraco.
A boa notícia: a porta é um ótimo lugar para perguntar
Tudo acima soa como restrição. Na prática é o contrário, porque a porta é o momento de maior intenção que você vai ter com essas pessoas. Elas estão de pé na sua casa, numa noite que escolheram, tendo já dito sim a estar ali.
Fazer uma pergunta nesse instante converte muito melhor do que a mesma pergunta num feed três semanas depois. Basta uma pergunta, ela precisa ser opcional, e precisa dizer o que vai acontecer de verdade: fazemos mais ou menos uma noite por mês, vamos te avisar, é só isso.
Faça isso e os quatrocentos e doze nomes viram um número menor, talvez duzentos e quarenta, que vale muito mais que quatrocentos e doze porque cada um pode ser alcançado em março sem gerar reclamação.
Onde o mecanismo vive
É por isso que a superfície de RSVP e a fanbase precisam ser o mesmo sistema, e não duas exportações que se encontram numa planilha. Na HIIPE a página de RSVP coleta a inscrição, o consentimento e a origem numa única ação, e a pessoa chega na fanbase já carregando os três, então o segmento «disse sim a ser contatado, neste evento» existe sem ninguém construir.
A porta agora faz parte do mesmo objeto, em vez de ser o ponto onde o registro para. O RSVP emite um passe QR pessoal, e a entrada o escaneia por um leitor web aberto com um código próprio do evento: nada para o convidado instalar, nenhuma conta para quem está na porta criar. Esse detalhe não é conforto, é o que mantém o registro inteiro. Um scanner que vive fora do sistema produz um segundo arquivo, e um segundo arquivo é exatamente como entrada e contato acabam fundidos na mão um mês depois. Aqui a leitura grava de volta no mesmo perfil: a presença e a permissão continuam sendo dois campos distintos de uma mesma pessoa, em vez de duas listas que alguém precisa conciliar. Como as peças se conectam é o que importa.
Há um teste rápido para saber de que lado você está. Procure alguém que entrou há dois anos e veja se o sistema diz a quais outras noites essa pessoa foi. Se a resposta vem em um clique, você tem uma ficha de pessoas. Se você precisa abrir quatro eventos e comparar na mão, você tem quatro listas de porta que dividem um sobrenome, e não é a mesma coisa.
A regra, em uma linha
Entrar é uma permissão. Ser contatado é outra. Nunca deixe uma exportação misturar as duas.
Se você já tem uma pilha de listas de convidados antigas, não apague e não escreva para elas. Trate como histórico de presença, que é genuinamente útil para entender quem vai a quê, e comece o registro de consentimento a partir do próximo evento. O argumento completo sobre o último evento alimentar o seguinte está em encher o próximo evento com a lista do anterior, e como esse registro deve ser está em o que é um fan CRM.
Para ler depois : Encher o próximo evento com a lista do anterior · O que um CRM para eventos deveria fazer entre dois eventos