Je herkent het vast wel. Een gaaf idee bedacht voor op de website. Of een nuttige nieuwe functie in de Mijn-omgeving van je website. Zo eentje waarvan je zeker weet dat dit je klanten echt gaat helpen. Het verzoek bij development ingediend. Maar ze zitten deze periode helemaal vol. En ze hebben ook nog eens te kampen met onderbezetting door vakanties en personeelstekort. Moet je dan echt langer wachten? In dit blog neem ik je mee hoe ik samen met mijn collega’s onze e-mailtool regelmatig als (tussen-)oplossing voor dit probleem inzet. Zo kun je sneller itereren met je ideeën en innovaties, terwijl je zelf in controle blijft én de druk op development verlaagt.

Afhankelijk van schaarse developmentcapaciteit

Het is ook niet gek natuurlijk. Goede developers groeien helaas niet aan de bomen maar zijn – net als diverse andere beroepen – erg schaars. We kunnen niet even tien extra developers aannemen, al zouden we het willen. En degenen die er zitten, hebben hun al dagen gevuld met belangrijk werk. Om over de hoeveelheid taken op hun backlogs nog maar te zwijgen. Jij staat samen met andere marketeers en product owners in de wachtrij. En er zijn andere dingen die (meestal om goede redenen) hogere prioriteit krijgen waardoor jouw verzoek telkens weer doorschuift. Want natuurlijk kunnen we niet alles tegelijk doen. Begrijpelijk, maar wel vervelend.

Net als bij veel andere bedrijven is dit ook in mijn werk bij Centraal Beheer aan de orde. We hebben daar een heel stel developers en IT-ers van grote klasse zitten. Maar ook zij hebben per persoon maar één stel hersens en twee handen om mee te werken. En ook maar hun maximale uren aan werktijd. Oh, en ja, zij hebben ook zo’n enorme backlog door alle wensen en innovaties die vanuit een ambitieuze organisatie zoals Centraal Beheer worden aangevraagd.

Je erbij neerleggen of zelf de regie pakken?

Ik ben niet het type dat dan denkt: ‘Oh, nou dan wachten we wel netjes tot we aan de beurt zijn’. Klinkt verstandig, maar is niet altijd even snel natuurlijk. Zeker niet bij een grote organisatie waar heel veel gebeurt. Dan kunnen prioriteiten ook snel veranderen en (om overwegend goede redenen) jouw verzoek nog verder naar achteren schuiven. Maar er zijn meer wegen die naar Rome leiden. Door te kijken naar wat wél kan, in plaats van je neer te leggen bij wat niet kan. Enige is wel dat je binnen je eigen mogelijkheden moet blijven om je slagvaardigheid te behouden. Als je een oplossingsroute kiest waarbij je weer afhankelijkheden krijgt met een andere afdeling, behoud je opnieuw niet de regie om zelf je (tijdelijke) oplossing te kunnen realiseren.

Sneller itereren met je e-mailtool

Ik heb hier samen met mijn team een oplossing voor gevonden die ons al vaak heeft geholpen en nog steeds vaak helpt. Wij gebruiken namelijk geregeld onze e-mailtool CanopyDeploy als plek om onze MVP (Minimum Viable Product) te maken. In CanopyDeploy hebben we namelijk tot op zekere hoogte data van onze klanten tot onze beschikking, maar ook de mogelijkheid om gepersonaliseerde e-mails, landingspagina’s en campagneflows te maken. Daardoor kan je bijvoorbeeld een tijdelijke versie van een bepaald formulier, een wizard/keuzehulp of een administratief proces ook daar bouwen. En vooral ook: daar leren en itereren. Zodat wanneer jouw verzoek wél aan de beurt is bij development, ze een al geteste en geïtereerde versie van het oorspronkelijke idee kunnen gaan maken. Bovendien vraagt men om goed te kunnen prioriteren vaak om een business case. Voor een nieuw idee is die er vaak niet. Door eerst een tijdje op deze manier een MVP in je e-mailtool in te zetten en goed te meten kun je een veel gerichtere business case opstellen. Dan sla je meteen een paar grote slagen tegelijk.

Deze aanpak heeft voor- en tegenstanders

Je begeeft je hiermee op een gebied waar je zowel voor- als tegenstanders treft. De collega’s van onder andere marketing, sales, klantenservice en administratie staan op de banken. Hun wensen en problemen worden immers veel eerder opgepakt dan wanneer ze moeten wachten tot development in de mogelijkheid is hiermee aan de slag te gaan. Maar op hun beurt vinden ze het bij IT en development niet altijd prettig dat er op meerdere plekken systemen worden gebouwd die eigenlijk onder hun toezicht zouden moeten vallen. Of, zoals ze dat hier noemen: dat we iets maken in een programma dat hiervoor niet de ‘doelarchitectuur’ is. En dat is natuurlijk volledig terecht. Wij vinden het moeten wachten irritant. Maar zij vinden het net zo irritant als wij vanuit marketing ons in hun werkgebied gaan zitten bemoeien. Ook al is dat van beide kanten met de beste bedoelingen.

In deze markt zijn snelheid en wendbaarheid grote wapens

Het is dus van groot belang om hierbij open en transparant te zijn. Mijn doel is niet om iets te creëren dat mijn IT- en development collega’s niet wenselijk vinden. Maar aan de andere kant moeten zij op hun beurt ook begrip hebben voor het feit dat we niet met alle ontwikkelingen maar maanden of zelfs jaren kunnen wachten. De markt om ons heen ontwikkelt als een razende. En hoewel veel bedrijven en veel concurrenten ook vergelijkbare problemen hebben is het een dooddoener om daardoor maar je erbij neer te leggen dat het niet anders is. “Maar onze concurrenten doen dit ook nog niet” is voor mij echt als een rode lap voor een stier. Juist wanneer concurrenten deze problemen óók hebben is dit bij uitstek het moment om – als je daartoe in staat bent, zoals wij via bijvoorbeeld onze e-mailtool – extra gas te geven. Dan pak je immers de kans op een voorsprong.

Kijk niet alleen naar je concurrenten, maar juist naar degenen die de toon zetten

Bovendien vind ik sowieso dat je niet te veel naar je concurrenten moet kijken. Goed om te weten waar ze mee bezig zijn. Maar je moet je meten langs de lat van de partijen die op het gebied van de digitale customer experience waar we naar streven de absolute top vormen.

Neem nou de op dit gebied inmiddels bijna cliché geworden voorbeelden zoals Coolblue, Bol.com of (die noem ik zelf graag) Knab. Dat je op dit gebied cliché genoemd wordt door mij is denk ik het grootste compliment dat ik je zou kunnen geven. Partijen die op het gebied van digitale klantervaring naar mijn mening de toon zetten.

Bedenk je goed dat jouw klanten misschien ook wel zakendoen met een concurrent van je, maar daarnaast ook vast wel eens iets hebben besteld bij Coolblue of Bol. Of misschien bankieren bij Knab. En als ze daar het totale gemak, de eenvoud en de snelheid van een goede customer experience ervaren, nemen ze die ervaring mee in alle ervaringen die daarna komen. De klant vergelijkt jou niet met je concurrenten. De klant vergelijkt de ervaring bij jou met ervaringen bij andere bedrijven. En als je bij Knab iets snel in je Mijn-omgeving kunt regelen binnen een paar tellen, en eenzelfde soort verzoek kost bij jou vijf werkdagen en vereist een door jou ondertekende brief die nog met de post moet komen, dan werkt dat negatief. Hoe goed jouw product verder ook is.

“Digitaal gebruiksgemak is een commodity geworden”

Een van de absolute specialisten op het gebied van customer experience is naar mijn idee Steven van Belleghem. Ik heb hem diverse keren mogen zien en horen spreken en heb meerdere van zijn boeken gelezen. Het digitale gebruiksgemak is – zeker sinds de coronatijd – echt een absolute vereiste geworden. Of zoals hij het zegt: “Digitaal gebruiksgemak is een commodity geworden”. Bij veel bedrijven is digitaal gebruiksgemak zo normaal geworden dat de lat bij consumenten heel erg hoog is komen te liggen.

Mensen zijn eigenlijk verwend geworden door hoe makkelijk alles tegenwoordig te regelen is. Maar dat zorgt er dus ook voor dat wanneer jij die lat niet haalt of niet kunt halen, je eigenlijk al snel afvalt. Partij A kan je nieuwe trui vanavond nog leveren en je mag achteraf betalen. Partij B levert over drie werkdagen en je moet vooraf betalen met iDeal of een overboeking. Of: bij partij A moet je morgen bellen tijdens kantooruren om een extra rekening te laten openen en bij partij B regel je dat met een paar drukken zelfs midden in de nacht in de app. Welke kies jij? Zo hard is het nou eenmaal geworden. En de consumenten zijn daar natuurlijk, gelukkig, de grote winnaars van.

Voordelen van het inzetten van je e-mailtool als MVP-machine

Dit is een goed moment om weer even terug te komen op dat inzetten van je e-mailtool als MVP-machine. Daar ging dit blog tenslotte over. Met je e-mailtool kun je dus, binnen je eigen invloed, (tussen)oplossingen realiseren. Zo kun je in plaats van wachten tot je aan de beurt bent, toch al een paar stappen naar voren zetten in de tussentijd.

En dat heeft een stapel voordelen, is mijn ervaring:

Een grafiek waarmee het verschil in winst op gebied van tijd en klantervaring wordt aangeduid tussen de route waarbij je wacht op development, of zelf al eerder een MVP in bijvoorbeeld je e-mailltool lanceert zodat je sneller itereren mogelijk maakt.
  • De druk op development verlaagt, want het probleem of de wens die je aanpakt wordt nu al aangepakt. Ook al is het een tussenoplossing en niet de eindoplossing, toch wordt er al een stap in de goede richting genomen.
  • Tijdens het ontwikkelen en itereren heb je binnen de emailtool alles in eigen hand. Daardoor ben je dus niet afhankelijk van collega’s van development om bijvoorbeeld pagina’s en formulieren op te bouwen, maar doe je dit gewoon zelf.
  • Je kunt al veel eerder testen en door itereren met de beoogde oplossing. Daardoor kun je wanneer je verzoek aan development wordt opgepakt, hen een al verder uitgewerkte en gevalideerde versie briefen. Zo pak je tijdswinst terwijl je moest wachten.
  • Tijdens het testen en door sneller itereren kun je ook ontdekken dat een idee misschien helemaal geen goed idee is. En dat kun je dan al concluderen vóórdat de developers hun zeer kostbare tijd eraan zouden gaan ‘verspillen’.

Inmiddels een beproefd concept

Op deze manier heb ik met mijn collega’s al diverse gave casussen ontwikkeld in onze e-mailtool. Daarmee hebben we de ergste pijn in zulke gevallen bij marketing, sales, klantenservice en administratie kunnen wegnemen. We hebben onze klanten veel eerder een digitale ervaring kunnen bieden en sneller kunnen itereren. Maar zo ook de druk op development kunnen verlagen. Deze werkwijze lost de problemen niet op, maar neemt wel de ergste pijn weg. En niet onbelangrijk: we hebben alle betrokken afdelingen daardoor dichter bij elkaar gebracht. Want laten we niet vergeten: mijn team en ik hebben de collega’s van de andere betrokken teams heel hard nodig. Maar op hun beurt, zij ons ook.

“Alleen ga je sneller, samen kom je verder.”

Share This