Salesforce asset lifecycle management voor connected devices

Kort antwoord: Asset lifecycle management op Salesforce werkt pas als de geinstalleerde unit een Asset-record is dat service, garantie en renewals allemaal lezen, in plaats van drie records bij drie teams. Salesforce levert de objecten er al voor: Asset met een parent-hierarchie, WarrantyTerm en AssetWarranty voor dekking, en Entitlement of ServiceContract voor wat de klant kocht. Het lastige deel is telemetrie, want device-events mogen niet regel voor regel in de org landen.

Wat betekent asset lifecycle management op Salesforce?

Het betekent dat je een fysieke unit volgt van levering via installatie, service, garantieclaims, upgrades tot vervanging, op een record dat zijn eigen historie draagt. Salesforce bundelt dit als Asset Service Lifecycle Management, met een interactieve assethierarchie, een coverage-overzicht voor entitlements, work order estimation en product service campaigns voor recalls en upgrades (Salesforce Help).

De features zijn het makkelijke deel. Wat bepaalt of het werkt, is het datamodel waar je in week een voor kiest.

Welk object hoort wat vast te houden?

De meeste vastgelopen connected-assettrajecten waar wij bij worden gehaald, liepen hier vast, niet op de integratie. Een schone verdeling ziet er zo uit.

• Product2 is het model. Het is wat je verkoopt, niet wat de klant heeft.
• Asset is de individuele unit: serienummer, installatiedatum, status, account, contact en locatie. Gebruik de parent- en root-assetvelden voor een device dat in een gateway, paneel of gebouw hangt, zodat een storing op een component oprolt naar iets waar een monteur naartoe kan.
• WarrantyTerm legt vast wat gedekt is, dus arbeid, onderdelen en kosten, en AssetWarranty koppelt die term aan een specifieke unit met eigen datums (objectreferentie).
• Entitlement en ServiceContract dragen wat de klant kocht en tot wanneer. Entitlements kunnen aan het account, de asset, de case of het contract hangen, en precies daarom staat dezelfde dekking vaak op drie plekken.
• Case en WorkOrder verwijzen naar de asset, nooit naar het product. Een case zonder asset-id kun je niet factureren, dekken of trenden.

Een regel houdt dit eerlijk: dekking wordt op precies een plek vastgelegd en de rest leest mee. Kan sales een verlengdatum aanpassen die service niet ziet, dan heb je geen asset lifecycle management maar drie spreadsheets in een jas.

Hoe krijg je telemetrie binnen zonder de org te verzuipen?

Salesforce heeft IoT Explorer uitgefaseerd en verwees klanten door naar platform events en flows (uitfaseringsbericht). Dat is het juiste instinct, met een regel erbij: Salesforce bewaart status en beslissingen, niet de ruwe stroom.

In de praktijk draaien wij drie lagen.

1. Ingest en reduceer buiten de org. Heartbeats, metingen en dubbele alarmen worden samengevouwen tot betekenisvolle overgangen voordat er iets de API passeert.
2. Publiceer overgangen als platform events. Een event per statuswijziging, met serienummer, conditie en tijdstempel, dat op serienummer naar de Asset wordt opgelost en niet op record-id.
3. Schrijf afgeleide status op de Asset en laat automatisering beslissen. Huidige gezondheid, laatst gezien, firmwareversie, openstaande storing. Een flow of Apex-handler bepaalt dan case, work order, of niets.

Die laatste optie telt het zwaarst. De triageregel, niet de ingestie, houdt een connected fleet onderhoudbaar. Voor ASSA ABLOY draaien we bij FocusCura en Phoniro 11.000 connected devices die tot 2,5 miljoen events per week produceren, en brachten we de wekelijkse cases terug van 3.000 naar 350, een reductie van 93% in drie markten zonder extra supportmensen. De devices werden niet stiller. Het model stopte met een case aanmaken voor elk symptoom.

Wat levert een asset-record je echt op?

• Service ziet dekking voor dispatch, dus niemand stuurt een betaalde monteur naar een unit onder garantie.
• Garantieclaims worden afgehandeld tegen de term op die unit, niet tegen een polis die iemand zich herinnert.
• Renewals worden geprognosticeerd op installatiedatums en garantie-einddatums die al in het systeem staan, zodat de klant het verlopen niet meer als eerste ontdekt.
• Productteams krijgen faalpercentages per model en per firmwareversie, omdat elke case naar een echte unit wijst.

Niets daarvan heeft een AI-laag nodig om de moeite waard te zijn. Het maakt die laag later wel mogelijk, want een agent kan alleen redeneren over een geinstalleerde basis die daadwerkelijk gemodelleerd is.

Hoe sequence je de bouw?

1. Laad de geinstalleerde basis met echte serienummers en installatiedatums, ook als die deels is. Assets zonder serienummer zijn later niet te reconcilieren.
2. Modelleer de hierarchie voordat je iets automatiseert, want herstelwerk hier raakt elk onderliggend record.
3. Hang garantietermen en entitlements eraan en kies het ene object dat dekking bezit.
4. Bedraad telemetrie als statusovergangen, met een geschreven triageregel per conditie.
5. Voeg pas daarna work orders, servicecontracten, renewalprognoses en agents toe.

Teams die stap een en vier omdraaien, houden een prachtige integratie over die events schrijft op assets die niemand vertrouwt. Wil je dit tegen je eigen org laten toetsen: Tekunda doet asset lifecycle work op Salesforce naast Field Service en connected-device delivery.

FAQ

Moet elk device een Asset zijn of een custom object?

Vrijwel altijd een Asset. Entitlements, garanties, work orders en Field Service hebben er al relaties mee, en een custom object betekent dat je die met de hand nabouwt.

Waar hoort ruwe telemetrie thuis?

Buiten de transactionele org, in een store die voor tijdreeksen is gebouwd. Salesforce houdt de huidige status, de events die hem wijzigden en de genomen beslissingen bij, niet elke meting.

Wat is het verschil tussen garantie en entitlement?

Een garantieterm beschrijft wat op een unit gedekt is, zoals onderdelen, arbeid en kosten. Een entitlement of servicecontract beschrijft wat de klant kocht, inclusief supportniveaus en datums. De meeste organisaties hebben beide nodig.

Kan dit zonder Field Service?

Ja. Asset-, garantie- en entitlementmodellering werkt in Service Cloud alleen. Field Service wordt nodig zodra je monteurs stuurt, onderdelen beheert en onderhoudsbezoeken plant.