In één keer een digitale klantreis ontwerpen die een paar jaar mee kan? Dat kan niet. Want om een klantreis echt goed te krijgen, moet je hem testen, aanpassen, weer testen, weer aanpassen etc. Bovendien veranderen markten snel en wil je kunnen reageren als de eisen van je eindgebruikers veranderen of als je concurrent met een nieuwe feature komt. Hoe je zo’n flexibele, wendbare klantreis een solide basis geeft vertellen we je in dit artikel.
In een eerder blog hadden we het over hoe een succesvolle crosschannel klantreis eruitziet en hoe je hem ontwerpt. Maar het bedenken van een klantreis is pas de eerste stap. Daarna moet je hem ook nog bouwen, uitrollen, testen en continu aanpassen en verfijnen. Om dat snel en flexibel te kunnen doen, heb je een slimme architectuur nodig.
Digitale klantreizen anno nu
Aan die architectuur worden steeds hogere eisen gesteld, nu klantreizen steeds complexer worden. De tijd dat ‘online’ bestond uit alleen een website of een app is voorbij. Bijna alle digitale ervaringen gaan tegenwoordig over meerdere kanalen heen (‘crosschannel’) en bevatten één of meerdere ‘fysieke’ componenten, zoals een winkelbezoek, een check-in op locatie of een betaling bij een betaalzuil. Kanalen veranderen en vernieuwen ook snel. We werken op het moment bijvoorbeeld veel met SMS-updates en WhatsApp. Maar het landschap voor tekstberichten kan er over een paar jaar totaal anders uitzien. De architectuur van je digitale klantreis moet daarop voorbereid zijn en zorgen dat je snel kunt schakelen.
Lees ook: De ‘digital only’-klantreis stelt hele speciale eisen aan je bedrijf.
Minimum Viable Product
Maar eerst is het belangrijk dat je snel live kunt. Want niemand heeft iets aan een klantreis die alleen op papier bestaat. Om snel een werkend product te hebben, splitsen we de lijst met functies die we willen bouwen op in kleine stukjes. Hoe kleiner die stukken zijn, hoe sneller we iets kunnen bouwen dat echt werkt. Deze ‘core-functionaliteit’ realiseren we in een Minimum Viable Product (MVP). Dat is een eerste product, meestal een app of een website, dat verre van ‘klaar’ is, maar waarvan we zeker weten dat zowel onze opdrachtgever als de gebruiker er echt iets aan hebben.
Neem bijvoorbeeld een reserveringsapp voor theatertickets: als je het programma kunt bekijken, kunt reserveren en de betaalflow werkt, dan heb je een werkend product dat live kan. Is dat dan de ideale digitale klantreis? Waarschijnlijk niet. Maar door goed te kijken hoe mensen je MVP gebruiken, kun je leren wat ze belangrijk vinden en hoe je de klantreis kunt verbeteren.
Backend als solide basis
Het idee van een MVP is dus om snel live te zijn, zodat je investering zo snel mogelijk rendeert, en daarna flexibel verder te bouwen. Om daarin een goede balans te vinden, bouwen we qua datamodel en logica alleen wat we nodig hebben om met het MVP live te kunnen. Maar we bouwen de backend wel zo, dat hij losgekoppeld van de frontend kan functioneren. En dat alle data en logica die erin zitten ook voor andere kanalen meteen bruikbaar is.
Ook al lanceren we als MVP dus een simpele site of app, we bouwen altijd een backend die kan koppelen met alle relevante systemen. Dat kost wat extra moeite, maar die investering betaalt zich later terug. Want als de basis niet stevig staat, wordt iedere aanpassing een project op zich en gaan je innovaties veel te langzaam. Ook de technische risico’s nemen enorm toe, omdat je niet precies weet waar je data staan en welke afhankelijkheden er zijn.
Monoliet vs. Microservice
Er zijn twee manieren om een backend te bouwen voor je crosschannel klantreis: monolithisch en met microservices. Een monolithische implementatie brengt alle functionaliteit samen in één stuk software. Een architectuur met microservices lanceert voor ieder stukje functionaliteit een apart, geïsoleerd programma. De ‘microservices versus monoliet’-discussie leidt onder developers nog wel eens tot verhitte discussie. En hoewel microservices zeker bepaalde voordelen hebben, kiezen wij meestal voor een monolithische implementatie. Op die manier kunnen we snel nieuwe functionaliteiten toevoegen en nieuwe kanalen koppelen, zonder al te veel complexiteit te creëren in de backend.
Welkom in de snoepwinkel
Eigenlijk bouwen we eerst, in plaats van een rechte weg van A naar B, een grote rotonde met maar één afslag. Dat lijkt veel extra werk, maar je hebt er pret van als je nieuwe wegen wilt aansluiten. Omdat de rotonde er dan al ligt, hoef je alleen maar een nieuwe afslag te maken. En is een bepaald kanaal verouderd of niet meer relevant? Dan gooien we het eruit. Ook dat is makkelijk, want dit soort beslissingen raakt de kern van de klantreis nauwelijks. Want experimenteren is goed, maar je mag daarmee nooit de core functionality, zoals inloggen of betalen, verstoren.
Designers en opdrachtgevers vinden dit een bijzonder prettige manier van werken. Ze hebben het zelfs regelmatig over de ‘snoepwinkel’: de mogelijkheid om snel en makkelijk naar behoefte nieuwe kanalen en nieuwe touchpoints toe te voegen. SMS, push-notificaties, verhuurautomaten of betaalzuilen: ze kunnen allemaal, altijd beschikken over alle nodige data om een perfecte gebruikerservaring te bieden.
Wat wil de eindgebruiker eigenlijk?
De monolithische structuur heeft nog een voordeel: al je data staan op dezelfde plek. En die data hebben we nodig om antwoord te krijgen op de vraag: ‘Wat wil onze gebruiker eigenlijk?’ Een goede backend laat je, in theorie, ook binnen de huidige wetgeving, meekijken met alles wat een gebruiker doet. En dat kan nuttig zijn. Maar er zijn veel effectievere manieren om op data te sturen. Dat begint met keuzes maken: waar wil je op sturen? Wat zijn je doelen?
Deze doelen vormen de basis van je meetplan en je meetplan is de basis van een dashboard. Dat dashboard vormt vervolgens het hart van je operatie. Dat hangt op grote schermen op kantoor, zodat iedereen kan zien wat het succes is van de aanpassingen die we doen aan de diverse kanalen.
De informatie op het dashboard vertelt ons hoe de klantreis presteert, voor ons en voor onze opdrachtgever. Door met een agile proces te werken (wij kiezen tegenwoordig meestal voor Kanban in plaats van Scrum, om nog makkelijker te kunnen switchen en sturen) bouwen we altijd aan de features die de ‘meters’ op het dashboard het meest in de goede richting bewegen.
De efficiëntste weg naar een crosschannel klantreis die werkt
Wil je dus efficiënt een klantreis bouwen die echt werkt? Bouw dan een Minimum Viable Product met een backend die snel uit te breiden is en waarin al je data en functionaliteit herbruikbaar zijn. Begin met het minimale aantal kanalen, maar sta klaar om te reageren op de signalen in je gebruiksdata. Zo weet je precies wat je volgende stap moet zijn en ben je ook wendbaar genoeg om hem snel te zetten.
Webinar
De bouw van een digitale crosschannel klantreis staat altijd bol van de spanning tussen klantervaring, business value, tijd en budget. De enige manier om daarmee om te gaan is: harde keuzes maken. Maar hoe doe je dit en welke keuzes maak je?
Onze experts vertellen je in een webinar welke keuzes je moet maken voor een perfecte klantreis: welke soorten apps onderscheiden we en welke moet je wanneer inzetten? Hoe bouw je een backend die alle soorten apps kan ondersteunen en hoe blijf je apps en klantreizen continu data-based doorontwikkelen? Wil je dit webinar bekijken, vraag hem dan aan!
