Salesforce asset lifecycle management voor connected devices

Kort antwoord: Salesforce Asset Service Lifecycle Management (ASLM) is het verpakte featurepakket van Salesforce om een fysiek asset te onderhouden van installatie tot einde levensduur: een interactieve assethierarchie, een coverage-overzicht van entitlements, work order estimation, recall- en upgradecampagnes, exchanges, depotreparatie en serviceinventaris, allemaal op het standaard Asset-object. Het werkt wanneer elke geinstalleerde unit een Asset-record is dat service, garantie en renewals allemaal lezen. Bij connected devices is telemetrie het lastige deel, want device-events mogen niet regel voor regel in de org landen.

Wat is Salesforce Asset Service Lifecycle Management?

Salesforce omschrijft ASLM als een manier om "de hele levenscyclus van asset-serviceactiviteiten te beheren" (Salesforce Help). In de praktijk valt het in vijf capaciteitsgebieden uiteen:

• Assetzichtbaarheid. Asset Interactive Hierarchy toont parent- en child-assets, en Asset Coverage View legt de entitlements van een klant voor de agent neer.
• Serviceuitvoering. Work Order Estimation prijst werk voordat het begint, Book Service Appointment regelt de planning en Product Service Campaign draait recalls en upgrades op grote schaal.
• Retouren en reparatie. Advanced Exchange maakt retour- en vervangingsverzoeken aan, Depot Repair handelt units af die voor reparatie terugkomen en Service Parts Return dekt beschadigde onderdelen die aan work orders hangen.
• Serviceinventaris. Voorraadtoewijzing, batchbeheer, zoeken en overboeken, tellingen en aanvulling.
• Arbeid en AI. Timesheets en Labor Cost Optimization, plus Agentforce for ASLM, dat agentsjablonen biedt voor voorraadtaken en service-inschatting.

Kort gezegd: standaard Salesforce geeft je het asset en de dekking ervan, en ASLM voegt de serviceprocessen toe die eromheen draaien.

Welke clouds en licenties heeft ASLM nodig?

Volgens hetzelfde Help-artikel is ASLM beschikbaar in Lightning Experience voor Service Cloud, Manufacturing Cloud, Automotive Cloud, Communications Cloud, Consumer Goods Cloud, Energy and Utilities Cloud en Media Cloud. Sommige features vragen om add-on-licenties, aan te schaffen via Salesforce Go, dus bekijk de editietabel per feature voordat je erop plant.

Twee verwante producten worden er makkelijk mee verward. Toen Salesforce ASLM in juni 2024 als losse add-on aankondigde, kondigde het ook Connected Assets aan, een aparte add-on om te reageren op tweewegs-telematica-events zoals firmware-updates, het aanmaken van work orders of veiligheidsmeldingen, en een Asset Health Score voor Field Service (Futurum Group). ASLM is de servicelaag. Connected Assets en je eigen integratie vormen de telemetrielaag.

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. De integratiegebruiker die ze publiceert authenticeert meestal via een connected app, dus laat die vooraf toetsen aan onze gids over de beveiligingswijzigingen voor Salesforce connected apps.
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. De volledige uitsplitsing staat in hoe teams met verbonden apparaten hun supportcases met 93 procent verlaagden op Salesforce.

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.
• Recalls en upgrades bereiken de juiste units, omdat een product service campaign alleen assets kan bereiken met een echt model, serienummer en firmwareversie.
• 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. Zet pas daarna ASLM-features zoals estimation, campagnes en exchanges aan, samen met servicecontracten, renewalprognoses en agents.

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, lees dan hoe Tekunda asset lifecycle management op Salesforce aanpakt, naast Field Service en connected-device delivery.

FAQ

Wat is Salesforce Asset Service Lifecycle Management in een zin?

Een set Salesforce-features om geinstalleerde assets end-to-end te onderhouden, van hierarchie en dekking tot estimates, recalls, exchanges, reparatie en serviceinventaris.

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.