Customer-success-healthscore: duidelijke signalen zonder AI

Waarom onduidelijke accountscores problemen veroorzaken

Een rood, geel of groen label lijkt eenvoudig, maar kan verbergen waarom een account aandacht nodig heeft. Een klant kan rood worden omdat het productgebruik is afgenomen, een verlenging dichtbij komt of een supportprobleem al te lang openstaat. Die situaties vragen om verschillende gesprekken.

Wanneer niemand een score kan uitleggen, verliezen customer-successmanagers hun vertrouwen erin. Ze kunnen achter een account met een tijdelijk loginprobleem aangaan en tegelijk een stille klant missen waarvan het wekelijkse gebruik al twee maanden daalt. Het label slaat alarm, maar geeft geen aanwijzing voor de volgende stap.

Onduidelijke scores maken klantgesprekken ook ongemakkelijk. Een manager kan niet geloofwaardig zeggen: «Je account loopt risico» en vervolgens niet benoemen op welke feiten dat oordeel is gebaseerd. Klanten reageren beter op een concrete observatie: «Je team heeft sinds vorige maand geen nieuw rapport meer gemaakt. Is er iets veranderd in jullie werkwijze?» Zo ontstaat een praktisch gesprek in plaats van een defensieve reactie.

Een customer-success-healthscore moet het team een gezamenlijke manier geven om accounts te vinden die aandacht nodig hebben. De score hoeft de toekomst niet te voorspellen en hoeft het oordeel van medewerkers niet te vervangen. Hij moet zichtbare signalen verzamelen, zoals recent productgebruik, onopgeloste supportverzoeken, de timing van een verlenging en vastgelegde veranderingen binnen het account.

Elk signaal heeft een regel in gewone taal nodig die een manager kan controleren. Markeer bijvoorbeeld een account wanneer het aantal wekelijkse actieve gebruikers vier weken lang met de helft daalt, in plaats van een vaag risicogetal toe te kennen. De manager kan het gebruik controleren, de accountnotities lezen en beslissen of een telefoongesprek, trainingsmateriaal of geen actie nodig is.

Transparantie maakt teamreviews ook beter. In plaats van te discussiëren over de vraag of een score «klopt», kan het team de feiten bespreken en een regel aanpassen die slechte meldingen veroorzaakt. Een eenvoudige score die mensen begrijpen helpt meer bij het volgen van klantbehoud dan een mysterieus label dat niemand vertrouwt.

Kies signalen die je team kan uitleggen

Een customer-success-healthscore werkt alleen wanneer een manager kan uitleggen waarom een account die score heeft gekregen. Begin met vier signaalgroepen: productgebruik, supportactiviteit, timing van de verlenging en accountnotities. Samen laten ze zien hoe de klant het product gebruikt, waar hulp nodig is, welke commerciële deadline dichterbij komt en wat het team tijdens echte gesprekken heeft geleerd.

Houd feiten en meningen gescheiden. Een feit kan zijn dat een account deze maand drie actieve gebruikers had, twee supporttickets opende of over 45 dagen wordt verlengd. Een mening kan zijn dat het account weinig betrokken lijkt of dat een nieuw contact ontevreden klinkt. Meningen kunnen nuttig zijn, maar koppel ze aan een eigenaar, datum en reden.

Kies signalen die mensen consequent verzamelen

Kies metingen die het team op dezelfde manier kan bijwerken. Als de ene manager een login als productgebruik telt en de andere alleen een voltooide taak, gaat de score uiteenlopen. Schrijf voor elk signaal een korte definitie en leg de databron vast.

Een eenvoudige set transparante accountsignalen kan bestaan uit:

• Productgebruik: actieve gebruikers en het voltooien van de belangrijkste workflow.
• Support: onopgeloste tickets, terugkerende soorten problemen en de tijd sinds het laatste antwoord.
• Timing van de verlenging: het aantal dagen tot de verlenging, contractwijzigingen en de vraag of een verlengingsgesprek is gestart.
• Accountnotities: een bevestigde wijziging van de interne voorvechter, een uitgesproken bedrijfsdoel of een vastgelegd risico.

Voeg geen metric toe alleen omdat je software die verzamelt. Het totale aantal logins kan indrukwekkend lijken, maar weinig zeggen over de resultaten van klanten. Ook het aantal tickets kan misleiden. Een betrokken klant die het product uitrolt, kan meer vragen stellen dan een stil account dat het product niet meer gebruikt.

Vraag bij elke metric of die de volgende actie van het team verandert. Als niemand door dat getal contact zou opnemen, training zou aanbieden, een probleem zou oplossen of zich op de verlenging zou voorbereiden, laat je de metric weg. Een kleinere score die een echt gesprek stuurt is beter dan een vol scorecard die mensen negeren.

AppMaster kan teams helpen een no-code-klantportal of interne tool te bouwen waarin deze signalen op één plek staan en de regels achter elke beoordeling zichtbaar zijn.

Meet productgebruik in de juiste context

Gebruiksgegevens helpen alleen wanneer ze het werk beschrijven dat de klant wilde doen. Alleen het aantal logins kan misleiden. Iemand kan elke dag inloggen zonder ooit de workflow af te ronden die resultaten oplevert.

Kies acties die echte vooruitgang laten zien. In een supportportal kunnen agents bijvoorbeeld tickets oplossen, managers rapporten beoordelen en klanten verzoeken indienen. In een interne operations-app kunnen medewerkers goedkeuringsstappen afronden of records bijwerken. Teams die AppMaster gebruiken kunnen bedrijfsprocessen bouwen rond de acties die ze willen meten.

Gebruik een vaste periode, bijvoorbeeld de afgelopen 30 dagen. Tel voltooide acties en actieve teamleden en vergelijk die met het recente patroon van het account. Een team dat normaal 400 workflows per maand afrondt maar er deze maand 80 doet, verdient aandacht. Een klein team dat regelmatig 20 workflows afrondt, kan gezond zijn.

Beoordeel niet elke klant tegen één universeel doel. Een account met vijf gelicentieerde gebruikers hoeft niet hetzelfde activiteitsniveau te hebben als een account met 500 gebruikers. Klantdoelen, uitrolfases en seizoensgebonden werk bepalen allemaal wat normaal gebruik is.

Houd het gebruikssignaal eenvoudig uit te leggen:

• De activiteit is stabiel of stijgt vergeleken met de vorige 30 dagen.
• De activiteit is gedurende twee beoordelingsperiodes merkbaar gedaald.
• Minder actieve gebruikers kunnen wijzen op een probleem met de uitrol, toegang of bezetting.
• Geen voltooide kernacties vraagt om een directe controle van het account.

Weinig gebruik vraagt om onderzoek. Het is geen definitief oordeel. Een school kan tijdens een vakantie minder actief zijn, of een bedrijf kan werk naar een ander team verplaatsen terwijl het de toegangsrechten bijwerkt. Controleer voordat je de status van een account verlaagt de verlengingsfase, recente supportverzoeken en accountnotities. Vraag daarna: «Is er iets veranderd in de manier waarop jullie team het product gebruikt?»

Voeg supportactiviteit toe zonder klanten de schuld te geven

Supportgegevens kunnen wrijving zichtbaar maken, maar veel tickets betekenen niet automatisch dat een account ontevreden is. Een klant kan zorgvuldige vragen stellen tijdens de uitrol van het product naar een groter team. Zie dat als betrokkenheid, tenzij de details op een probleem wijzen.

Begin met problemen die langer openstaan dan je normale reactietijd. Let op terugkerende verzoeken over hetzelfde onderwerp, vooral wanneer verschillende mensen binnen één bedrijf ze melden. Drie tickets over een onduidelijke instelling voor toegangsrechten vertellen je meer dan één korte vraag over het opnieuw instellen van een wachtwoord.

Gebruik een kleine gedeelde schaal zodat iedereen supportinteracties op dezelfde manier vastlegt:

• Positief: de klant bevestigt dat het antwoord heeft geholpen of bedankt het team.
• Neutraal: de klant heeft informatie nodig en toont geen frustratie.
• Zorgelijk: de klant meldt een geblokkeerde taak, vertraging of terugkerende verwarring.
• Urgent: het werk ligt stil, een deadline loopt gevaar of het probleem treft meerdere gebruikers.

Koppel de score aan het probleem, niet aan de toon van de klant. Iemand kan gefrustreerd klinken en toch een redelijk verzoek hebben. Het account heeft aandacht nodig wanneer een probleem blijft bestaan, terugkeert of belangrijk werk blokkeert.

Maak onderscheid tussen technische problemen en een gebrek aan training. Een technisch probleem kan een foutmelding, mislukte integratie of AppMaster-applicatie zijn die niet werkt zoals geconfigureerd. Stuur zo'n geval naar de persoon die het kan onderzoeken en volg het tot het is opgelost. Verlaag de klantscore niet alleen omdat iemand een defect heeft gemeld.

Een trainingsprobleem ziet er anders uit. Gebruikers kunnen vragen hoe ze een bedrijfsproces maken, rollen instellen of een benodigd scherm vinden. Bied een korte uitleg of praktisch voorbeeld. Komt dezelfde vraag na de hulp terug, markeer het account dan voor duidelijkere onboarding in plaats van de klant als lastig te behandelen.

Supportactiviteit moet een eenvoudige vraag beantwoorden: kan deze klant verder? Open blokkades en terugkerende onopgeloste problemen moeten het signaal verlagen. Doordachte vragen, succesvolle oplossingen en actief leren wijzen vaak de andere kant op.

Volg verlengingstiming en veranderingen binnen het account

Een verlengingsdatum moet ruim voor het einde van het contract tot actie leiden. Een score die zeven dagen voor de verlenging rood wordt, waarschuwt het team te laat. Stel signalen in op 120, 90, 60 en 30 dagen voor de datum, zodat de accounteigenaar tijd heeft voor een nuttig gesprek.

De datum zegt niet of de klant ontevreden is. Hij vertelt het team alleen dat er een commerciële beslissing aankomt. Houd dit deel van de score gescheiden van productgebruik, supportgeschiedenis en tevredenheidsnotities. Een gezonde, actieve klant kan de verlenging toch uitstellen omdat de financiële afdeling het budget nog niet heeft goedgekeurd.

Gebruik plan- en contractgegevens alleen wanneer ze de opvolging veranderen. Een groot jaarplan met een opzegtermijn van 60 dagen vraagt bijvoorbeeld om een eerdere review dan een klein maandabonnement. Ken geen belang toe alleen omdat een hogere contractwaarde urgenter aanvoelt. Het signaal moet de eigenaar vertellen wat die moet doen, niet klanten rangschikken op omzet.

Een verlengingsrecord kan bevatten:

• Verlengingsdatum en uiterste opzegdatum.
• Huidig plan, contracttermijn en voorwaarden die de timing beïnvloeden.
• Benoemde verlengingseigenaar aan klantzijde en bedrijfszijde.
• Bekend risico, zoals een budgetreview, fusie of leiderschapswissel.
• Gepland volgend gesprek en de datum daarvan.

Veranderingen binnen het account hebben eigen velden nodig. Vertrekt een executive sponsor, leg dan de datum vast, de vervangende contactpersoon als die bekend is en de volgende stap om de relatie opnieuw op te bouwen. Label het account niet automatisch als «ongezond». Een leiderschapswissel zorgt voor onzekerheid, maar gebruiks- en supportsignalen kunnen er nog steeds goed uitzien.

Behandel bekende risico's als feiten, niet als gissingen. «De klant zei dat procurement in mei met een budgetreview begint» geeft de eigenaar een reden om op te volgen. «Mogelijk geen verlenging» legt niets uit en kan het volgen van klantbehoud vertekenen.

Voor een AppMaster-klant kan het plan om een interne tool van een pilot naar een groter operationeel team uit te rollen invloed hebben op de timing van de verlenging, ook wanneer de app goed werkt. Leg het uitrolbesluit vast, wie het goedkeurt en wanneer die beslissing moet vallen. Zo krijgt het team een concrete taak in plaats van een vage waarschuwing.

Bekijk deze velden na elk verlengingsgesprek. Werk het record dezelfde dag bij wanneer de datum, het risico of het contact verandert. Transparante scoring hangt af van actuele feiten.

Gebruik accountnotities met duidelijke regels

Handmatige notities voegen context toe die productgegevens niet kunnen geven. Een daling in logins kan zorgelijk lijken, maar een recent gesprek kan uitleggen dat het team van de klant het werk tijdelijk heeft stilgelegd vanwege een geplande verhuizing. Notities kunnen een nieuw doel, een wijziging van de sponsor of een zorg uit een vergadering vastleggen.

Houd het format kort, zodat mensen het gebruiken. Elke notitie moet vermelden wat er is gebeurd, wat de klant zegt nodig te hebben en welke volgende actie is afgesproken. Vermijd notities als «goed gesprek» of «klant lijkt ontevreden». Een andere collega kan een account op basis daarvan niet eerlijk beoordelen.

Een eenvoudig format werkt goed:

• Datum en accounteigenaar.
• Reden van het gesprek of contact.
• Doel, zorg of verandering van de klant in gewone taal.
• Afgesproken actie, eigenaar en deadline.

Bijvoorbeeld: «12 mei, Priya. Kwartaalreview. De operationslead wil vóór 1 juni een goedkeuringsflow live hebben. Ze gaven aan dat twee managers nog geen toegang hebben. Priya stuurt de toegangsgegevens uiterlijk 14 mei.» De volgende accounteigenaar kan met deze notitie aan de slag. In een klantportal van AppMaster kan het team de notitie naast gebruiks-, support- en verlengingsgegevens bewaren.

Geef handmatige notities een beperkte rol in de score. Een recente, specifieke risiconotitie kan de score verlagen of een check-in activeren. Een bevestigd positief resultaat kan het vertrouwen vergroten. Persoonlijke indrukken mogen niet zwaarder wegen dan bewijs, zoals onopgeloste supportcases of een nabije verlenging zonder betrokken beslisser.

Stel een vervalregel in voor notities die invloed hebben op een score. Een zorg die 90 dagen geleden is vastgelegd, mag een account niet in een risicostatus houden als het team die heeft opgelost en nieuwer bewijs het risico niet ondersteunt. Voor elke score-update moet de eigenaar oudere notities markeren als opgelost, nog actief of niet langer relevant.

Gewone taal beschermt de klant en het team. Schrijf «De klant vroeg om de uitrol uit te stellen totdat de financiële review is afgerond» in plaats van «moeilijk account». Leg feiten, directe verzoeken en afgesproken acties vast. Laat aannames over motieven of persoonlijkheid weg.

Bouw de score stap voor stap op

Begin met een score die mensen op papier kunnen berekenen. Een bereik van 0 tot 100 is herkenbaar, maar de exacte schaal is minder belangrijk dan de schriftelijke regels erachter. Geef elk signaal een beperkt aantal punten en noteer waarom het punten oplevert of verliest.

Productgebruik kan 30 punten bijdragen, supportactiviteit 20, verlengingstiming 25 en accountnotities 25. Een manager moet een account kunnen openen en een wijziging zien zoals «-10 omdat er 21 dagen geen wekelijkse actieve gebruikers hebben ingelogd». Vermijd labels als «betrokkenheidsrisico» tenzij het systeem ook het bewijs toont.

Houd waarschuwingen en context gescheiden. Een contract dat over 45 dagen afloopt, verhoogt de urgentie, maar betekent niet automatisch dat het account ongezond is. Een plotselinge daling in actieve gebruikers in combinatie met een onopgelost supportprobleem kan wel een check-in-waarschuwing activeren. Zo blijft de score gericht op situaties die aandacht nodig hebben.

Maak scorecategorieën met een duidelijke actie:

• 80-100: zet het normale succesplan voort en zoek naar mogelijkheden voor uitbreiding.
• 60-79: bekijk de recente accountactiviteit tijdens het volgende geplande contactmoment.
• 40-59: wijs een eigenaar toe die binnen vijf werkdagen contact opneemt met de klant.
• 0-39: houd een interne review en spreek vóór het klantcontact een herstelplan af.

Bouw de eerste versie samen met customer success, support en sales. Elk team ziet een ander deel van het account. Support kan uitleggen waarom alleen het aantal tickets een slechte waarschuwing is, terwijl sales een budgetwijziging of nieuwe beslisser kan signaleren die het verlengingsrisico beïnvloedt.

Een no-code-klantportal of interne tool kan de score, puntgeschiedenis, notities en toegewezen actie op één plek tonen. Met AppMaster kan een team accountgegevens modelleren, score-regels instellen in visuele bedrijfsprocessen en ze aanpassen wanneer het proces zich ontwikkelt.

Houd voor elke regelwijziging een wijzigingslog bij. Noteer de datum, de oude regel, de nieuwe regel en de reden. Wanneer een score later verandert, kan het team zien of het klantgedrag is veranderd of de methode voor scoring.

Voorbeeld: een account dat een check-in nodig heeft

Een customer-successteam beheert een account met 42 actieve gebruikers. Maandenlang gebruikten ongeveer 30 mensen het product elke week. Deze week daalde het aantal wekelijkse actieve gebruikers naar 18 omdat een teamlid dat rapporten instelde en collega's trainde het bedrijf van de klant heeft verlaten.

Het account heeft ook twee openstaande supporttickets. In het ene ticket staat de vraag hoe gebruikersrechten na het vertrek moeten worden bijgewerkt. Het andere meldt dat een geplande data-export is mislukt. De verlenging valt over 75 dagen. Zonder context kan die combinatie tot een rode, urgente score leiden.

Een recente gespreksnotitie geeft het team een ander beeld. De operationsmanager van de klant zei dat er volgende maand een vervanger begint. Ze vroeg om een korte trainingssessie en wil dat het exportprobleem is opgelost voordat de nieuwe medewerker start. De klant noemde geen budgetbezuinigingen, ontevredenheid of plannen om te vertrekken.

Houd elk signaal zichtbaar, zodat één score de details niet verbergt:

• Gebruik: 40% lager dan de vorige week na het vastgestelde vertrek van een medewerker.
• Support: twee openstaande tickets, waarvan één invloed heeft op een routineproces.
• Verlenging: over 75 dagen, dus er is tijd om actie te ondernemen.
• Accountnotitie: de klant heeft onboardingondersteuning voor een vervanger gevraagd.

Dit vraagt om geplande opvolging, niet om een noodreactie. De customer-successmanager moet binnen twee werkdagen de status van het exportticket bevestigen en daarna een trainingssessie van 30 minuten voor de nieuwe medewerker aanbieden.

Plan een review drie weken nadat de nieuwe persoon is begonnen. Controleer of het wekelijkse gebruik stijgt, of beide tickets zijn gesloten en of de nieuwe gebruiker veelvoorkomende taken kan uitvoeren. Het team kan de transparante accountsignalen daarna bijwerken op basis van bewijs in plaats van aannames.

Een duidelijk record voorkomt een veelgemaakte fout bij het volgen van klantbehoud: elke daling in activiteit behandelen als een verlengingsrisico. Hier vraagt de daling in gebruik om aandacht, maar de gespreksnotitie verklaart die daling en geeft het team een praktische reactie.

Veelgemaakte fouten bij scoring

Een customer-success-healthscore moet een nuttig gesprek starten, geen oordeel uitspreken. Teams creëren valse alarmen wanneer ze elke daling in gebruik als churnrisico behandelen. Een maandelijkse gebruiker kan na het afronden van een project minder vaak inloggen, terwijl een operationeel team dezelfde app dagelijks slechts enkele minuten gebruikt.

Lees het gebruik in combinatie met het normale patroon en de actuele doelen van de klant. Een sterke daling is belangrijker wanneer die samengaat met een onopgelost supportprobleem, een gemiste mijlpaal in de uitrol of een naderende verlenging.

Houd regels zichtbaar. Als één persoon een ingewikkelde spreadsheet met verborgen formules beheert, kan niemand anders uitleggen waarom een account geel is geworden. Schrijf elk signaal in gewone taal op, inclusief het gewicht, de databron en de actie die het moet activeren.

Supportgegevens hebben een tijdslimiet nodig. Een oud ticket mag de score niet blijven verlagen nadat het team het probleem heeft opgelost en de klant het resultaat heeft bevestigd. Geef open problemen meer gewicht dan opgeloste problemen en verminder hun invloed na een vastgestelde periode. Een factuurvraag die twee maanden geleden is gesloten, mag niet zwaarder wegen dan stabiel productgebruik vandaag.

Contractwaarde kan het oordeel vertekenen. Een groot account verdient misschien aandacht, maar omzet heft duidelijke wrijving niet op. Als gebruikers een belangrijke taak niet meer afronden, een beheerder herhaaldelijk zorgen heeft gemeld en de verlenging dichtbij komt, heeft het team een plan nodig, ongeacht de omvang van het account.

Controleer de actualiteit voordat je handelt

Een score op basis van verouderde gegevens zorgt voor onnodig werk. Werk productactiviteit, ticketstatus, verlengingsgegevens en accountnotities volgens een vast schema bij. Vraag de eigenaar grote veranderingen te bevestigen, zoals een nieuwe sponsor, een kleiner team of een gepauzeerd project.

Controleer voordat je op een lage score handelt of de verandering in gebruik afwijkt van het normale patroon van het account, of supportproblemen nog openstaan en het dagelijkse werk beïnvloeden en of de verlengingsgegevens actueel zijn. Lees de nieuwste accountnotitie voor context. Elk teamlid moet de score kunnen uitleggen zonder een formule te openen.

Een transparante score helpt mensen zich te richten op accounts die nu contact nodig hebben. Hij mag het oordeel van de accounteigenaar nooit vervangen.

Een korte checklist voor reviews

Een healthscore helpt alleen wanneer het team hem snel kan controleren en vertrouwt op wat het ziet. Een wekelijkse review voorkomt dat kleine hiaten rond de verlenging voor verrassingen zorgen. Ook voorkomt zo'n review dat mensen een kleur of getal als het hele verhaal behandelen.

Bevestig voor elk account de verlengingsdatum. Als het account geen vast verlengingsschema heeft, leg dan uit waarom, bijvoorbeeld vanwege een maandelijkse overeenkomst of een inactief contract. Controleer de nieuwste productactiviteit samen met openstaande supportitems en lees de nieuwste accountnotitie voordat je contact opneemt met de klant. Een recent gesprek kan een personeelswijziging, vertraagde lancering of verzoek verklaren dat opvolging nodig heeft.

Elke scorewijziging heeft een reden in gewone taal nodig. «Het gebruik daalde nadat het team de beheerder verloor» is nuttig. «Score aangepast» niet. Wijs de volgende actie aan één persoon toe en voeg een deadline toe. Gedeeld eigenaarschap betekent vaak dat niemand contact opneemt met het account.

Een account kan een lagere score hebben omdat niemand 21 dagen heeft ingelogd. Voordat de eigenaar een waarschuwingsmail verstuurt, kan die een openstaand supportticket vinden en een notitie waarin staat dat de klant wacht op de configuratie van single sign-on. De juiste opvolging is dan een statusupdate over die configuratie, niet een algemeen bericht over adoptie.

Deze gewoonte maakt de score eenvoudiger te controleren. Iedereen in het team kan zien wat er is veranderd, waarom dat gebeurde en wie de volgende actie uitvoert. Een no-code-klantportal of interne accounttool kan deze velden op één scherm plaatsen, maar duidelijk eigenaarschap en regelmatige reviews blijven belangrijk.

Verwerk de score in het dagelijkse werk

Een score helpt alleen wanneer hij de volgende actie van het team verandert. Houd de eerste versie klein. Kies een groep accounts, pas één maand dezelfde regels toe en vergelijk de resultaten met wat accountmanagers uit gesprekken en e-mails weten.

Vraag managers twee afwijkingen te markeren: een account dat als gezond staat maar risicovol aanvoelt, en een account dat als risicovol staat maar in werkelijkheid stabiel is. Deze gevallen laten ontbrekende context zien, zoals een seizoensgebonden daling in gebruik of een geplande uitrol die nog niet is gestart.

Gebruik een eenvoudige wekelijkse routine:

• Bekijk accounts waarvan de score sinds de vorige week is veranderd.
• Wijs één opvolgingstaak toe met een eigenaar en deadline.
• Noteer de reden voor de actie in de accountnotities.
• Bespreek afwijkingen tussen score en werkelijkheid tijdens de teamvergadering.
• Controleer de week erna of achterstallige opvolgingen opnieuw verschijnen.

Wijzig één regel tegelijk. Geef je onopgeloste supporttickets meer gewicht, noteer dan de oude regel, nieuwe regel, datum en reden. Bekijk daarna enkele weken het effect. Meerdere wijzigingen tegelijk maken het moeilijk te bepalen welke regel de score verbeterde en welke ruis veroorzaakte.

AppMaster kan dit proces omzetten in een no-code-interne tool. Teams kunnen accountrecords aanmaken voor gebruiksgegevens, supportactiviteit, verlengingsdata, handmatige notities en scoregeschiedenis. Visuele bedrijfsprocessen kunnen de score berekenen en een opvolgingstaak aanmaken wanneer een account een gekozen drempel overschrijdt. Teamleden kunnen notities na gesprekken bijwerken via een web- of mobiele interface in plaats van belangrijke details in persoonlijke spreadsheets te bewaren.

Begin met gegevens die het team al vertrouwt. Een basis-score op basis van recent gebruik, openstaande supportproblemen, verlengingstiming en een duidelijke notitie van de manager is nuttiger dan een ingewikkeld model dat niemand kan uitleggen. Bekijk na een maand welke regels overeenkomen met echte accountsituaties en verwijder de regels die dat niet doen.