Afgelopen vrijdag vierde Basic Orange haar twintigjarig bestaan. Eind 2008 begon ik als projectmanager bij dit internetbureau, midden in de Amsterdamse binnenstad. Van online projectmanagement had ik nog niet zo heel veel kaas gegeten, maar het soort klanten waarvoor wij werkten kende ik maar al te goed: culturele instellingen. Op een donderdagmiddag zat ik samen met Hans aan een website voor een theater te werken. Ik probeerde Hans uit te leggen wat de klant in gedachten had. Dat ging niet helemaal goed…
Hans en ik zaten duidelijk niet op één lijn.
“Snap je eigenlijk wel dat iedere online applicatie uit drie onderdelen bestaat?”
Ik blijf Hans glazig aankijken, dus hij vist een A4-tje uit de printer en begint te tekenen. Eerst een cilinder met daaronder een kleine letter d en een hoofdletter B: dB, database.
“Daar zitten alle gegevens in.”
Vervolgens een vierkant met daaronder de letters www, de voorkant van de website.
“Hier worden de gegevens getoond.”
En tenslotte tekent Hans twee horizontale pijlen: eentje vanuit de database naar de website (“Dit is de code die gegevens uit de database haalt, zodat deze in de website getoond kunnen worden.”) en eentje vanuit de website naar de database (“Code om gegevens in de database weg te schrijven.”).
Inmiddels is het alweer 5 jaar geleden dat ik bij Basic Orange vertrok, maar ik denk nog vaak terug aan Hans en zijn tekening. Ik merk namelijk dat ik niet alleen ben/was in mijn onbegrip en dat veel mensen die bezig zijn met online marketing en dienstverlening, zich niet beseffen dat iedere online applicatie uit 3 delen bestaat: de database waar alle gegevens inzitten, een voorkant voor de gebruikers van de applicatie (een website, maar ook een app, een content management systeem of een customer relationship management tool) en de code waarmee gegevens in de database kunnen worden weggeschreven en kunnen worden opgehaald.
Vroeger was het vaak zo dat al deze onderdelen door dezelfde partij werden ontwikkeld en beheerd. De bezoekers van jouw website (voorkant) zagen informatie die jij via het CMS (nog een voorkant) in de database had ingevoerd. De code zorgde ervoor dat je informatie kon wegschrijven, maar ook dat deze opgehaald en aan bezoekers getoond kon worden. Alle onderdelen werden gebouwd en beheerd door dezelfde partij. Vaak ook op dezelfde fysieke locatie (een server ergens in een serverpark). Tegenwoordig is dat anders en dat maakt het allemaal nog iets ingewikkelder. Iedere online applicatie bestaat echter nog steeds uit drie elementen: een database, code en een (of meerdere) voorkant(en).
Een paar voorbeelden…
Als jij van achter jouw laptop een LinkedIn-profiel aanmaakt, voer jij allerlei persoonlijke informatie in via de website. De code ontwikkeld door LinkedIn zorgt ervoor dat deze gegevens in een LinkedIn-database worden opgeslagen. De database met jouw en mijn gegevens staat waarschijnlijk op een server ergens in Ierland. Of dit voor de website en de code ook zo is, is nog maar de vraag. Voor de werking van het platform LinkedIn maakt het in ieder geval niets uit.
Als je vervolgens onderweg naar een potentiële klant vanuit de trein nog even snel haar profiel checkt via de LinkedIn-applicatie gebruik je een andere voorkant (de app) om bepaalde informatie uit de LinkedIn-database op te halen. Je zal echter merken dat niet alle informatie zichtbaar wordt in de app. Dit komt niet doordat deze informatie niet in de database zit, maar wel omdat er geen plek voor is in de voorkant van de applicatie en misschien omdat de code van de app deze informatie niet ophaalt.
Als je als bedrijf LinkedIn (of een ander sociaal netwerk) gebruikt om relaties op te bouwen met jouw klanten en potentiële klanten en je maakt geen koppeling met een eigen database blijf je afhankelijk van LinkedIn (of het andere netwerk) om bij de gegevens te kunnen en er gebruik van te kunnen maken. De vraag is of je dat wil… Je hebt namelijk nergens controle over: niet over de voorkant (LinkedIn wijzigt regelmatig het uiterlijk van haar website en applicatie), niet over de code (functionaliteiten komen en gaan) en niet over de database (afgelopen jaar was het ineens niet meer mogelijk om jouw contacten uit LinkedIn te exporteren – inmiddels is dat gelukkig wel weer zo).
Het is niet voor niets dat nieuwsbrieven tegenwoordig weer vaak worden genoemd als belangrijke en populaire tool om met doelgroepen te communiceren. Hoewel de data die jij gebruikt voor het vullen van jouw nieuwsbrieven ook vaak in databases staat die niet in jouw beheer zijn (zoals de databases van Mailchimp bijvoorbeeld), heb je toch vaak meer mogelijkheden als het gaat om het beheer van persoonlijke gegevens van jouw abonnees. Hiermee is een nieuwsbrief-applicatie al meer een systeem om relaties mee te managen. Iets wat LinkedIn voor individuele gebruikers ook meer en meer probeert te zijn. Maar laten we eerlijk zijn: een relatie bouw je niet alleen op via LinkedIn of een nieuwsbriefapplicatie. Het is de optelsom van allerlei inspanningen via diverse middelen.
Het belang van klantdata voor iedere organisatie
Een echte CRM-applicatie is dan eigenlijk ook onontbeerlijk als jij en jouw collega’s relaties opbouwen en versterken met jullie doelgroepen, via social media, maar ook via e-mail, telefoon en face-to-face-meetings. Het is erg prettig om zelf het beheer over de database te kunnen voeren. Daarnaast is het vaak ook mogelijk om gegevens door mensen zelf te laten beheren. Via een API kan er contact met een database worden gemaakt (die net per se in jouw beheer is), zodat er gegevens opgehaald of weggeschreven kunnen worden.
Ook LinkedIn (en andere social media) kennen dergelijke API’s. Als jij een inlog op jouw website via social media mogelijk maakt, wordt allerlei persoonlijke informatie uit iemands social media profiel (of eigenlijk de achterliggende database) opgehaald en overgezet naar jouw eigen database. Op deze manier sla je meerdere vliegen in één klap: mensen hoeven niet opnieuw hun gegevens in te voeren (dat hadden ze immers al gedaan toen ze hun profiel aanmaakten), de gegevens zijn meestal up to date en je zet ze over van de LinkedIn-database naar een database in eigen beheer. Fijn als je er een volgende keer gebruik van wilt maken.
Ik ben Hans nog steeds dankbaar voor zijn uitleg jaren geleden. Hopelijk heb ik zijn verhaal goed begrepen en uitgelegd, zodat jij er ook iets aan hebt.
Uitgelichte afbeelding: Jochem Koole, licentie: CC BY