When Your Product Breaks, You Need to Own It. Here's How.
Fouten gebeuren, en bedrijven begrijpen dat. Wat ze absoluut NIET begrijpen, is wanneer je hen niet vertelt dat er iets mis is. Transparantie is key.
Sinds SaaS mainstream is geworden, vertrouwen bedrijven van alle groottes op hun SaaS-providers om hen een betrouwbare en hoogwaardige oplossing te bieden. Deze afhankelijkheid is werkelijk "missie kritisch" nu SaaS alle aspecten van de bedrijfsvoering aanstuurt. Downtime kan desastreuze gevolgen hebben voor het bedrijf.
Dit is natuurlijk geen nieuw concept; software is al tientallen jaren ontwikkeld om missie-kritische bedrijfsprocessen te ondersteunen. Het verschil is dat bedrijven met SaaS niet langer controle hebben over de werking van de software; dat ligt nu in handen van de leverancier. Degenen onder ons die ooit in de on-premise software business zaten, hebben deze les lang geleden geleerd; we waren ooit in de toepassing ontwikkeling, nu zijn we in het _leveren_van_toepassingen. Ik herinner me goed dat we in de vroege dagen van Boomi's overgang van on-premise naar SaaS, geen idee hadden van een operationeel team (waarom zouden we?) en dat we dat vanaf nul moesten opbouwen.
Dus bedrijven hebben nu een verdere afhankelijkheid van hun leveranciers, die niet alleen continue productinnovaties moeten leveren die waarde toevoegen, maar ook moeten zorgen dat de levering van die functies en de voortdurende werking van de toepassing niet invloed heeft, performant en betrouwbaar is.
Zoals dat gebeurt, worden er fouten gemaakt in dit proces. Architectonische gaten worden onthuld naarmate producten opschalen, wat leidt tot uitval. Fouten worden geïntroduceerd in releases. Hardware-upgrades verlopen niet zoals gepland. Deze leiden allemaal tot uitval en kunnen bedrijven op significante manieren beïnvloeden.
Nogmaals, fouten zoals deze zijn ook niets nieuws. Wat nieuw is, is wie de fouten maakt. In de dagen van on-premises, loop je gewoon de gang door naar je IT-afdeling en kun je je hart luchten totdat dingen zijn opgelost. Je ziet uit eerste hand de status van je problemen. Tegenwoordig weet je alleen dat je app is gestopt met werken. Je weet niet wanneer, waarom, wie eraan werkt, of wanneer het zal worden opgelost.
En dit is de belangrijkste les die ik heb geleerd van de overgang van Boomi van on-premise naar SaaS: Transparantie. Het is het allerbelangrijkste concept en zou onderdeel moeten zijn van het DNA van uw hele bedrijf. Bedrijven begrijpen dat dingen kapot gaan. Misbegrijp me niet, je moet van wereldklasse zijn, en je moet er zeker voor zorgen dat je nooit dezelfde fout twee keer maakt. Maar fouten gebeuren, en bedrijven begrijpen dat. Wat ze absoluut NIET begrijpen, is wanneer je hen niet vertelt dat er iets mis is. Er is geen snellere manier om het vertrouwen van je klant te verliezen dat je zo hard hebt verdiend.
Hier zijn een paar dingen die we bij Boomi hebben ontdekt die een grote stap hebben gezet in het succesvol beheren van klantcrises:
- Wees Proactief. Als je klant je vertelt over je uitval, ben je al verloren.
- Neem de uitval op je. Zeg dat je het verprutst hebt, zodra je dat doet. Je hoeft nog niet te weten wat er misging, maar je moet communiceren zodra je weet dat er iets mis is. Zie punt 1.
- Bied frequente updates aan. Zelfs als de update is "we werken er nog steeds aan", prima. De frequentie hangt af van de impact van het probleem en de kritiek van je toepassing. Als je helemaal offline bent en je klant geen inkomsten kan genereren, moet je elke 15 minuten updates geven.
- In je update, zeg wanneer je je volgende update zult geven.
- Zodra je weer online bent, communiceer dat onmiddellijk, en beloven om een volledig "oorzaak en corrigerende actie" rapport te leveren. Wat de oorzaak van het probleem was, en welke corrigerende actie heb je ondernomen om ervoor te zorgen dat dit niet nogmaals gebeurt.
- Bonus: als de reden voor je uitval was dat een leverancier waar je van afhankelijk bent, offline ging, is het prima om dat te zeggen, maar besef dat dit totaal niet belangrijk is voor de klant. Ze zien jou als de leverancier van de toepassing voor hen, en ze geven niet om welke externe leverancier je gebruikt, ze willen weten hoe jij ervoor gaat zorgen dat jouw app het probleem dat is opgetreden niet herhaalt.
Als je deze stappen volgt, laat je je klanten zien dat zij jouw prioriteit zijn, dat je hen altijd zult laten weten of er problemen zijn, en dat je een proces hebt om je levering continu te verbeteren. Dit draagt bij aan een langdurige relatie tussen jou en je klanten.
Sinds SaaS mainstream is geworden, vertrouwen bedrijven van alle groottes op hun SaaS-providers om hen een betrouwbare en hoogwaardige oplossing te bieden. Deze afhankelijkheid is werkelijk "missie kritisch" nu SaaS alle aspecten van de bedrijfsvoering aanstuurt. Downtime kan desastreuze gevolgen hebben voor het bedrijf.
Dit is natuurlijk geen nieuw concept; software is al tientallen jaren ontwikkeld om missie-kritische bedrijfsprocessen te ondersteunen. Het verschil is dat bedrijven met SaaS niet langer controle hebben over de werking van de software; dat ligt nu in handen van de leverancier. Degenen onder ons die ooit in de on-premise software business zaten, hebben deze les lang geleden geleerd; we waren ooit in de toepassing ontwikkeling, nu zijn we in het _leveren_van_toepassingen. Ik herinner me goed dat we in de vroege dagen van Boomi's overgang van on-premise naar SaaS, geen idee hadden van een operationeel team (waarom zouden we?) en dat we dat vanaf nul moesten opbouwen.
Dus bedrijven hebben nu een verdere afhankelijkheid van hun leveranciers, die niet alleen continue productinnovaties moeten leveren die waarde toevoegen, maar ook moeten zorgen dat de levering van die functies en de voortdurende werking van de toepassing niet invloed heeft, performant en betrouwbaar is.
Zoals dat gebeurt, worden er fouten gemaakt in dit proces. Architectonische gaten worden onthuld naarmate producten opschalen, wat leidt tot uitval. Fouten worden geïntroduceerd in releases. Hardware-upgrades verlopen niet zoals gepland. Deze leiden allemaal tot uitval en kunnen bedrijven op significante manieren beïnvloeden.
Nogmaals, fouten zoals deze zijn ook niets nieuws. Wat nieuw is, is wie de fouten maakt. In de dagen van on-premises, loop je gewoon de gang door naar je IT-afdeling en kun je je hart luchten totdat dingen zijn opgelost. Je ziet uit eerste hand de status van je problemen. Tegenwoordig weet je alleen dat je app is gestopt met werken. Je weet niet wanneer, waarom, wie eraan werkt, of wanneer het zal worden opgelost.
En dit is de belangrijkste les die ik heb geleerd van de overgang van Boomi van on-premise naar SaaS: Transparantie. Het is het allerbelangrijkste concept en zou onderdeel moeten zijn van het DNA van uw hele bedrijf. Bedrijven begrijpen dat dingen kapot gaan. Misbegrijp me niet, je moet van wereldklasse zijn, en je moet er zeker voor zorgen dat je nooit dezelfde fout twee keer maakt. Maar fouten gebeuren, en bedrijven begrijpen dat. Wat ze absoluut NIET begrijpen, is wanneer je hen niet vertelt dat er iets mis is. Er is geen snellere manier om het vertrouwen van je klant te verliezen dat je zo hard hebt verdiend.
Hier zijn een paar dingen die we bij Boomi hebben ontdekt die een grote stap hebben gezet in het succesvol beheren van klantcrises:
- Wees Proactief. Als je klant je vertelt over je uitval, ben je al verloren.
- Neem de uitval op je. Zeg dat je het verprutst hebt, zodra je dat doet. Je hoeft nog niet te weten wat er misging, maar je moet communiceren zodra je weet dat er iets mis is. Zie punt 1.
- Bied frequente updates aan. Zelfs als de update is "we werken er nog steeds aan", prima. De frequentie hangt af van de impact van het probleem en de kritiek van je toepassing. Als je helemaal offline bent en je klant geen inkomsten kan genereren, moet je elke 15 minuten updates geven.
- In je update, zeg wanneer je je volgende update zult geven.
- Zodra je weer online bent, communiceer dat onmiddellijk, en beloven om een volledig "oorzaak en corrigerende actie" rapport te leveren. Wat de oorzaak van het probleem was, en welke corrigerende actie heb je ondernomen om ervoor te zorgen dat dit niet nogmaals gebeurt.
- Bonus: als de reden voor je uitval was dat een leverancier waar je van afhankelijk bent, offline ging, is het prima om dat te zeggen, maar besef dat dit totaal niet belangrijk is voor de klant. Ze zien jou als de leverancier van de toepassing voor hen, en ze geven niet om welke externe leverancier je gebruikt, ze willen weten hoe jij ervoor gaat zorgen dat jouw app het probleem dat is opgetreden niet herhaalt.
Als je deze stappen volgt, laat je je klanten zien dat zij jouw prioriteit zijn, dat je hen altijd zult laten weten of er problemen zijn, en dat je een proces hebt om je levering continu te verbeteren. Dit draagt bij aan een langdurige relatie tussen jou en je klanten.
Ervaar de kracht van het Guru-platform uit de eerste hand - maak onze interactieve producttour
Neem een rondleiding