La brique Service Cloud de Salesforce possède des paramètres insoupçonnés et séduit par sa simplicité de mise en œuvre. Son implémentation, même peu sophistiquée, offre des fonctionnalités à forte valeur ajoutée pour nos clients. L’un des atouts majeurs de cette brique c’est sans nul doute sa maturité même si elle bénéficie d’innovations continues release après release.
Un projet Service Cloud peut se limiter à la gestion des requêtes via l’email-to-case, que ce soit seul, combiné avec un CTI, ou enrichi par l’intégration d’un chat, et bien plus encore. Cependant, certaines configurations élémentaires sont parfois omises, cela entraîne des impacts significatifs.
Dans cet article, je vais mettre en lumière cinq pièges à éviter lors de la configuration de Service Cloud de Salesforce : de la vérification des adresses mail des utilisateurs à la gestion des automatismes déclenchés par le changement de statut des emails associés aux requêtes, en passant par la visibilité sur l’onglet ‘Superviseur Omni’ et les subtilités des modèles d’email par défaut et des adresses d’acheminement dans les échanges par mail sur les requêtes.
1. Vérifier l’adresse mail de l’utilisateur
Depuis peu, si l’email d’un utilisateur n’est pas vérifié, les mails qu’il envoie ne sont pas reçus pas le destinataire.
L’email envoyé n’est pas non plus traqué dans le log d’emails. Rien de plus déroutant d’autant que l’utilisateur parvient à saisir et envoyer son mail sans blocage ni erreur quelconque et au niveau des activités on voit bien l’email sortant dans l’historique des interactions avec le contact.
Vérifier l’email d’un utilisateur habilité à en envoyer, devient donc incontournable pour garantir la réception des mails côté client. Jusqu’ici, nous avons développé le réflexe de regarder la délivrabilité des mails lorsqu’un client nous remonte des soucis d’envois. A présent, pensez-y! Assurez-vous que les emails des utilisateurs sont vérifiés car la délivrabilité, la clé DKIM et le SPF ou encore l’email relay ne suffisent plus si le nécessaire n’a pas été fait au niveau de l’utilisateur.
2. La réponse du client à un mail sur une requête n’arrive pas dans Salesforce
Une requête peut être issue d’un échange téléphonique et donner lieu à un suivi par email par la suite à l’initiative de l’utilisateur côté Salesforce. Dans ce cas, il faut veiller à ne PAS envoyer le premier mail sortant avec l’adresse personnelle de l’agent du service client qui a traité la requête.
Au contraire, il faut que cet envoi se fasse depuis une adresse d’acheminement configurée dans les paramètres de l’email-to-case.
En effet, cela va permettre à Salesforce de raccrocher par la suite les réponses entrantes du client à la requête. Autrement, la réponse est reçue dans la boîte mail personnelle de l’utilisateur.
Ne vous y trompez donc pas ! Cette règle d’or est à communiquer aux clients et surtout pendant les formations utilisateurs.
3. Il est difficile d’attribuer la visibilité sur l’onglet ‘Superviseur Omni’ via un ensemble de permissions ?
Ce piège est moins évident d’autant que définir la visibilité d’un onglet d’objet est chose aisée pour n’importe quel Administrateur Salesforce. Or, avec l’avènement des ensembles de permissions, il n’est pas rare que nous soyons amenés à attribuer aux personnes habilitées l’accès à la vue dédiée aux superviseurs de l’omni-channel après avoir créé une configuration de superviseur Omni-Channel.
La particularité ici, c’est que lors de la définition de l’ensemble de permissions il faut IMPÉRATIVEMENT choisir le type de licence “Salesforce” sinon ça ne marchera pas. Et, retrouver cette précision de taille dans la documentation Salesforce revient à chercher une aiguille dans une botte de foin. Vous êtes désormais prévenus 😎.
4. Le modèle d’email par défaut de la requête apparaît dans la fenêtre d’édition de mail et pré-remplit l’objet du mail
Dans Service Cloud, ce comportement est dû à la présence dans votre org, d’un modèle d’email classic qui a été défini sur l’action d’envoi de mail sur l’objet ‘requête’ comme étant le modèle par défaut. De plus, si la case “Ne pas appliquer l’objet du modèle” est cochée, alors ce n’est pas l’objet du modèle par défaut qui s’applique mais plutôt celui sur l’email associé à la requête.
Pour éviter cela, pensez à vider ces deux champs, de sorte à garder dans la fenêtre d’édition de mail depuis la requête le fil des échanges entrants et sortants.
Définissez plutôt sur l’action d’email présent sur la requête à minima deux valeurs par défaut : un objet personnalisé et le destinataire du mail par exemple.
5. Faire que le changement de statut de l’email associé à la requête déclenche des automatismes
Vous n’êtes pas sans savoir que les mails associés à une requête Salesforce sont portés par l’objet standard “E-mail” (EmailMessage).
Celui-ci comporte entre autres un champ statut avec plusieurs valeurs possibles pour déterminer si l’email est :
- nouveau
- lu
- répondu
- transféré
- envoyé
- brouillon
Il est courant que les clients souhaitent avoir un indicateur visuel sur la requête afin d’informer les agents du support de l’arrivée d’un email entrant non lu et ce, sans les inonder de notifications Chatter. Cet indicateur visuel serait différent selon la valeur du statut du mail associé.
Cependant, le changement de statut se fait automatiquement par le système dès l’ouverture du mail, si nous voulons déclencher un automatisme sur cette base, il faut activer une fonctionnalité supplémentaire.
Il faut cocher sur les paramètres de l’email-to-case l’option “Invoquer des déclencheurs en cas de changement de statut de Nouveau à Lu” autrement le passage de “Nouveau” à “Lu” par exemple ne pourra déclencher un quelconque automatisme pour réaliser des actions spécifiques.
Par ailleurs, concernant l’objet “Email”, sachez que vous ne pouvez pas vous fier aux champs “Première ouverture”, “Ouvert ?” et “Dernière ouverture” ; ils ne sont jamais alimentés par le système. Ne basez donc aucun automatisme là-dessus d’ici que Salesforce rectifie cela.
Projet après projet, nous découvrons des paramètres insoupçonnés dans Salesforce au prix de longues heures de recherche, d’incompréhension et d’inquiétude. Maintenant que vous avez lu cet article, ces cinq cas d’usage n’auront plus de secrets pour vous. Vous agissez désormais en Admins avertis et éclairés.
Et vous, quels sont les paramètres cachés que vous avez découvert, dans Service Cloud ou ailleurs, et qui pourraient aider d’autres à gagner du temps et à préserver leur sérénité ?
Partagez vos expériences et enrichissons-nous mutuellement !
Si vous souhaitez approfondir le sujet, voici d’autres articles complémentaires :
Optimiser la délivrabilité des emails avec Salesforce Marketing Cloud
Découverte d’Omni-Channel dans Salesforce
Comment bien configurer Omni-Channel dans Salesforce Lightning?
