De eerste voiceservices zijn ontwikkeld en veel daarvan draaien ook. De eerste beginnersfouten zijn er uit, zou je denken. Dit zijn de zes lessen na de eerste voice-ophef.
Les 1. Het is geen reclame
We horen veel over de opkomst van voicetechnologie, maar nog bijzonder weinig over concrete learnings die zijn opgedaan met het ontwikkelen van voice services. In de afgelopen jaren is het een proces van vallen en opstaan geweest. Daarom willen we graag de lessen delen die we de afgelopen jaren hebben geleerd met de ontwikkeling van voice-services voor merken zoals KLM en LeasePlan.
De eerste les is wellicht een open deur, maar wel een van de belangrijkste als je met voice begint te werken: het is geen reclame. Voice is geen medium dat je kunt gebruiken om boodschappen naar de luisteraar te pushen. Ten minste, nog niet (het wachten is op de eerste voice-activated commercial op de Google Home). Ook is het nieuwtje er nu wel af. ‘Iets’ met voice doen gaat niet zoveel reuring meer opleveren. Er is ook nog geen advertentie structuur op de platforms zelf. Je kunt natuurlijk via andere media je service adverteren, maar het is op die manier best lastig om mensen überhaupt naar je dienst te krijgen. Tenzij je natuurlijk echt iets wezenlijks toevoegt voor de gebruiker.
Het is een service. Het gaat dus om waarde toevoegen. En dat is eigenlijk de grootste uitdaging. Want wat belangrijk is voor je klant, is misschien niet persé heel belangrijk voor jouw merk. En vice versa. We beginnen dus altijd met dezelfde vraag: wat hebben je klanten echt nodig?
Daarbij zijn we zelf de eerste om toe te geven dat we daar ook af en toe mis hebben geschoten. De lancering van de Pack Assistant van KLM in 2017 kreeg best wat aandacht. Maar we merkten ook dat de service te lang en te uitgebreid was. Het was overcompleet en mensen haakten halverwege af. Niet helemaal relevant voor mensen dus. Inmiddels zijn we een stuk verder en heeft KLM vier voice services ontwikkeld, voor het opdoen van inspiratie, het boeken van je ticket, de Pack Assistant, en de Vertrekplanner. Deze worden constant geoptimaliseerd.
Een goede voice service is ook echt een service. Het is een start-up die je constant moet onderhouden op het gebied van development, design en copy, door een toegewijd team. De moeite is groot, maar dat is de business potentie ook.
2. Stop met praten. Start met bouwen
Niemand kan in de toekomst kijken. Als we het hebben over innovatie wordt dit vaak als een nadeel gezien, omdat je minder zekerheid hebt. Wij zien dit vaak als de grootste kans die er is omdat je nog vrij kunt experimenteren. Maar dan moet je wel beginnen.
Onderzoek laat zien dat het als eerste uitrollen van een nieuw business model grote successen kan brengen, kan resulteren in tevreden klanten en je merkperceptie kan verbeteren. Maar je betaalt ook de prijs van onzekerheid. Zal voice technologie binnenkort in de zwarte cijfers lopen? Misschien. Haalt het de kritieke gebruikersaantallen die het nodig heeft? Waarschijnlijk. Zal het een van je grootste communicatiekanalen worden binnen drie jaar? Goed mogelijk. Maar we weten het niet zeker.
Hoe ontwikkel je voor het onbekende?
- Wees flexibel
‘Change is the only constant’. Wat je precies wilt oplossen of aanbieden moet helder zijn. Anders kun je ook niet toetsen of het lukt. Hoe je deze service dan vervolgens precies gaat bouwen, zal blijven veranderen. En dat is niet alleen maar door de veranderingen binnen je eigen organisatie. Google werkt continu aan updates van hun API’s, die jouw scope of work zullen beïnvloeden.
Met het bouwen van de reisinspiratie service ‘Take Me There’ voor KLM hebben we een deel van de functionaliteiten zelf gebouwd om de gebruiker om hun gewenste vertreklocatie te kunnen vragen. Ineens maakte Google het mogelijk om de locatie van het device uit te lezen nadat de gebruiker daar toestemming voor had gegeven. Uiteindelijk konden we dus automatisch een goede suggestie doen voor een vertreklocatie en was er een hoop werk voor niets.
De les? Blijf agile (om nog maar even een buzzword te gebruiken). Blijf flexibel in de deliverables (backlog), in het budget en vooral, verwachtingen (KPI’s).
- Training
De echte optimalisatie begint nadat de service live staat. En dan is het: training, training, training. Een team van mensen beoordeeld verkeerde interpretaties van DialogFlow, test verbeteringen in een staging omgeving en pushed het dan weer live.
Zo kan het bijvoorbeeld zo zijn dat je zegt dat je een vlucht wilt boeken naar ‘the Big Apple’, maar DialogFlow dit niet herkent als New York. Je kunt deze alternatieve benaming in deze context dan zelf toevoegen. Zo blijft het systeem leren nadat het live staat.
- Begin gewoon
Als je weet dat het eigenlijk pas echt goed wordt met training, is het belangrijk om gewoon te beginnen. Hou een scherpe visie op de consumentenbehoefte die je wilt bedienen, definieer een MVP, creëer een backlog en begin.
3. Denk na over je architectuur
Het is dus belangrijk om flexibel te zijn in het ontwikkelingsproces. Het punt waar we nu op ingaan hangt daar nauw mee samen: focus op je architectuur.
Niet alleen je team en organisatie moeten flexibel zijn, maar ook de techniek zelf. Het systeem achter de applicatie is net zo belangrijk als de applicatie zelf.
Beginnen is belangrijk (anders heb je helemaal geen architecture). Maar realiseer je ook dat deze eerste service zeer waarschijnlijk zal moeten worden aangepast of zelfs faalt en moet worden stopgezet. Vraag je dus direct af wat er dan gebeurt. Heb je een framework staan waar je makkelijk verschillende services in kunt pluggen? Wat gebeurt er als er een andere taal bij komt? Net zoals bij een website is er een front- en backend, en soms ook een API. Denk ook na over de lange termijn van het ecosysteem.
Daarnaast wil je ook een consistente gebruikerservaring bieden, op elk kanaal. Als je klant je iets vertelt via de Google Home, zou het handig zijn als deze informatie ook beschikbaar is voor je medewerkers bij customer services, zodat ze daar op kunnen acteren.
Een belangrijke beslissing die we hebben genomen met het ontwikkelen van de voice services samen met KLM is om niet alles in Google’s DialogFlow te bouwen. Dit zou wel de makkelijkste optie zijn geweest, maar het zou ook betekenen dat we afhankelijk zouden zijn van alle functionaliteiten van DialogFlow. Ook zou alle data via Google lopen, wat we niet willen. Om dit op te lossen hebben we ons eigen A.I. ecosysteem gebouwd dat alleen informatie doorgeeft aan Google wanneer dit wordt gevraagd. Wij gebruiken Google, maar Google gebruikt ons niet. Dit betekent (in theorie) dat we Google zouden kunnen inwisselen voor elk ander platform, als we denken dat dit beter is voor de voice service die we aan het ontwikkelen zijn. Ook maakt dit het toevoegen van nieuwe services en bijvoorbeeld een uitrol naar andere talen of Alexa een stuk makkelijker.
4. ‘Intent’ boven ‘context’
Context is de structuur van het gesprek. Bij ons begint het designproces van elke voice-applicatie met een Conversation Tree. Hierin brengen we de verwachte conversatie van de gebruiker in kaart. Een goedlopende dialoog. Maar een echte dialoog is weinig voorspelbaar.
Als mensen praten met een chatbot, passen ze hun antwoorden aan. Je vraagt: “wanneer wil je vertrekken?”. Mensen denken even na en antwoorden dan, helder en duidelijk: “Volgende week vrijdag”. Met een voice service beginnen mensen vaak al met praten voordat ze nadenken. Op de vraag “wanneer wil je vertrekken?” krijg je dan een antwoord zoals het volgende: “Uuuhmmm volgende week woensdag 18…Oh nee… 17. Dat is dinsdag, alsjeblieft.” Mensen zeggen hetzelfde maar op verschillende manieren. Mensen stappen uit de context op rare momenten, springen terug naar eerdere stappen of slaan juist stappen over. Het is geen invulformulier.
Daarom is het dus belangrijk om intent boven context te plaatsen. Met Intent Based Conversational Design leggen we eerst de focus op wat de gebruiker wil bereiken. Daarna zorgen we dat het gesprek flexibel genoeg is om op elk moment in deze intentie te voorzien. Het resultaat? We kunnen springen naar verschillende momenten in een gesprek en zelfs het gesprek even verlaten om dan op het juiste moment weer terug te komen.
DialogFlow is zo gemaakt dat het alle intents open houdt op elk punt van het gesprek. Maar het kan heel verleidelijk zijn om de intents te beperken per interactie, om zo te zorgen dat de gebruiker toch lineair door een gesprek loopt. Dat bespaart namelijk ook op de tijd dat je bezig bent met development. Op dat moment moet je keuzes maken gebaseerd op het verwachte gedrag van de gebruiker. In de praktijk zul je merken dat het heel moeilijk is om gedrag te voorspellen, en als je kijkt naar de gebruikerservaring, is het veel slimmer om alle opties voor de gebruiker open te houden.
Dit is natuurlijk wel veel meer werk. Op dit moment staat DialogFlow het uitwisselen van data tussen deze intents namelijk niet toe. Het heeft nog niet de functionaliteit om te weten wat er eerder is gezegd in het gesprek en om dat vervolgens te delen met andere stappen van het gesprek. Dit is dus nog een goede reden om niet geheel op DialogFlow te leunen in het design van je voice service.
5. De mensen en het merk
Zoals eerder aangegeven kun je je service pas valideren na je eerste release. Dit betekent niet dat je van tevoren geen research kunt doen om te zorgen dat deze eerste live-gang succesvol is. We combineren onder andere contextuele interviews, desk research en video dagboeken om de mogelijkheden van een service te verkennen en elementen in het leven van de consument te identificeren die we kunnen verbeteren. Na een brainstorm en uiteindelijke selectie van het idee bouwen we een simpel prototypen om een snelle validatie van het idee uit te voeren. Hiermee verbeter je de kans om een relevante en handige service te creëren enorm. Een goede start is het kijken naar de customer journey: welke stappen onderneemt je klant om het gehele proces rondom je product te doorlopen?
De fit met het merk: waarom doet het merk dit?
Als je eenmaal het gevoel hebt dat de service zal werken voor mensen, is het natuurlijk ook ontzettend belangrijk dat het werkt voor je merk. Als er geen connectie is tussen de oplossing die je biedt en de visie van het merk, zullen mensen simpelweg niet begrijpen wat je aanbiedt. Zelfs als de oplossing fantastisch is kan het voor het merk niet relevant zijn. Het zou onlogisch zijn voor Tesla om een kookhulp te starten of voor Coca-Cola om een reisservice aan te bieden.
Hou in gedachten dat, idealiter, de service uniek voor het merk is. Kijk naar hoe je je eigen data kunt gebruiken (die nergens anders beschikbaar is) om een relevante service te maken. Als ik een mayonaise-merk ben, zou ik een mayo recepten service kunnen beginnen. Maar ik kan Google ook al vragen om recepten met mayonaise. Dus wat voeg je dan nog toe?
De extra waarde voor je klanten kan dus vanalles zijn. Van speciale aanbiedingen tot andere services waar je specifieke klantdata gebruikt. Zo geeft Disney niet alleen Star Wars feitjes in haar voice service, maar is het een challenge. Netflix biedt niet alleen maar informatie over hun show Stranger Things, maar maakt er een game van. En KLM gebruikt in haar services data van de Schiphol API om zo passagiers te adviseren over wanneer ze thuis moeten vertrekken om hun vlucht te halen. Dit maakt de service slimmer voor KLM.
6. Hou het simpel
A.I. is nu nog niet slim genoeg als basis voor een echt goede gespreks interface. Spraakherkenning al een tijd 100% nauwkeurig, maar de manier waarop mensen met elkaar praten is moeilijk te automatiseren. Google en Amazon kunnen begrijpen wat we zeggen, maar vinden het lastig om te bepalen waarom we het zeggen. En dit is natuurlijk essentieel om een echt gesprek te voeren.
In 2017 lanceerden we Pack Assistant met KLM. Er is hard gewerkt om het echt ‘conversational’ te maken. Veel verschillende antwoorden konden geïnterpreteerd en er werden veel opties ingebouwd om ervoor te zorgen dat mensen het gesprek niet zouden verlaten. Het resultaat was technisch hoogstandje, wat zelfs werd tentoongesteld namens Google op SXSW 2018 als toonaangevend project.
Maar de service was te ingewikkeld en de drop-off rate te hoog. We realiseren ons nu dat niet alleen de techniek nog niet echt klaar is voor ‘conversational design’ maar ook mensen zelf nog niet. Daarom werken we nu een versimpeling van de service, om deze toegankelijker te maken.
De realiteit is namelijk dat mensen nog steeds moeten leren wat ze van merken kunnen verwachten op het gebied van voice. Op dit moment wordt de Google Home het meest gebruikt om de lichten aan en uit te doen, items toe te voegen aan boodschappenlijstjes en om timers te zetten. Korte commando’s die een simpele taak tot uitvoering brengen. Er is weinig sprake van een echt gesprek. En dat verwachten mensen ook nog niet. Ze verwachten korte commando’s te kunnen geven en korte antwoorden te krijgen.
Ook development kan snel gecompliceerd worden. Vooral wanneer je gebruik maakt van meerdere API’s en de service op meerdere platformen actief zal zijn in meerdere talen. De tijd en het werk dat gaat zitten in het testen, trainen en onderhouden van de services kan exponentieel oplopen.
Allemaal redenen om klein te beginnen, het simpel te houden en vanaf daar verder te gaan. Je weet niet echt hoe de platformen zich in de toekomst zullen ontwikkelen en kunt alleen maar evalueren om te verbeteren als je de gebruikersfeedback hebt. Het mooie van voice is dat de feedback enorm direct is. Als je wilt weten wat mensen van je website of app vinden, moet je ze dit actief vragen om het je te vertellen. Binnen de Google Home omgeving vertellen de gebruikers je al wat ze verwachten en van je service vinden, of je het nu leuk vindt of niet. Dit kan je ook helpen prioriteit aan te brengen in je design aanpassingen en focus aan te brengen in hoe je je service portfolio verbetert en uitbreidt.
Lees het volledige bericht op Emerce »
