Après l'envoi

Les trente secondes entre le moment où un visiteur touche Envoyer et le buzz du téléphone de votre équipe d'accueil — c'est là que le formulaire de visiteur gagne sa place. Beaucoup de choses se passent dans ce creux, presque tout invisible au visiteur. Cette page parcourt la chaîne — ce qui est écrit, ce qui se déclenche, et comment vous câblez chaque pièce à votre vrai flux de suivi.

L'écriture atomique

Quand un visiteur envoie le formulaire, le navigateur appelle une seule fonction Postgres — submit_visitor_form — qui fait tout dans une seule transaction. Soit chaque ligne atterrit avec succès, soit aucune ne le fait. Cela compte parce que les fiches de visiteur à moitié écrites étaient le bug le plus courant que nous avons eu à pourchasser avant le lancement : une ligne de membre sans photo, ou de la présence sans membre, ou une valeur de champ personnalisé pointant vers rien.

En un seul appel, la fonction :

1. Valide le code d'accès s'il y en a un (voir Protection par code d'accès).
2. Insère le membre dans la table members avec le bon ID d'org et un type de membre Visiteur (recherché depuis member_types où is_default_visitor = true).
3. Stocke l'URL de la photo sur members.photo après que le téléversement vers le bucket de stockage member-photos se termine.
4. Écrit les valeurs des champs personnalisés dans member_field_values — une ligne par champ personnalisé rempli, plus les champs intégrés wants_visit, wants_prayer et prayer_request.
5. Affecte l'unité hiérarchique si le visiteur a choisi un campus ou une branche (voir Hiérarchie et présence).
6. Insère la ligne de présence si le visiteur a coché la bascule « Je suis ici aujourd'hui ».

La fonction est SECURITY DEFINER, c'est ainsi que les visiteurs anonymes peuvent écrire dans des tables qui exigent normalement une session authentifiée — RLS les rejetterait sinon. Tout le cadrage par org se passe à l'intérieur de la fonction elle-même.

Le nouveau visiteur apparaît

En une seconde ou deux après l'envoi, la nouvelle fiche du visiteur est visible à trois endroits :

• Membres → Tous les membres, avec la photo, le nom, le téléphone et une puce de type de membre indiquant Visiteur. L'horodatage « enregistré aujourd'hui » est défini.
• Tableau de bord → widget Nouveaux visiteurs, avec la photo bien visible et le nom de l'inviteur en dessous si le visiteur a rempli « Qui vous a invité ? »
• Présence → Services d'aujourd'hui (seulement si la bascule de présence était activée), regroupés sous la réunion qu'ils ont choisie.

Tout le monde avec la permission members.read pour votre org voit la nouvelle fiche. Les pasteurs et bergers cadrés à une unité hiérarchique spécifique ne voient que les visiteurs affectés à cette unité.

Le déclencheur de workflow

Le formulaire de visiteur est l'un des points d'entrée de workflow les plus courants dans GCM. Tout workflow avec un déclencheur membre créé se déclenche automatiquement quand la nouvelle fiche atterrit. La plupart des églises en mettent au moins un en place :

• Workflow de message de bienvenue — envoyer un WhatsApp ou un SMS dans les cinq minutes pour remercier le visiteur et lui donner des informations sur les prochaines étapes.
• Workflow d'assignation de berger — affecter automatiquement un pasteur ou un partenaire de suivi en fonction du campus, de la tranche d'âge ou du statut familial du visiteur.
• Workflow de notification du dimanche matin — pinger le chat de groupe de l'équipe d'accueil avec le nom et la photo du visiteur.

Vous construisez ceux-ci dans Workflows. Le déclencheur à rechercher est Membre créé, et la plupart des églises le filtrent davantage avec une condition : member_type = visitor. De cette façon, le workflow ne se déclenche que pour les nouveaux visiteurs, pas quand un membre est créé à partir d'une importation CSV ou par un membre du personnel.

Si vous voulez qu'il se déclenche uniquement pour les visiteurs venus via le formulaire (pas les visiteurs créés autrement), filtrez sur date_of_registration = today et la source de l'enregistrement. Les conditions granulaires sont documentées sous Déclencheurs de workflow.

Notifications au personnel

Le chemin le plus rapide entre « le visiteur a envoyé » et « quelqu'un du personnel le sait » est le module messaging. Deux motifs que nous voyons le plus :

Ping de groupe WhatsApp

Configurez un workflow qui, sur membre-créé avec type de membre visiteur, envoie un message WhatsApp templaté au groupe de votre équipe d'accueil :

Nouveau visiteur : {{member.full_names}} ({{member.primary_phone}}) — campus {{member.unit_name}}. Photo : {{member.photo_url}}

Réglez-le comme un envoi de groupe vers l'ID de chat WhatsApp de votre équipe d'accueil. Les pasteurs reçoivent le ping sur leurs téléphones avant que le visiteur ne se soit relevé de son siège.

Digest e-mail

Si un ping en temps réel semble trop agressif, exécutez un workflow de digest à 23h quotidien qui envoie par e-mail les visiteurs du jour au responsable de l'accueil. Même déclencheur (membre créé, type visiteur), mais au lieu de se déclencher immédiatement, le workflow met en mémoire tampon et envoie un seul e-mail par jour.

Les deux motifs sont documentés de bout en bout dans la recette premier visiteur.

Le chemin de conversion

Un visiteur n'est pas encore un membre. La ligne entre les deux est une que votre église trace — après une visite ? Trois ? Quand ils passent par un cours de fondements ? Quand un pasteur décide ? GCM n'impose pas de règle.

Ce que nous recommandons :

• Laissez le type de membre comme Visiteur pour tous ceux qui entrent via le formulaire, sans mise à niveau automatique.
• Construisez un workflow de visiteur récurrent qui se déclenche quand un visiteur atteint trois services présents. Le workflow peut pinger un berger pour les appeler, ou les faire remonter sur une tuile de tableau de bord « prêts à convertir ».
• Faites changer le type de membre à Membre par les bergers manuellement, après une conversation. Le changement est journalisé dans les journaux de données pour que vous puissiez l'auditer plus tard.

Cela maintient l'étape sociale (décider que quelqu'un fait maintenant partie de la famille de l'église) entre les mains d'un humain, tandis que l'étape de données (création de la fiche, suivi de la présence, envoi des accueils) est entièrement automatisée.

Échecs et nouvelles tentatives

Le formulaire tolère les coupures — si le téléphone du visiteur a une mauvaise réception, l'envoi est mis en file d'attente localement et réessayé quand le réseau revient. Si le code d'accès est faux, le visiteur voit une erreur claire et a une autre chance.

L'échec le plus courant est les doublons : le même visiteur remplit le formulaire deux fois d'affilée (son premier envoi semblait bloqué donc il a tapé Envoyer à nouveau). Les deux envois passent ; vous vous retrouvez avec deux fiches de visiteur pour la même personne.

Pour les nettoyer : ouvrez le profil du visiteur en double, faites défiler jusqu'à Fusionner → choisissez la fiche canonique. Les valeurs des champs personnalisés, la présence et la photo se consolident toutes sur la fiche survivante. La plupart des églises font cela le lundi matin dans le cadre du bilan standard de l'équipe d'accueil.

Où aller ensuite

• Déclencheurs de workflow — le catalogue des événements que les workflows peuvent écouter.
• Messaging — envoyer le vrai WhatsApp ou e-mail de bienvenue.
• Recette premier visiteur — un exemple travaillé reliant le formulaire à un message de bienvenue et à une assignation de berger.
• Retour à Aperçu du formulaire de visiteur.