Hoe een headless CMS toch slim kan zijn

Er wordt de laatste tijd veel geschreven en gesproken over headless content management. Het vertrekpunt van de discussie is daarbij doorgaans dat er twee categorieën CMS-systemen zijn: volledige headless systemen, waarbij voor iedere nieuwe touchpoint ook een nieuwe presentatielaag ontwikkeld moet worden, en pagina-gebaseerde systemen die een onlosmakelijk geheel vormen met de desktop website. De werkelijkheid is veel genuanceerder en biedt een heel scala aan opties die tussen deze twee uitersten in liggen.

Daarbij kun je denken aan een experience as a service-oplossing, waarbij het CMS gedeeltelijke pagina-rendering verzorgt, of een hybride CMS-oplossing die – net als een headless CMS – content kan uitleveren naar ieder gewenst kanaal maar ook een presentatielaag heeft. Hierdoor kunnen alle verschillende kanalen met elkaar verbonden worden en creëer je geen content silo’s.

Een headless CMS creëert data-eilandjes

Om het aanschouwelijk te maken, zou je een digital experience kunnen vergelijken met een eiland. De interactie met de websitebezoeker vindt daarbij aan de oppervlakte plaats, terwijl content en data door middel van ondergrondse pijpleidingen heen en weer worden getransporteerd. In een volledig headless scenario creëer je met ieder nieuw kanaal (microsite, mobile site, in store display, intranet, etc.) dat je toevoegt een nieuw, losstaand data-eilandje. Met als gevolg dat je een nieuwe brug moet bouwen en nieuwe ondergrondse pijpleidingen aan moet leggen. De verschillende data-eilandjes die je op deze manier creëert, communiceren slecht met elkaar omdat ze allemaal individueel up-to-date gehouden moeten worden.

Een hybride CMS zorgt voor een connected experience

Wanneer je als bedrijf voorop wilt blijven lopen met innovaties en je snel wil kunnen aanpassen aan veranderingen in de markt, is het van groot belang dat je snel kunt schakelen en kunt experimenteren met nieuwe touchpoints. Om daarbij een consistente customer journey te waarborgen, is het essentieel dat die verschillende touchpoints content, assets en data met elkaar kunnen uitwisselen. Een hybride CMS voorziet in die behoefte. In plaats van met veel moeite voor ieder nieuw marketinginitiatief nieuwe bruggen te bouwen, breid je gewoon je oorspronkelijke eiland uit, waardoor je heel gemakkelijk nieuwe touchpoints kunt ondersteunen. Tegelijkertijd kunnen die touchpoints content en data direct met je hele digitale landschap delen.

Silo’s staan haaks op personalisatie

De grootste valkuil en het grootste risico van een headless CMS is dan ook het feit dat in silo’s georganiseerde systemen per definitie niet of slecht onderling communiceren. Dat geldt niet alleen voor verschillende touchpoints, maar ook voor teams, assets en integraties met andere systemen. Op presentatieniveau zorgt dit gebrek aan uniformiteit voor een gefragmenteerde klantreis, waarbij iedere touchpoint een andere look & feel heeft, ze niet dezelfde informatie weergeven of een andere boodschap uitdragen. Een dergelijke gebroken klantreis is in de huidige tijd niet meer acceptabel. Voor de klant maakt het immers niet uit welk kanaal hij gebruikt – hij wil overal dezelfde perfecte ervaring.

Onder de oppervlakte, daar waar alle data en content zich bevinden, zorgen headless silo’s voor een nog veel groter probleem: ze hinderen personalisatie. Om cross-channel te kunnen personaliseren is voortdurende communicatie nodig tussen alle touchpoints en externe applicaties, zoals CRM-systemen en transactionele platformen. In een volledig headless scenario komt personalisatie dan ook vaak met horten en stoten tot stilstand.

Echte flexibiliteit is flexibiliteit voor iedereen

De reden waarom er momenteel zoveel over headless CMS wordt gesproken is de vermeende agility bij het creëren van nieuwe touchpoints. De realiteit is dat bedrijven vaak een groot aantal van elkaar losstaande touchpoints creëren, die in de praktijk lastig te onderhouden blijken. Dit legt een enorme druk op de ontwikkelaars, die voortdurend de functionaliteiten en templates van iedere integratie in het oog moeten houden. Maar ook op de marketeers, die voor iedere afzonderlijke touchpoint nieuwe content moeten creëren. Bovendien is het publiceren van nieuwe content zonder een presentatielaag en de bijbehorende preview-optie vaak een schot in het donker – met alle risico’s van dien.

Door content onafhankelijk van de presentatielaag op te slaan kun je naar hartelust experimenteren met nieuwe kanalen. Wanneer iedere kleine aanpassing aan die kanalen echter gepaard gaat met meerdere overlegrondes tussen marketing en IT, verlies je al snel de flexibiliteit waarvoor je nu juist een headless oplossing had gekozen. Precies om die reden zijn hybride CMS-systemen zo ideaal: niet alleen houden ze content en presentatie gescheiden, ze beschikken eveneens over een ingebouwde cross-channel presentatielaag. Content kan op die manier formaat-neutraal gebruikt worden – iets waar ontwikkelaars blij van worden – en marketeers kunnen hun content op een eenduidige manier via alle kanalen verspreiden.

Alleen een softwarebedrijf bouwt zijn eigen software

Veel bedrijven kiezen voor een headless scenario in de blijde veronderstelling dat ze op die manier een presentatielaag kunnen bouwen die voor ieder afzonderlijk kanaal exact de gewenste templates bevat. Maar al te vaak komen ze vervolgens tot de conclusie dat wanneer je zelf de daarvoor benodigde software bouwt, je die ook zelf moet onderhouden. Dit betekent dat iedere bug fix, iedere aanpassing aan de wensen van de klant of de marketingafdeling, iedere API voor een nieuwe touchpoint en al het standaard onderhoud op het bord van je ontwikkelteam terechtkomt. Daardoor transformeren je ontwikkelaars al snel van aanjagers van innovatie naar onderhoudsmedewerkers van je presentatielaag.

Naast het voortdurende onderhoud dat in eigen huis moet plaatsvinden, betekent het bouwen van je eigen systemen ook dat ontwikkelaars rekening moeten houden met alle wensen vanuit de marketingafdeling. Het creëren en onderhouden van templates wordt daardoor automatisch ook een taak van het ontwikkelteam, aangezien voor iedere kleine aanpassing die de marketingafdeling wil maken, zoals het aanpassen van een kleur of font, de tussenkomst van een ontwikkelaar vereist is. Voor bedrijven die wereldwijd actief zijn, zal er een volledig nieuwe functionaliteit moeten worden ontwikkeld om gemakkelijk content te kunnen vertalen. Bovendien zullen bedrijven met meerdere auteurs en redacteurs een uitgekiende workflow met de geëigende gebruikersrechten moeten ontwikkelen.

Zonder hoofd maar niet zonder verstand

Het wekt geen verbazing dat een headless oplossing voor bedrijven die gewend zijn aan een star, pagina-gebaseerd CMS-systeem in eerste instantie een geschenk uit de hemel lijkt. In werkelijkheid leidt een dergelijk scenario tot het bouwen van vele verschillende bruggen naar geïsoleerde eilandjes die tijd-intensief onderhoud verlangen en uiteindelijk vertraging van de bedrijfsprocessen veroorzaken. De reden daarvoor is simpel: een headless configuratie staat gelijk aan het met duct tape repareren van een probleem dat je CMS allang had moeten oplossen.

In een wereld waarin het aantal touchpoints en marketing-technologieën voortdurend toeneemt zou de mogelijkheid om content, assets en data door alle kanalen heen te delen tot de kernfunctionaliteiten van ieder CMS moeten behoren. Om je klant op alle apparaten een consistente, interactieve en persoonlijke ervaring te bieden, heb je een oplossing nodig die de content-flexibiliteit van een headless architectuur combineert met kanaal-overstijgende connectiviteit. Alleen op die manier kun je data-intelligence in het hart (en hoofd) van je digitale merkbeleving plaatsen.