Guide expert
Encaisser pendant l’appel : le lien de paiement Stripe, sans numéro de carte dicté
Comment l’agent retrouve la facture, vérifie l’identité et envoie le lien
Le flux complet d’un paiement téléphonique sans carte dictée : lecture du solde dans l’ERP ou le CRM, vérification d’identité, envoi d’un lien Stripe aux coordonnées du dossier, écriture du résultat.
Le meilleur moment pour encaisser est déjà en ligne
Un client qui appelle au sujet de sa facture est un client prêt à payer. C’est l’intention la plus rare et la plus périssable d’un cycle de comptes à recevoir : elle dure le temps de l’appel.
Dans la plupart des petites et moyennes entreprises, cette intention se heurte à une organisation qui n’est pas prête à la recevoir. La personne qui répond n’a pas accès au module de facturation, ou n’a pas le droit de prendre un paiement, ou craint — avec raison — de manipuler un numéro de carte. On promet un rappel, et la facture repart pour un cycle complet.
L’objectif d’un paiement pendant l’appel n’est donc pas d’automatiser une tâche administrative. C’est de supprimer le délai entre la décision de payer et le paiement reçu.
Pourquoi la carte dictée à voix haute est la mauvaise réponse
La solution instinctive consiste à faire lire les chiffres de la carte au téléphone. Elle est encore proposée, parfois avec une mise en pause de l’enregistrement, et elle crée trois problèmes que personne ne cadre au moment de l’adopter.
- Le numéro est prononcé à voix haute, dans un bureau, souvent devant d’autres personnes.
- Il entre dans l’enregistrement d’appel et dans la transcription, donc dans votre conservation de données, vos sauvegardes et vos exports.
- Il fait entrer la ligne téléphonique, le fournisseur de téléphonie et l’outil d’enregistrement dans la portée PCI DSS, avec les obligations qui l’accompagnent.
- Une seule pause d’enregistrement mal configurée annule toute la protection, sans que personne s’en aperçoive avant un audit.
L’approche par lien : la carte n’existe jamais du côté téléphonique
L’alternative défendable est simple : l’agent ne touche jamais aux données de carte. Il identifie le dossier, confirme le montant, puis fait envoyer un lien vers une page de paiement hébergée par Stripe. Le client saisit sa carte chez Stripe, sur son téléphone, pendant l’appel ou juste après.
Ce déplacement change la nature du risque. Il n’y a plus de donnée de carte à protéger sur la ligne, dans l’enregistrement ou dans la transcription, parce qu’il n’y en a jamais eu. Ce qui circule au téléphone, c’est un numéro de facture et un montant.
Le reste de l’article décrit le flux tel qu’il est configuré chez un client de VocalOps, y compris les endroits où il doit s’arrêter.
Étape 1 — retrouver le bon montant dans le bon système
L’agent ne demande pas au client combien il doit. Il lit le dossier dans le système que vous désignez comme faisant autorité : ERP, CRM ou logiciel de facturation, selon les permissions validées pendant le cadrage.
Cette étape décide de la qualité de tout le reste. Un paiement encaissé sur un solde périmé produit un trop-payé, un crédit à émettre et un appel de plus — l’inverse exact du gain recherché.
- Quel système fait autorité sur le solde, et à quelle fréquence est-il lu?
- Que se passe-t-il si deux factures sont ouvertes pour le même client?
- Comment un paiement déjà reçu par un autre canal est-il reconnu?
- Que fait l’agent si le solde est introuvable ou si le système ne répond pas?
Étape 2 — vérifier l’identité en faisant confirmer, jamais en divulguant
Le principe est celui de la confirmation : l’agent propose un élément partiel du dossier et l’appelant le valide. Il ne lit pas l’adresse, ni le montant complet, ni l’historique à voix haute avant d’avoir une correspondance.
Le numéro d’appel entrant sert de premier indice, jamais de preuve. Un client peut appeler d’un autre téléphone, un locataire peut appeler pour un propriétaire, un employé peut appeler pour son entreprise. Chacun de ces cas mérite une règle écrite plutôt qu’une improvisation.
Le niveau de vérification se choisit selon la sensibilité du compte, et la règle de transfert après un nombre d’essais convenu fait partie de la configuration, pas de l’exception.
Étape 3 — envoyer le lien là où le dossier le dit, et nulle part ailleurs
C’est la règle la plus importante de tout le flux, et celle qui manque le plus souvent aux démonstrations. Le lien de paiement part vers le courriel ou le numéro de cellulaire déjà inscrits au dossier. Jamais vers des coordonnées dictées pendant l’appel.
Un système qui accepte « envoyez-le plutôt à cette adresse » transforme une ligne de service en canal de détournement : il suffit d’appeler en se faisant passer pour un client pour recevoir un lien rattaché à sa facture. Si une mise à jour de coordonnées est réellement nécessaire, elle suit un parcours distinct, avec une personne, et pas dans le même appel que le paiement.
L’agent reste en ligne pendant que le lien arrive. Il confirme la réception, répète où chercher, et consigne le cas si le client ne le trouve pas.
Étape 4 — écrire le résultat, et savoir quoi faire quand l’écriture échoue
Le paiement reçu par Stripe doit se retrouver dans votre système de facturation, rapproché du bon compte client. C’est la partie invisible du flux et celle qui coûte le plus cher lorsqu’elle est négligée.
Le scénario à cadrer explicitement est celui où le client a payé mais où l’écriture échoue. Il doit produire une alerte visible pour une personne, avec le montant, le client et l’identifiant du paiement — jamais un silence qui se découvre à la relance suivante, alors que le client a déjà été débité.
- Lien émis, avec la facture visée et le canal d’envoi.
- Paiement reçu chez Stripe, avec son identifiant.
- Écriture dans le système de facturation, ou échec signalé à une personne.
- Résultat inscrit à l’appel, pour que la prochaine personne n’ait pas à réécouter.
Ce que l’agent doit refuser
Un paiement est l’action la plus lourde de conséquences qu’un agent téléphonique peut déclencher. La liste des refus n’est donc pas une limite embarrassante : c’est la partie de la configuration qui protège votre entreprise.
- Aucun numéro de carte, code de sécurité ou date d’expiration; l’agent interrompt le client qui commence à les dicter.
- Aucun rabais, entente de paiement, radiation d’intérêts ni paiement partiel non prévu.
- Aucun remboursement ni annulation de paiement.
- Aucune discussion sur une contestation de montant : transfert.
- Aucun envoi de lien à des coordonnées fournies pendant l’appel.
Ce qu’il faut mesurer, et ce que cela ne réglera pas
L’indicateur utile est le délai entre l’appel et le paiement reçu, puis la part des factures réglées pendant l’appel plutôt que dans un cycle de relance. Prenez quelques semaines de base de comparaison avant le lancement, sinon vous n’aurez qu’une impression favorable.
Ce flux ne recouvre pas une créance dont le client refuse le montant, ne remplace pas une politique de crédit et ne règle pas un solde contesté. Il supprime le délai entre l’intention de payer et l’encaissement, ce qui est déjà considérable — mais il faut le décrire ainsi.
Enfin, les enregistrements et les transcriptions d’un appel de paiement contiennent des renseignements financiers. Leur emplacement, leur durée de conservation et leur suppression sont des décisions à prendre avant le premier appel, pas après un audit. Au Québec, la Loi 25 impose des obligations de minimisation et de transparence qui s’appliquent directement à ces enregistrements.