Formulaire web et Pipedrive : transmettre chaque demande

Un client envoie une demande de devis depuis son espace B2B. Le site affiche une confirmation, mais le commercial ne retrouve aucun lead. Le client clique de nouveau et deux tâches apparaissent. Le risque commence dès que le site confirme la demande sans conserver une référence que le support pourra retrouver dans le CRM.

Enregistrez la demande côté site, réutilisez sa référence si le navigateur renvoie le formulaire et suivez chaque écriture Pipedrive séparément. Le programme Python illustre la partie CRM pour un compte déjà identifié. Il crée ou réutilise le contact, crée le lead et rattache une activité. Les 48 tests de l’archive couvrent ce flux et quatre autres parcours sur des données fictives.

Pour connecter votre formulaire à Pipedrive, décidez avec le commerce quels comptes sont qualifiés, qui reçoit l’activité et où retrouver les demandes en attente. Consignez ces responsabilités avec les autres flux d’intégration du CRM.

Vérifier si le formulaire natif suffit

Les Web Forms de Pipedrive font partie de LeadBooster. Ils permettent de collecter des demandes sous forme de leads ou d’affaires et leur configuration requiert les droits d’administration des affaires. Vérifiez si les champs proposés, l’attribution des demandes et le suivi commercial couvrent votre besoin.

Un formulaire spécifique se justifie lorsque le site possède déjà son identité utilisateur, ses règles d’accès, ses données de compte ou un parcours de qualification que l’outil choisi ne couvre pas. Un connecteur standard ou une plateforme d’automatisation peut aussi convenir. Il faut alors vérifier le comportement sur doublon, interruption et reprise, au même titre que le mapping nominal.

Recevoir la demande avant de lancer le flux CRM

Le programme traite les demandes d’un utilisateur B2B reconnu côté serveur et relié à un compte ERP. Une demande de devis entre dans la boîte des leads pour qualification. Pour un prospect anonyme ou une société sans correspondance, l’équipe retrouve la demande côté site et qualifie le compte avant l’écriture CRM.

Enregistrez la soumission dans le stockage du site avant de confirmer sa réception au navigateur. Planifiez ensuite le traitement asynchrone à partir de cet enregistrement. L’archive commence au moment où la soumission arrive au connecteur. Le journal SQLite y conserve l’empreinte des données d’entrée et les résultats des écritures. L’interface web, la file d’attente et le stockage du message restent à implémenter sur votre site.

Si le site peut enregistrer la demande et sa mise en file dans la même transaction, le worker retrouvera le travail même après un arrêt entre l’enregistrement et l’appel CRM. Pour une file externe, une table de tâches à transmettre (outbox) peut jouer ce rôle. La référence de la demande figure dans la réponse affichée au client et dans la tâche du worker. Le statut « reçue » correspond à la validation côté site. Passez à « lead créé » lorsque Pipedrive a renvoyé un ID ou que le support a vérifié cet ID.

Résoudre le compte avant de chercher un contact

Le serveur attribue une référence à la demande et la réutilise en cas de répétition de la requête. Rattachez cette référence à la session ou au compte autorisé. Le serveur détermine lui-même l’organisation, le contact et le commercial à partir de ses correspondances, y compris si le navigateur envoie des identifiants dans le formulaire.

Dans l’exemple, ERP-C041 est relié à l’organisation fictive 42. Une identité du site peut correspondre à une fiche existante ou avoir reçu l’autorisation de créer un contact. La table identities empêche de réaffecter une référence connue à une autre fiche. Pour un connecteur partagé, rattachez aussi les clés du journal à la société Pipedrive autorisée.

store.bind("account", "ERP-C041", 42)
# Si le rapprochement existant est prouvé :
store.bind("contact", "portal-user-1", 11)

# Pour une autre identité, réellement nouvelle et qualifiée :
store.bind("new-contact-approved", "portal-user-2", "yes")

Garder une identité stable lorsque l’email change

Une adresse email peut changer ou être partagée. Avant d’ouvrir le formulaire, rapprochez les utilisateurs existants avec les contacts du compte. La recherche de personnes peut proposer des candidats par email et organisation. Faites vérifier la correspondance par l’équipe commerciale avant d’inscrire l’ID CRM dans le registre.

Par exemple, deux acheteurs peuvent partager achats@example.test. Si l’un possède déjà une identité reliée au contact 11, alors cette correspondance reste la référence pour ses demandes. Le second acheteur reste à qualifier tant que son identité n’est pas établie. Une demande en attente doit conserver le compte proposé et le motif du blocage. Quand le commercial approuve une fiche, le worker reprend la même soumission et relit le compte de cette personne.

Si la personne déjà rapprochée appartient désormais à une autre organisation, le traitement s’arrête. Un changement de société, une fusion CRM ou une erreur de compte demande une décision. Le cas sur la fusion d’organisations et le compte ERP à conserver explique pourquoi un rattachement automatique peut déplacer le problème vers la facturation.

Créer le lead et lier la première activité

Le client HTTP utilise un token API dans l’en-tête x-api-token. Chargez-le côté serveur depuis un stockage privé. Le client refuse les redirections pour éviter d’envoyer ce secret à une autre destination. Les commandes de démonstration utilisent des réponses simulées.

Créez la personne avec POST /api/v2/persons et les champs name, emails, org_id et owner_id. La création du lead utilise POST /api/v1/leads avec organization_id. Le test de mapping vérifie que le lead reçoit bien le compte fictif 42 dans ce champ.

lead_body = {
    "title": title,
    "person_id": int(person),
    "organization_id": int(org),
    "owner_id": self.owner_id,
}
lead = self.store.effect(
    "lead/" + submission_id,
    lead_body,
    lambda: created(self.api, "/api/v1/leads", lead_body),
)

Lier l’activité au bon objet

Le lead doit être lié à une personne ou à une organisation, comme le précise la référence Leads. Le programme conserve l’identifiant retourné, puis crée une activité avec POST /api/v2/activities. Elle porte le lead_id, le propriétaire et les participants ; le participant principal désigne la personne selon le contrat v2 consulté.

L’activité de démonstration n’a pas de date imposée. La production doit définir son échéance avec l’équipe commerciale, son fuseau et son calendrier. Un type d’activité valide et un propriétaire actif font partie des prérequis de recette. La documentation Activities permet de vérifier les champs effectivement acceptés.

Dans le contrat d’entrée, identifiez le payload minimal pour chaque écriture REST et la sortie attendue. Le lead renvoie un UUID et l’activité renvoie son propre identifiant. Ajoutez ces références à la trace de la soumission pour que le support puisse ouvrir les deux objets. Si votre intégration utilise OAuth, associez la connexion à la société autorisée avant de résoudre les identifiants du compte.

Protéger chaque effet, même après un redémarrage

La protection ne repose pas sur une liste d’identifiants en mémoire. La table effects garde une clé unique, l’empreinte du corps envoyé, l’état de traitement et le résultat connu. Une réservation est validée avant l’appel HTTP ; aucune transaction SQL n’est maintenue ouverte pendant le réseau.

Deux workers qui partagent la même base SQLite ne peuvent pas réserver le même effet. Si une soumission confirmée revient après réouverture de la base, le résultat conservé est rendu sans nouvel appel. Si la même référence revient avec un titre ou un email différent, le programme signale un conflit. Pour corriger une demande déjà reçue, rapprochez-la du lead initial et traitez la correction sur ce dossier. Attribuez une nouvelle référence à une nouvelle demande.

L’idempotence s’applique à plusieurs niveaux. La création de personne utilise person/<identité>. Le lead et l’activité utilisent chacun la référence de la soumission. Ainsi, deux demandes distinctes du même acheteur peuvent partager un contact et obtenir chacune leur suivi. Si les workers disposent chacun de leur propre base, alors les deux peuvent réserver la même clé. Utilisez un journal partagé avec une contrainte d’unicité et testez la réservation concurrente avant de répartir la charge.

Résoudre une réponse manquante avant de poursuivre

Si la réponse est perdue après le POST, l’écriture a peut-être réussi. Le support ouvre l’étape bloquée à partir de la référence de soumission et cherche la fiche dans la société Pipedrive concernée. Pour un lead, une référence de soumission enregistrée dans un champ personnalisé recherchable peut aider au rapprochement. Testez sa recherche et les droits de lecture avant le pilote. Le programme n’ajoute pas ce champ au lead.

Lorsque le support a confirmé la fiche distante et vérifié que le worker initial a terminé, il consigne l’ID et la preuve. L’extrait suivant montre la résolution d’un POST de création de personne dans un scénario distinct où portal-user-1 était une nouvelle identité approuvée.

store.resolve(
    "person/portal-user-1",
    {"id": 11},
    "Rapprochement vérifié par l’opérateur dans le compte de démonstration",
)

Si la fiche reste introuvable, conservez l’étape en attente tant que le résultat du POST est incertain. L’absence de résultat dans une recherche peut venir du périmètre ou des droits de lecture. Prévoyez une procédure contrôlée pour réautoriser l’écriture lorsqu’une preuve établit que la demande initiale a été refusée. Une réservation pending peut encore appartenir à un worker actif.

Paradoxalement, après un timeout, créer un lead de secours peut laisser deux commerciaux traiter la même demande. Pour tester ce cas, simulez la perte de réponse après l’acceptation du POST par le serveur. Mesurez le délai de rapprochement à partir de la référence. Si le support ne peut pas retrouver le résultat avant le seuil convenu avec le commerce, maintenez le dossier dans la file et prévenez le responsable du suivi.

Choisir qui crée l’activité de suivi

Le programme crée l’activité par API. Excluez ces leads du périmètre d’une règle native qui créerait la même tâche. Testez avec le propriétaire réel du lead et vérifiez qu’une seule activité apparaît dans son agenda.

Si vous confiez l’activité à Pipedrive, retirez l’étape API correspondante et testez la règle avec les valeurs réellement envoyées. Un lead créé par API peut déclencher une automatisation déjà active lorsque ses conditions sont satisfaites. Si la règle cible un propriétaire, vérifiez le propriétaire attribué par l’API. Vérifier les conditions de déclenchement dans Pipedrive.

Un lead présent et une activité absente ne prouvent donc pas une panne de transport. Comparez le propriétaire, la visibilité, le déclencheur et l’historique de la règle. Évitez de recréer le lead pour essayer de déclencher la tâche : vous transformerez un problème de condition en problème de données.

Si une règle native crée aussi l’activité, alors un seul POST du connecteur peut suffire à produire deux tâches. Pour le reproduire en recette, activez la règle sur le compte de test, envoyez la demande et comparez l’historique de l’automatisation au journal API. Si vous retenez la règle native, convenez d’un délai de suivi. Le tableau de supervision doit faire remonter les leads confirmés dont l’activité reste absente passé ce délai.

Reproduire les résultats et les échecs

Télécharger le code et les tests des cinq parcours, puis extraire l’archive. Python 3.11 ou supérieur suffit ; aucune bibliothèque n’est à installer. La démonstration utilise un dossier temporaire et n’appelle pas Pipedrive.

python3 demo.py
python3 test_integration.py -v

Dans la sortie de demo.py, le bloc form affiche un lead fictif dont l’UUID se termine par 0070 et l’activité 3. La valeur repeat_creates_nothing: true confirme que la seconde soumission renvoie le même résultat sans création supplémentaire. Les tests couvrent aussi la réouverture de la base et la réservation depuis une seconde connexion SQLite.

Pour la recette distante, rejouez ces scénarios avec des données de démonstration. Vérifiez les droits de lecture et d’écriture, le type d’activité et les règles natives actives sur le compte autorisé. Retrouvez la gestion des réponses et erreurs dans notre tutoriel SDK Pipedrive pour Symfony.

Plan d’action et erreurs fréquentes à l’ouverture

Une demande confirmée par le site et absente du CRM doit être retrouvable dans la file de qualification. Un lead confirmé et sans activité doit faire l’objet d’une vérification du propriétaire et du déclencheur. Pour diagnostiquer ces deux alertes, rattachez les états au même identifiant de soumission.

Le serveur contrôle les droits, les champs autorisés et les protections anti-abus. Dans les logs, conservez la référence, l’état du traitement et la décision prise. Réservez le message du prospect au dossier auquel l’équipe autorisée peut accéder.

Commencer par les comptes rapprochés

Ouvrez d’abord le parcours sur un groupe de comptes rapprochés. Mesurez demandes reçues, demandes à qualifier, leads confirmés et activités réellement accessibles au propriétaire. Le coût de support dépend surtout du temps nécessaire pour retrouver une entrée bloquée ; une alerte sans référence de soumission oblige à rechercher dans plusieurs outils.

1. Soumettez deux fois la même demande. Retrouvez une seule demande côté site et un seul lead dans le CRM.
2. Envoyez une demande depuis un compte inconnu. Vérifiez son apparition dans la file de qualification et attribuez un responsable.
3. Contrôlez que le commercial voit l’activité avec le bon lead et le délai attendu.
4. Simulez une réponse perdue. Demandez au support de retrouver le résultat et de reprendre le flux à partir de sa preuve.

Le cadre des accès, des objets et des réponses incertaines figure dans notre guide d’intégration API Pipedrive. Pour un portail déjà connecté, le cas Pipedrive et e-commerce B2B décrit la qualification des signaux qui peuvent devenir une opportunité. Retrouvez les règles entre plusieurs sources dans notre guide de synchronisation CRM.

Conclusion : conserver la demande et prouver le suivi

Avant l’ouverture, le support doit pouvoir partir d’une référence du site et retrouver la demande, le lead confirmé ou le motif qui bloque encore le transfert. Le journal doit indiquer la dernière écriture confirmée pour que le support reprenne au bon endroit.

Pour accepter le flux, vérifiez qu’une soumission répétée rend le même résultat, qu’une identité inconnue apparaît en qualification et qu’une réponse perdue suspend la création jusqu’au rapprochement. Contrôlez ensuite la tâche dans l’agenda du commercial qui doit la traiter.

Pour cadrer une connexion Pipedrive sur mesure, Dawap peut vous aider à établir les correspondances avec vos comptes existants, à attribuer les demandes au bon commercial et à tester les reprises avant d’ouvrir le formulaire.