Comment les equipes de parcs connectes reduisent leurs cases de 93 pour cent sur Salesforce

Reponse courte : les equipes qui gerent des parcs connectes ne reduisent pas leur volume de cases en recrutant davantage au support. Elles le reduisent en laissant l'appareil signaler sa propre panne, en resolvant automatiquement la majorite de ces signalements, et en reservant un case Salesforce a l'exception qui exige reellement un humain. Sur un programme livre pour ASSA ABLOY (FocusCura et Phoniro), ce modele a fait passer les cases hebdomadaires d'environ 3 000 a 350, soit une reduction de 93 pour cent, sur 11 000 appareils connectes et jusqu'a 2,5 millions d'evenements par semaine dans trois marches, sans un seul poste de support supplementaire.

Qu'est-ce que le service pilote par la telemetrie ?

Le service pilote par la telemetrie est un modele ou c'est l'equipement, et non le client, qui ouvre la conversation. Les evenements des appareils alimentent le CRM en continu, sont rattaches a un asset et a un entitlement, et declenchent un chemin de resolution avant que quiconque decroche un telephone.

Trois niveaux meritent d'etre distingues, car la plupart des equipes les confondent :

• Reactif. Le client constate la panne et appelle. Chaque incident coute un agent.
• Proactif. La plateforme detecte en premier et alerte quelqu'un. Plus confortable pour le client, mais un humain traite toujours.
• Triage autonome. La plateforme detecte, classe et repare. Un case n'existe que si la reparation echoue.

La quasi-totalite des 93 pour cent se joue dans le passage du proactif a l'autonome. L'alerting proactif seul augmente generalement la charge, parce qu'il ajoute une file sans supprimer l'ancienne.

Comment un evenement machine devient-il un incident resolu sans case ?

1. Ingerer au rythme des evenements, pas des cases. Des millions d'evenements hebdomadaires appartiennent a une couche de donnees concue pour le volume. Salesforce l'appelle desormais Data 360, l'ancien Data Cloud renomme sous Agentforce 360.
2. Resoudre l'identite avant tout. Chaque evenement est rattache a un enregistrement d'asset, a sa localisation, a son client et a son entitlement. Un evenement non attribuable est un defaut d'integration, pas un incident.
3. Classer contre un jeu de regles. Les signatures pointent vers des classes de panne connues avec un remede connu : redemarrage, reappairage, mise a jour firmware, commande de consommable, intervention.
4. Reparer automatiquement quand le remede est deterministe. La majorite des pannes terrain sont un petit ensemble de recurrences. Automatisez d'abord les recurrences et la longue traine ne devient jamais urgente.
5. Ne creer un case qu'a l'escalade. Le case s'ouvre apres l'echec de l'automatisation et porte tout l'historique des tentatives, pour que l'agent ne reparte pas de zero.
6. N'envoyer une intervention Field Service que si une presence physique est indispensable, avec la piece et le diagnostic deja attaches a l'ordre de travail.

Quels evenements meritent vraiment un case ?

C'est la question que la plupart des contenus sur le service connecte esquivent, et c'est precisement de la que vient le chiffre. Un case est une unite de travail humain, pas une unite de telemetrie. Classez chaque signature dans l'un de trois seaux avant de construire quoi que ce soit :

• Bruit. Transitoire, auto-corrige, sans impact client. A supprimer et a compter. Jamais a afficher.
• Deterministe. Panne connue, correction connue, aucun jugement requis. A automatiser de bout en bout.
• Ambigu. Exige une personne, une decision ou une visite. Seul ce seau a le droit de creer un case.

Les equipes qui sautent cet exercice se retrouvent avec un alerting proactif qui genere plus de tickets que l'ancienne ligne telephonique.

A quoi ressemblent ces 93 pour cent sur le terrain ?

L'activite connected care d'ASSA ABLOY exploitait un parc de 11 000 appareils produisant jusqu'a 2,5 millions d'evenements par semaine sur trois marches. Le support absorbait environ 3 000 cases par semaine, et la reponse evidente sur la table etait de recruter.

La telemetrie a plutot ete routee vers Service Cloud via une couche de triage autonome, et le parc a commence a se resoudre lui-meme. Le volume hebdomadaire s'est stabilise autour de 350 cases. L'effectif support n'a pas bouge.

Deux details comptent plus que le titre :

• Ce qui reste est plus difficile, et c'est normal. Il ne reste que le seau ambigu. Attendez-vous a une hausse du temps de traitement moyen par case pendant que le cout total du service baisse, et menez cette conversation avec votre directeur des services avant la mise en production, pas apres.
• Rien n'a ete reconstruit par marche. Le chemin appareil vers Service Cloud a ete livre comme composant 2GP package, ce qui a rendu les deuxieme et troisieme marches peu couteux au lieu d'etre des projets repetes.

Quel modele operationnel fait tenir la baisse ?

L'architecture produit la premiere baisse. Le modele operationnel empeche la derive au bout de deux trimestres.

• Traitez le jeu de regles comme un produit, pas comme du parametrage. Versionne, revu, deploye par un pipeline et reversible. Les regles editees en direct en production finissent toujours par pourrir.
• Donnez les seuils au management du service. Ceux qui subissent la file doivent pouvoir changer ce qui se declenche sans attendre une release.
• Mesurez les cases pour mille appareils, pas les cases. Le volume absolu vous flatte quand le parc stagne et vous punit quand vous gagnez des clients. Le ratio est le seul signal honnete.
• Revoyez la liste de suppression a cadence fixe. Tout ce que vous avez fait taire est un pari, et les mises a jour firmware transforment les bons paris en mauvais.
• Gardez un seul enregistrement d'asset. Des que l'etat de l'appareil vit dans deux systemes, les agents cessent de faire confiance a l'automatisation et ouvrent des cases par precaution.

Ou cela derape-t-il d'habitude ?

• Alerter sans reparer. Un tableau de bord rempli de tuiles rouges est un nouveau travail, pas un travail economise.
• Stocker chaque evenement brut comme enregistrement de plateforme. Volume d'evenements et volume de cases sont des ordres de grandeur differents et n'ont pas leur place au meme endroit.
• Aucun entitlement dans le chemin. Sans contexte contractuel, l'automatisation ne peut pas decider qui paie la visite, donc elle escalade tout par securite.

FAQ

Faut-il Data 360 pour demarrer ?

Pas pour un pilote. Une couche de donnees de volume devient necessaire quand le debit d'evenements depasse ce que votre org principale devrait stocker, ce qui arrive bien avant le million hebdomadaire pour la plupart des parcs.

Est-ce que cela remplace Field Service ?

Non. Cela reduit le nombre d'interventions et ameliore celles qui restent, puisque le diagnostic et la piece sont connus avant le depart du technicien.

En combien de temps le volume de cases bouge-t-il ?

La premiere baisse mesurable vient du seau deterministe, qui est aussi le plus petit chantier. Sequencez-le en premier et vous obtenez la preuve avant le perimetre.

Agentforce le fait-il nativement ?

Agentforce raisonne sur le contexte que vous lui donnez. Il n'invente pas votre taxonomie de pannes : les regles de classification, les donnees d'asset et le modele d'entitlement doivent exister en dessous.

Nous construisons ce schema sous le nom de Tekunda IoT Cloud : des evenements machine au triage autonome sur Service Cloud et a la planification Field Service, adosses a Data 360. Si votre file de cases grandit au rythme de votre parc installe, parlons-en.