• Accueil / Salesforce / Utilisation de l’automatisation…
, Utilisation de l&rsquo;automatisation pour gérer le cycle de vie des leads &#8211; Admin Hero<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Utilisation de l’automatisation pour gérer le cycle de vie des leads – Admin Hero8 minutes de lecture


Un billet d’invité par Kristi Campbell.

L’une des meilleures choses pour moi en tant qu’administrateur Salesforce est que je peux me familiariser avec des choses comme l’optimisation des processus – des points bonus quand cela est lié à l’automatisation de ces processus via Salesforce! Il peut être difficile, cependant, d’apprécier les étapes progressives que vous prenez lorsqu’un processus ne semble toujours pas «terminé». L’un de ces processus en constante évolution dans ma vie d’administrateur en ce moment concerne le cycle de vie des leads.

Un peu de contexte – lorsque je suis entré dans cette entreprise, il y avait une variété de systèmes de vente en place. Nous avions acquis une poignée d’entreprises, chacune ayant apporté des sièges de Salesforce, Pardot, ainsi qu’un outil de partenaire externe local dans le mix. L’une de mes premières tâches majeures a été de faciliter la consolidation en une seule instance de Salesforce, intégrée à une instance de Pardot, et de lancer une communauté de partenaires pour remplacer notre outil local. Bien que cela nous donne une source de vérité (hourra!), Cela a également introduit de nouvelles questions liées au processus Lead que nous devons aborder:

  • Traitons-nous les prospects différemment lorsque nous les créons et les attribuons à un partenaire par rapport aux prospects qu’ils entrent eux-mêmes?
  • Dans quelle fenêtre de temps devrions-nous nous attendre à ce que les partenaires agissent sur leurs pistes, et comment peuvent-ils au mieux mettre à jour les enregistrements pour nous montrer que des mesures ont été prises? Réattribuons-nous automatiquement les prospects qui ne montrent pas cette action dans un délai donné?
  • Autorisons-nous les partenaires à exporter des enregistrements dans leur propre CRM et / ou voulons-nous proposer de construire des intégrations?
  • Comment gérons-nous les leads répétés? Une fois que nous attribuons un lead à un partenaire, est-ce qu’il «possède» le lead tout au long de la vie de l’engagement avec le prospect?

La dernière question est celle sur laquelle nous allons nous concentrer ici. Avec une variété de livres blancs, de webinaires et d’engagements à des salons, il existe souvent de nombreux points de contact avec un prospect avant qu’il n’atteigne le point de basculement vers un achat.

J’ai d’abord été confronté à cette question après notre premier grand salon depuis la consolidation de l’organisation. Nous avions un outil de déduplication en place (criez à Clouddingo!), j’ai donc pu identifier facilement les enregistrements existants (heureusement), mais comment signaler la répétition à leurs propriétaires actuels?

Notre décision initiale a été de mettre à jour leur Statut du lead à New, car nous savions que les partenaires examinaient activement leurs nouvelles pistes. Mais nous, en tant qu’administrateurs, n’aimions pas cette solution et, finalement, bon nombre de nos partenaires non plus; ils ont estimé que c’était déroutant, surtout sans moyen d’identifier facilement quels prospects étaient vraiment nouveaux ou répétés.

Ainsi, nous avons entamé l’évolution d’une nouvelle Revisiter formule de case à cocher sur les leads. Cela a commencé assez simple:

NOT(ISPICKVAL(Status, "New")) && 
NOT( ISBLANK( Last_Status_Change_Date__c ) ) && 
OR(LastModifiedDate > (Last_Status_Change_Date__c + 1) ,DATEVALUE(LastModifiedDate) > (LastActivityDate + 1)) && 
OR(LastModifiedBy.ProfileId = "00e30000000eyco",LastModifiedBy.ProfileId = "00e800000011uFU" /*Profiles for Sys Admin and Robots*/)

Décomposons cela:

  • Premièrement, une piste ne peut être marquée pour une nouvelle visite que si elle n’est pas nouvelle. S’il est déjà nouveau, il est déjà sur votre radar, il devrait donc être activement travaillé.
  • Le facteur clé suivant était le dernier changement de statut du prospect, étant donné que nous supposons qu’il n’est pas nouveau. Pour définir cela, nous avons créé un champ Date / Heure appelé Date du dernier changement de statut, qui est mis à jour via une règle de workflow rapide

, Utilisation de l&rsquo;automatisation pour gérer le cycle de vie des leads – Admin Hero<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Avec une action de mise à jour immédiate sur le terrain

, Utilisation de l&rsquo;automatisation pour gérer le cycle de vie des leads – Admin Hero<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Pour les enregistrements existants qui n’avaient pas encore été mis à jour, j’ai rempli une date pour que la formule ait quelque chose à partir duquel travailler.

  • À partir de là, nous comparons cette date à une variété d’autres champs de date ou d’heure du système pour voir quelle autre action a été entreprise sur le prospect: Est-ce que LastModifiedDate est plus récent? La LastActivityDate est-elle plus récente? Pour plus d’informations sur la différence entre ces deux dates et comment chacune est calculée, cliquez ici.
  • Enfin, s’il a été modifié, qui a fait les modifications? Si le propriétaire ou un autre utilisateur commercial est celui qui a effectué le changement, nous supposons par nature qu’il s’engage avec le prospect et qu’il n’a pas besoin de le signaler. Si l’administrateur ou l’un de nos utilisateurs automatisés de Robot a effectué la modification la plus récente, nous souhaitons la signaler.

Note bonus: En apprenant à commenter du code, j’ai appris à commenter des formules! le /* Remarque */ vous voyez ci-dessus m’aide à me souvenir des identifiants que j’ai inclus pour cette formule.

C’était un bon début! Nous avons créé une vue et un rapport appelés autour de la nouvelle case à cocher et avons conseillé à nos utilisateurs de modifier les enregistrements pour les effacer. Dans l’idéal, ils mettaient à jour le statut, ajoutaient des notes ou consignaient des activités – se réengageant avec le prospect – et ces mises à jour effaçaient le drapeau jusqu’à ce que le prospect ait un autre point de contact qui le re-marque pour une nouvelle visite.

Lorsque nous recevons des questions des utilisateurs sur le nouveau processus, nous réévaluons nos hypothèses à partir de la formule initiale. Par exemple:

  • La date de la dernière activité utilise la «dernière date des événements sur un enregistrement». Bien que nous n’ayons pas officiellement déployé les activités, certains utilisateurs enregistrent les appels terminés, nous voulions donc en tenir compte. Mais qu’en est-il des activités futures? Une tâche définie pour le mois prochain toujours être supérieur à la date de la dernière modification, il n’y aurait donc aucun moyen d’effacer l’indicateur.
    • Nous avons donc supprimé « DATEVALUE (LastModifiedDate)> (LastActivityDate + 1))»De la formule, et les activités ne sont pas actuellement un facteur.
  • Nous avons trouvé un grand nombre de prospects signalés inutilement, sur la base de modifications non liées que nous en tant qu’administrateurs apportaient aux prospects (Data Loader, quelqu’un?) Ou de «mises à jour» effectuées via des intégrations. Cela avait un impact sur l’adoption, car les gens ne «faisaient pas confiance» à la case à cocher.

Vraiment, nous voulons signaler si exploitable des modifications ont été apportées, pas seulement tout modifications.

  • Pour évaluer cela, nous avons créé un champ de formule appelé Lead Touch qui utilise le meilleur de Dernière activité de Pardot créer un rendez-vous, etc. pour comparer avec notre Dernier changement de statut.
  • Et si le lead est établi avec un statut différent de Nouveau? Par exemple, lorsqu’un partenaire crée initialement un prospect basé sur une personne à qui il a déjà parlé, il commence par Statut du lead de nouveau contacté.

Étant donné que ce n’était pas techniquement modifié il ne peuplait pas la date du dernier changement de statut, sens Revisiter n’a pas été vérifié alors qu’il aurait dû l’être. Une mise à jour rapide de la formule des critères de règle de workflow a permis de résoudre ce problème:

PRÉCÉDENT:

, Utilisation de l&rsquo;automatisation pour gérer le cycle de vie des leads – Admin Hero<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

MIS À JOUR:

, Utilisation de l&rsquo;automatisation pour gérer le cycle de vie des leads – Admin Hero<span class="wtr-time-wrap after-title"><span class="wtr-time-number">8</span> minutes de lecture</span>

Cela nous amène à l’état actuel de notre formule:

NOT(ISPICKVAL(Status, "New")) && NOT( ISBLANK( Last_Status_Change_Date__c ) ) && Lead_Touch__c > (DATEVALUE(Last_Status_Change_Date__c) + 1) && OR(LastModifiedBy.ProfileId = "00e30000000eyco",LastModifiedBy.ProfileId = "00e800000011uFU" /*Profiles for Sys Admin and Robots*/)

Nous n’en avons peut-être pas «fini» avec ce processus, mais nous sommes certainement mieux lotis qu’auparavant! D’une part, nous avons supprimé un grand nombre de faux positifs, ce qui aide nos utilisateurs à s’engager en leur rappelant de manière proactive que leurs prospects ont besoin d’une nouvelle visite. D’un autre côté, cela finit par être plus restrictif que je ne le souhaiterais étant donné qu’actuellement, l’utilisateur doit modifier le statut pour réinitialiser le Date du dernier changement de statut et effacez donc le drapeau. La prochaine version impliquera probablement un Dernière modification par date du propriétaire, quelque chose rempli via Workflow qui tient compte des dernières activités modifiées et terminées et / ou des mises à jour de chatter par le propriétaire. Ou peut-être un autre nouveau facteur auquel nous n’avons même pas encore pensé!

Comment abordez-vous le réengagement des prospects existants? J’adorerais entendre toute contribution pour la prochaine évolution de notre processus!

A propos de Kristy Campbell

Kristi est devenue administratrice Salesforce autodidacte en 2007 alors qu’elle travaillait dans Service Cloud dans une société de logiciels hôteliers à Boston, MA. Elle est maintenant un développeur certifié Force.com et une administratrice avancée vivant à Charlotte, en Caroline du Nord. En 2015, elle a commencé le chapitre Charlotte Women In Tech pour rencontrer d’autres femmes rockstar Salesforce qui Salesforce et a été interviewée sur le fait d’être une #GirlyGeek for the Good Say Sir! Podcast sur Dreamforce. Vous pouvez la trouver en ligne sur son blog à l’adresse http://www.kristiforce.com ou sur Twitter @KristiForce.



Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer