Salesforce Nonprofit Cloud : architecture d’un CRM de collecte moderne

Une équipe de collecte ne manque pas toujours de données. Elle manque souvent de tomber d'accord sur ce que ses données racontent. Un montant promis, un paiement reçu et une recette rapprochée peuvent apparaître dans trois tableaux différents, sous le même intitulé : « dons ». Avant de construire un dashboard, il faut résoudre cette ambiguïté.

Salesforce Nonprofit Cloud : commencer par les événements métier

Un CRM de collecte doit permettre de distinguer la relation avec un soutien, l’engagement de don, les transactions et l’affectation des fonds. Le modèle Fundraising de Salesforce Nonprofit Cloud comporte notamment les objets Gift Commitment, Gift Transaction et Gift Designation.

Ces objets fournissent un vocabulaire de conception ; leur présence ne remplace pas le travail sur vos règles métier.

Prenons une fondation fictive qui finance des ateliers éducatifs. Une entreprise annonce un soutien de 12 000 euros en trois échéances. Le CRM doit pouvoir raconter cet engagement, les versements effectivement reçus et leur destination.

Afficher immédiatement 12 000 euros comme argent disponible donnerait une vision trompeuse de la trésorerie.

La première question d’architecture devient donc : quel événement autorise chaque changement d’état ? Une promesse documentée ouvre un engagement. Une confirmation de paiement fait entrer une transaction dans le processus de traitement. Le rapprochement financier établit une autre information, avec sa propre preuve et sa propre date.

Définir les responsabilités des systèmes

• Salesforce peut tenir la connaissance relationnelle et les données de collecte.

• Le prestataire de paiement conserve les détails techniques du paiement.

• La comptabilité porte les écritures et leur validation.

• Une plateforme d’e-mailing exécute les campagnes et applique ses exclusions.

• Chaque système a un périmètre explicite.

Cela implique de désigner un référentiel par information. Qui peut corriger une adresse ? Où une opposition à la prospection est-elle enregistrée ? Quel système confirme un remboursement ? Ces décisions doivent être documentées avec les équipes avant de configurer les flux.

L’architecture proposée n’oblige pas à dupliquer les dossiers des bénéficiaires dans les outils de collecte. Une équipe fundraising peut suivre les financements d’un programme sans accéder aux informations individuelles des personnes accompagnées.

Trois informations, trois preuves

Information	Événement ou preuve à suivre
Engagement	Une promesse documentée.
Paiement	Une confirmation de paiement et sa référence.
Rapprochement financier	Une preuve de rapprochement, avec sa date propre.

Le tableau de bord doit distinguer engagements, encaissements et éléments à rapprocher.

Concevoir un socle que l’on peut exploiter

Pour notre fondation fictive, le premier périmètre couvre les soutiens, les campagnes, les engagements, les transactions et les affectations. À chaque échange externe, on conserve une référence stable et un statut de traitement.

Les informations utiles au suivi figurent dans le CRM ; les traces techniques détaillées ont une conservation et un accès dédiés.

Un minimum de règles suffit à rendre ce socle contrôlable : montants dans une devise définie, origine connue, références externes uniques à la bonne granularité et motifs de correction. Une clé doit distinguer les événements de paiement des identifiants de don : plusieurs événements peuvent concerner une même transaction.

Ne fusionnez pas automatiquement deux personnes parce qu’elles partagent une adresse e-mail. Les familles et les adresses collectives existent. Prévoyez une file de revue des rapprochements ambigus, avec un responsable.

Faire de la recette une preuve de fonctionnement

Les essais doivent couvrir des cas qui révèlent les failles : paiement reçu deux fois, versement partiel, remboursement, don anonyme, changement d’adresse et échec de synchronisation. Pour chacun, définissez le résultat attendu et la personne qui intervient en cas d’écart.

Le tableau de bord doit montrer les engagements, les encaissements et les éléments à rapprocher séparément. Cette séparation donne aux fundraisers et à la finance un langage commun. Elle évite de demander aux équipes de reconstruire la vérité dans Excel après chaque campagne.

Jusqu’où faut-il aller ?

Une petite organisation n’a pas nécessairement besoin de toutes les briques de l’écosystème Salesforce. Vérifiez les licences, les fonctionnalités disponibles et les besoins d’intégration dans l’environnement cible. Ne transposez pas sans analyse une recette conçue pour NPSP vers Nonprofit Cloud : les modèles ne sont pas interchangeables.

Chez GenerosIT, nous proposons de cadrer le processus, la donnée et les responsabilités avant de choisir les automatisations. Le Diagnostic Générosité Augmentée™ aide à situer les priorités. Le bon premier projet est celui dont l’équipe sait expliquer le fonctionnement et traiter les exceptions.

Pour avancer : choisissez une campagne et dessinez le parcours d’un engagement jusqu’au rapprochement. Repérez les changements d’état sans preuve. Découvrez notre approche sur generosit.fr.

Référence technique

Salesforce Developers — Fundraising Data Model. Le schéma de cet article est une proposition d’architecture, pas la reproduction du modèle complet Salesforce.

Mots-clés : Salesforce Nonprofit Cloud · Salesforce Nonprofit Cloud collecte · CRM de collecte · Gift Commitment · Gift Transaction.