Comment les équipes de parcs connectés réduisent leurs cases de 93 pour cent sur Salesforce

Réponse courte : les équipes qui gèrent des parcs connectés ne réduisent pas leur volume de cases en recrutant davantage au support. Elles le réduisent en laissant l'appareil signaler sa propre panne, en résolvant automatiquement la majorité de ces signalements, et en réservant un case Salesforce à l'exception qui exige réellement un humain. Sur un programme livré pour ASSA ABLOY (FocusCura et Phoniro), ce modèle a fait passer les cases hebdomadaires d'environ 3 000 à 350, soit une réduction de 93 pour cent, sur 11 000 appareils connectés et jusqu'à 2,5 millions d'événements par semaine dans trois marchés, sans un seul poste de support supplémentaire.

Qu'est-ce que le service piloté par la télémétrie ?

Le service piloté par la télémétrie est un modèle où c'est l'équipement, et non le client, qui ouvre la conversation. Les événements des appareils alimentent le CRM en continu, sont rattachés à un asset et à un entitlement, et déclenchent un chemin de résolution avant que quiconque décroche un téléphone.

Trois niveaux méritent d'être distingués, car la plupart des équipes les confondent :

• Réactif. Le client constate la panne et appelle. Chaque incident coûte un agent.
• Proactif. La plateforme détecte en premier et alerte quelqu'un. Plus confortable pour le client, mais un humain traite toujours.
• Triage autonome. La plateforme détecte, classe et répare. Un case n'existe que si la réparation échoue.

La quasi-totalité des 93 pour cent se joue dans le passage du proactif à l'autonome. L'alerting proactif seul augmente généralement la charge, parce qu'il ajoute une file sans supprimer l'ancienne.

Comment un événement machine devient-il un incident résolu sans case ?

1. Ingérer au rythme des événements, pas des cases. Des millions d'événements hebdomadaires appartiennent à une couche de données conçue pour le volume. Salesforce l'appelle désormais Data 360, l'ancien Data Cloud renomme sous Agentforce 360.
2. Résoudre l'identité avant tout. Chaque événement est rattaché à un enregistrement d'asset, à sa localisation, à son client et à son entitlement. Un événement non attribuable est un défaut d'intégration, pas un incident.
3. Classer contre un jeu de règles. Les signatures pointent vers des classes de panne connues avec un remède connu : redémarrage, réappairage, mise à jour firmware, commande de consommable, intervention.
4. Réparer automatiquement quand le remède est déterministe. La majorité des pannes terrain sont un petit ensemble de récurrences. Automatisez d'abord les récurrences et la longue traîne ne devient jamais urgente.
5. Ne créer un case qu'à l'escalade. Le case s'ouvre après l'échec de l'automatisation et porte tout l'historique des tentatives, pour que l'agent ne reparte pas de zéro.
6. N'envoyer une intervention Field Service que si une présence physique est indispensable, avec la pièce et le diagnostic déjà attachés à l'ordre de travail.

Quels événements méritent vraiment un case ?

C'est la question que la plupart des contenus sur le service connecté esquivent, et c'est précisément de là que vient le chiffre. Un case est une unité de travail humain, pas une unité de télémétrie. Classez chaque signature dans l'un de trois seaux avant de construire quoi que ce soit :

• Bruit. Transitoire, auto-corrigé, sans impact client. À supprimer et à compter. Jamais à afficher.
• Déterministe. Panne connue, correction connue, aucun jugement requis. À automatiser de bout en bout.
• Ambigu. Exige une personne, une décision ou une visite. Seul ce seau a le droit de créer un case.

Les équipes qui sautent cet exercice se retrouvent avec un alerting proactif qui génère plus de tickets que l'ancienne ligne téléphonique.

À quoi ressemblent ces 93 pour cent sur le terrain ?

L'activité connected care d'ASSA ABLOY exploitait un parc de 11 000 appareils produisant jusqu'à 2,5 millions d'événements par semaine sur trois marchés. Le support absorbait environ 3 000 cases par semaine, et la réponse évidente sur la table était de recruter.

La télémétrie a plutôt été routée vers Service Cloud via une couche de triage autonome, et le parc a commencé à se résoudre lui-même. Le volume hebdomadaire s'est stabilisé autour de 350 cases. L'effectif support n'a pas bougé.

Deux détails comptent plus que le titre :

• Ce qui reste est plus difficile, et c'est normal. Il ne reste que le seau ambigu. Attendez-vous à une hausse du temps de traitement moyen par case pendant que le coût total du service baisse, et menez cette conversation avec votre directeur des services avant la mise en production, pas après.
• Rien n'a été reconstruit par marché. Le chemin appareil vers Service Cloud a été livré comme composant 2GP package, ce qui a rendu les deuxième et troisième marchés peu coûteux au lieu d'être des projets répétés.

Quel modèle opérationnel fait tenir la baisse ?

L'architecture produit la première baisse. Le modèle opérationnel empêche la dérive au bout de deux trimestres.

• Traitez le jeu de règles comme un produit, pas comme du paramétrage. Versionné, revu, déployé par un pipeline et réversible. Les règles éditées 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 déclenche 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 honnête.
• Revoyez la liste de suppression à cadence fixe. Tout ce que vous avez fait taire est un pari, et les mises à jour firmware transforment les bons paris en mauvais.
• Gardez un seul enregistrement d'asset. Dès que l'état de l'appareil vit dans deux systèmes, les agents cessent de faire confiance à l'automatisation et ouvrent des cases par précaution.

Où cela dérape-t-il d'habitude ?

• Alerter sans réparer. Un tableau de bord rempli de tuiles rouges est un nouveau travail, pas un travail économisé.
• Stocker chaque événement brut comme enregistrement de plateforme. Volume d'événements et volume de cases sont des ordres de grandeur différents et n'ont pas leur place au même endroit.
• Aucun entitlement dans le chemin. Sans contexte contractuel, l'automatisation ne peut pas décider qui paie la visite, donc elle escalade tout par sécurité.

FAQ

Faut-il Data 360 pour démarrer ?

Pas pour un pilote. Une couche de données de volume devient nécessaire quand le débit d'événements dépasse 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 réduit le nombre d'interventions et améliore celles qui restent, puisque le diagnostic et la pièce sont connus avant le départ du technicien.

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

La première baisse mesurable vient du seau déterministe, qui est aussi le plus petit chantier. Séquencez-le en premier et vous obtenez la preuve avant le périmètre.

Agentforce le fait-il nativement ?

Agentforce raisonne sur le contexte que vous lui donnez. Il n'invente pas votre taxonomie de pannes : les règles de classification, les données d'asset et le modèle d'entitlement doivent exister en dessous.

Nous construisons ce schéma sous le nom de Tekunda IoT Cloud : des événements machine au triage autonome sur Service Cloud et à la planification Field Service, adossés à Data 360. Si votre file de cases grandit au rythme de votre parc installé, parlons-en.