Tekunda Team

Tekunda Team

Hoe teams met verbonden apparaten hun supportcases met 93 procent verlaagden op Salesforce

Hoe teams met verbonden apparaten hun supportcases met 93 procent verlaagden op Salesforce

Kort antwoord: teams met verbonden apparaten verlagen hun casevolume niet door meer supportmedewerkers aan te nemen. Ze verlagen het door het apparaat zijn eigen storing te laten melden, de meeste van die meldingen automatisch af te handelen en een Salesforce-case te bewaren voor de uitzondering die echt een mens nodig heeft. In een programma dat wij voor ASSA ABLOY (FocusCura en Phoniro) hebben opgeleverd, daalde het aantal wekelijkse supportcases daardoor van ongeveer 3.000 naar 350, een reductie van 93 procent, over 11.000 verbonden apparaten en tot 2,5 miljoen events per week in drie markten, zonder extra supportmedewerkers.

Wat is telemetriegedreven service?

Telemetriegedreven service is een model waarin het asset het gesprek begint in plaats van de klant. Apparaatevents stromen continu het CRM in, worden gekoppeld aan een asset en een entitlement, en starten een oplospad voordat iemand de telefoon pakt.

Drie niveaus zijn het waard om uit elkaar te houden, want de meeste teams gooien ze op een hoop:

  • Reactief. De klant merkt de storing en belt. Elk incident kost een medewerker.
  • Proactief. Het platform merkt het eerst en waarschuwt iemand. Prettiger voor de klant, maar een mens handelt het nog steeds af.
  • Autonome triage. Het platform signaleert, classificeert en herstelt. Er ontstaat alleen een case als het herstel mislukt.

Vrijwel die hele 93 procent zit in de sprong van proactief naar autonoom. Alleen proactief alarmeren verhoogt de werklast meestal juist, omdat je een wachtrij toevoegt zonder de oude weg te halen.

Hoe wordt een apparaatevent een opgelost incident zonder case?

  1. Verwerk op eventsnelheid, niet op casesnelheid. Miljoenen events per week horen thuis in een datalaag die voor volume is gebouwd. Salesforce noemt die laag inmiddels Data 360, de hernoemde Data Cloud onder Agentforce 360.
  2. Los eerst de identiteit op. Elk event wordt gekoppeld aan een assetrecord, de locatie, de klant en het entitlement. Een event dat je niet kunt toewijzen is een integratiefout, geen incident.
  3. Classificeer tegen een regelset. Signatuurpatronen wijzen naar bekende storingsklassen met een bekende remedie: herstarten, opnieuw koppelen, firmware pushen, verbruiksartikel bestellen, monteur sturen.
  4. Herstel automatisch waar de remedie deterministisch is. De meeste veldstoringen zijn een kleine set herhalingen. Automatiseer die eerst en de staart wordt nooit urgent.
  5. Maak alleen een case bij escalatie. De case ontstaat nadat de automatisering het heeft geprobeerd en gefaald, met de volledige geschiedenis erbij zodat de medewerker niet vanaf nul begint.
  6. Stuur pas via Field Service iemand ter plaatse als het fysiek moet, met het onderdeel en de diagnose al aan de werkorder gekoppeld.

Welke apparaatevents verdienen eigenlijk een case?

Dit is de vraag die de meeste publicaties over connected service overslaan, en precies hier komt het getal vandaan. Een case is een eenheid menselijk werk, geen eenheid telemetrie. Sorteer elke eventsignatuur in een van drie bakken voordat je iets bouwt:

  • Ruis. Tijdelijk, zelfherstellend, geen klantimpact. Onderdrukken en tellen. Nooit tonen.
  • Deterministisch. Bekende storing, bekende fix, geen oordeel nodig. Volledig automatiseren.
  • Ambigu. Vraagt een mens, een besluit of een bezoek. Alleen deze bak mag een case aanmaken.

Teams die deze oefening overslaan houden proactieve alarmering over die meer tickets oplevert dan de oude telefoonlijn.

Hoe zag die 93 procent er in de praktijk uit?

De connected-care activiteiten van ASSA ABLOY draaiden een vloot van 11.000 apparaten met tot 2,5 miljoen events per week in drie markten. Support verwerkte ongeveer 3.000 cases per week, en het voor de hand liggende antwoord op tafel was aannemen.

In plaats daarvan is de telemetrie via een autonome triagelaag naar Service Cloud gerouteerd, en begon de vloot zichzelf op te lossen. Het weekvolume stabiliseerde rond 350 cases. De bezetting bleef gelijk.

Twee details wegen zwaarder dan de kop:

  • Wat overblijft is zwaarder, en dat klopt. Wat resteert is de ambigue bak. Reken op een hogere gemiddelde afhandeltijd per case terwijl de totale servicekosten dalen, en voer dat gesprek met je servicedirecteur voor de livegang, niet erna.
  • Er is niets per markt opnieuw gebouwd. Het pad van apparaat naar Service Cloud is opgeleverd als een verpakte 2GP-component, en juist daardoor waren de tweede en derde markt goedkoop in plaats van een herhaalproject.

Welk operationeel model houdt de daling vast?

Architectuur levert de eerste daling. Het operationele model voorkomt dat je binnen twee kwartalen terugzakt.

  • Behandel de regelset als product, niet als configuratie. In versiebeheer, gereviewd, via een pipeline uitgerold en terug te draaien. Regels die live in productie worden aangepast verrotten altijd.
  • Geef servicemanagement eigenaarschap over drempelwaarden. Wie de wachtrij voelt, moet kunnen aanpassen wat afgaat zonder op een release te wachten.
  • Meet cases per duizend apparaten, niet cases. Een absoluut aantal vleit je bij een vlakke vloot en straft je af zodra je klanten wint. De ratio is het enige eerlijke signaal.
  • Bekijk de onderdrukkingslijst op een vast ritme. Alles wat je hebt gedempt is een weddenschap, en firmware-updates maken goede weddenschappen slecht.
  • Houd een assetrecord aan. Zodra de apparaatstatus in twee systemen leeft, vertrouwen medewerkers de automatisering niet meer en openen ze uit voorzorg cases.

Waar gaat dit meestal mis?

  • Alarmeren zonder herstellen. Een dashboard vol rode tegels is nieuw werk, geen bespaard werk.
  • Elk ruw event als platformrecord opslaan. Eventvolume en casevolume schelen ordes van grootte en horen op verschillende plekken.
  • Geen entitlement in het pad. Zonder contractcontext kan de automatisering niet bepalen wie het bezoek betaalt, dus escaleert ze veiligheidshalve alles.

FAQ

Heb je Data 360 nodig om te starten?

Niet voor een pilot. Een volumedatalaag heb je nodig zodra de eventsnelheid groter wordt dan wat je kernorg zou moeten opslaan, en dat gebeurt bij de meeste vloten ruim voor de miljoenen per week.

Vervangt dit Field Service?

Nee. Het verlaagt het aantal ritten en verbetert de ritten die overblijven, omdat diagnose en onderdeel al bekend zijn voordat de bus vertrekt.

Hoe snel beweegt het casevolume?

De eerste meetbare daling komt uit de deterministische bak, en dat is ook de kleinste bouw. Zet die vooraan en je hebt bewijs voordat je scope hebt.

Doet Agentforce dit standaard?

Agentforce redeneert over de context die je geeft. Het verzint je storingstaxonomie niet, dus de classificatieregels, assetdata en het entitlementmodel moeten er nog steeds onder liggen.

Wij bouwen dit patroon als Tekunda IoT Cloud: van apparaatevents naar autonome triage op Service Cloud en dispatch via Field Service, gefundeerd op Data 360. Groeit jouw casewachtrij mee met je installed base? Neem contact op.

Gerelateerde artikelen