Depois do envio

Os trinta segundos entre um visitante tocar Enviar e o telefone da sua equipe de boas-vindas vibrar é onde o formulário de visitante prova seu valor. Muita coisa acontece nesse vão, quase tudo invisível para o visitante. Esta página percorre a cadeia — o que é escrito, o que é disparado e como você conecta cada peça ao fluxo real de acompanhamento da sua igreja.

A escrita atômica

Quando um visitante envia o formulário, o navegador chama uma função do Postgres — submit_visitor_form — que faz tudo em uma única transação. Ou toda linha aterrissa com sucesso ou nenhuma aterrissa. Isso importa porque registros de visitante escritos pela metade eram o bug pré-lançamento mais comum que tivemos que perseguir: uma linha de membro sem foto, ou presença sem membro, ou um valor de campo personalizado apontando para nada.

Em uma chamada, a função:

1. Valida o código de acesso se um estiver configurado (veja Proteção por código de acesso).
2. Insere o membro na tabela members com o ID de org certo e um tipo de membro Visitante (consultado de member_types onde is_default_visitor = true).
3. Armazena a URL da foto em members.photo depois que o upload para o bucket de armazenamento member-photos termina.
4. Escreve valores de campos personalizados em member_field_values — uma linha por campo personalizado preenchido, mais os campos embutidos wants_visit, wants_prayer e prayer_request.
5. Atribui a unidade hierárquica se o visitante escolheu um campus ou filial (veja Hierarquia e presença).
6. Insere a linha de presença se o visitante marcou o toggle "Estou aqui hoje".

A função é SECURITY DEFINER, que é como visitantes anônimos conseguem escrever em tabelas que normalmente exigem uma sessão autenticada — RLS iria rejeitá-los caso contrário. Todo o escopamento por org acontece dentro da própria função.

O novo visitante aparece

Em um segundo ou dois após o envio, o novo registro do visitante fica visível em três lugares:

• Membros → Todos os membros, com a foto, nome, telefone e um chip de tipo de membro lendo Visitante. O carimbo de "registrado hoje" é definido.
• Painel → widget Novos visitantes, com a foto em destaque e o nome de quem convidou embaixo se o visitante preencheu "Quem te convidou?".
• Presença → Serviços de hoje (apenas se o toggle de presença estava ligado), agrupados sob qualquer reunião que ele tenha escolhido.

Todos com a permissão members.read para sua org veem o novo registro. Pastores e pastores de cuidado com escopo em uma unidade hierárquica específica só veem visitantes atribuídos àquela unidade.

O gatilho de workflow

O formulário de visitante é um dos pontos de entrada de workflow mais comuns no GCM. Qualquer workflow com um gatilho membro criado dispara automaticamente quando o novo registro aterrissa. A maioria das igrejas configura pelo menos um:

• Workflow de mensagem de boas-vindas — enviar um WhatsApp ou SMS em cinco minutos agradecendo ao visitante e dando informação sobre próximos passos.
• Workflow de atribuição de pastor de cuidado — atribuir automaticamente um pastor ou parceiro de acompanhamento baseado no campus, faixa etária ou status familiar do visitante.
• Workflow de notificação de domingo de manhã — pingar o chat de grupo da equipe de boas-vindas com o nome e a foto do visitante.

Você constrói esses em Workflows. O gatilho a procurar é Membro criado, e a maioria das igrejas o filtra ainda mais com uma condição: member_type = visitor. Dessa forma o workflow só dispara para novos visitantes, não quando um membro é criado a partir de uma importação CSV ou por um membro da equipe.

Se você só quer que dispare para visitantes que vieram pelo formulário (não visitantes criados de outra forma), filtre por date_of_registration = today e a fonte do registro. As condições granulares estão documentadas em Gatilhos de workflow.

Notificações para a equipe

O caminho mais rápido entre "visitante enviou" e "alguém da equipe sabe" é o módulo messaging. Dois padrões que vemos mais:

Ping de grupo no WhatsApp

Configure um workflow que, no membro-criado com tipo de membro visitante, envia uma mensagem WhatsApp em modelo para o grupo da sua equipe de boas-vindas:

Novo visitante: {{member.full_names}} ({{member.primary_phone}}) — campus {{member.unit_name}}. Foto: {{member.photo_url}}

Configure como envio para grupo para o ID de chat WhatsApp da sua equipe de boas-vindas. Os pastores recebem o ping no celular antes do visitante ter se levantado do banco.

Digest por e-mail

Se um ping em tempo real parece muito agressivo, rode um workflow de digest diário às 23h que envia por e-mail os visitantes do dia para o líder de boas-vindas. Mesmo gatilho (membro criado, tipo visitante), mas em vez de disparar imediatamente, o workflow acumula e envia um único e-mail por dia.

Ambos os padrões estão documentados de ponta a ponta na receita do primeiro visitante.

O caminho de conversão

Um visitante ainda não é um membro. A linha entre os dois é uma que sua igreja desenha — depois de uma visita? Três? Quando passa por uma aula de fundamentos? Quando um pastor decide? O GCM não impõe uma regra.

O que recomendamos:

• Deixe o tipo de membro como Visitante para todos que entram pelo formulário, sem upgrade automático.
• Construa um workflow de visitante retornante que dispara quando um visitante atinge três serviços frequentados. O workflow pode pingar um pastor de cuidado para ligar para eles, ou exibi-los em um tile de painel "prontos para converter".
• Faça os pastores de cuidado mudarem o tipo de membro para Membro manualmente, depois de uma conversa. A mudança é registrada nos logs de dados para que você possa auditá-la depois.

Isso mantém o passo social (decidir que alguém agora é parte da família da igreja) nas mãos de um humano, enquanto o passo de dados (criar o registro, rastrear presença, enviar boas-vindas) é totalmente automatizado.

Falhas e novas tentativas

O formulário tolera offline — se o telefone do visitante tem recepção ruim, o envio é enfileirado localmente e tenta novamente quando a rede volta. Se o código de acesso está errado, o visitante vê um erro claro e tem outra chance.

A falha mais comum é duplicatas: o mesmo visitante preenche o formulário duas vezes seguidas (o primeiro envio parecia travado então tocou Enviar de novo). Ambos os envios passam; você acaba com dois registros de visitante para a mesma pessoa.

Para limpar esses: abra o perfil do visitante duplicado, role até Mesclar → escolha o registro canônico. Valores de campos personalizados, presença e foto se consolidam no registro sobrevivente. A maioria das igrejas faz isso na manhã de segunda como parte da revisão padrão da equipe de boas-vindas.

Para onde ir em seguida

• Gatilhos de workflow — o catálogo de eventos que workflows podem escutar.
• Messaging — enviando o WhatsApp ou e-mail de boas-vindas de verdade.
• Receita do primeiro visitante — um exemplo trabalhado ligando o formulário a uma mensagem de boas-vindas e a uma atribuição de pastor de cuidado.
• Voltar para Visão geral do formulário de visitante.