La plupart des programmes de parrainage commencent par un tableur, et pour quelques contrats par an, un tableur constitue une solution tout à fait acceptable. Mais à un moment donné, ce n'est plus le cas, et il est utile de savoir à quel moment exactement.
La première chose qu’un tableur ne peut pas faire, c’est recevoir. Les demandes arrivent par e-mail, via un formulaire de contact, par l’intermédiaire d’un collègue qui connaît quelqu’un, et parfois lors d’un événement. Quelqu’un doit les transcrire dans des lignes. Ce qui n’est pas transcrit reste invisible, c’est pourquoi les programmes gérés de cette manière ont tendance à découvrir des demandes auxquelles ils n’ont jamais répondu.
Le deuxième élément est la traçabilité des décisions. Une cellule enregistre le résultat, mais pas qui a pris la décision, sur quelle base ni à quel moment. Cela ne pose pas de problème tant qu’il n’est pas nécessaire d’expliquer cette décision : à un collègue qui reprend le dossier, au service financier au moment de l’élaboration du budget, ou à une organisation qui demande pourquoi une demande a été refusée alors qu’une autre, comparable, a été financée.
Le troisième point concerne ce qui se passe après la signature. Les droits acquis sont consignés dans un contrat, les livrables dus se trouvent dans une boîte de réception, et la trace de ce qui a effectivement été livré n'apparaît nulle part. Les équipes s'en rendent généralement compte au moment de l'établissement des rapports, lorsqu'il faut reconstituer les éléments à partir de leurs souvenirs.
Il y a également le problème des versions, qui tient moins à l'outil qu'à l'équipe. Dès que deux personnes modifient les données relatives au parrainage, ou qu'un bureau local tient son propre fichier, il n'y a plus de réponse unique quant au montant du budget engagé. Chaque consolidation se transforme alors en un travail de rapprochement manuel, qui intervient généralement au pire moment de l'année.
Ce qui remplace le tableur, ce n’est pas un système monolithique, mais trois fonctionnalités : un point d’entrée unique pour les demandes, une décision consignée avec le nom d’un responsable de l’approbation, et un espace où les livrables et les dépenses sont regroupés avec le contrat auquel ils se rapportent. Un programme qui dispose de ces trois éléments peut continuer à utiliser un tableur pour l’analyse, ce pour quoi les tableurs sont véritablement efficaces.
Une limite à ne pas négliger : changer d'outil ne résout pas l'absence de processus. Si personne n'a défini par écrit les critères d'éligibilité d'une demande ni déterminé qui doit l'approuver au-delà d'un certain montant, une plateforme ne fera que reproduire plus rapidement cette même improvisation. Définissez d'abord les règles, puis intégrez-les dans l'outil.
Une plateforme de gestion des partenariats ( Gestion du sponsoring ) couvre ces trois aspects : des formulaires de demande personnalisés avec des règles d'éligibilité, un processus d'approbation automatisé avec des autorisations attribuées aux évaluateurs, ainsi que le suivi de l'activation, des livrables et du budget pour chaque dossier de.