Hoe marketingmanagers grip houden op een schaalbare website

Leestijd: 14 minuten

Inhoudsopgave

• De website als flessenhals
• Wat er misgaat als content sneller groeit dan het systeem
• De redacteur die niet kan redigeren
• Het consistentieprobleem bij meerdere contentbeheerders
• Wat een goed CMS doet dat een slecht CMS niet doet
• Gestructureerde content: de kracht van collecties
• Contentgovernance: wie beheert wat
• Workflows bouwen rondom content
• Hoe Webflow dit oplost voor organisaties met volume
• De migratie van een rommelig systeem naar een schoon systeem
• Wat dit vraagt van een manager

De website als bottleneck

Er is een moment in de groei van een organisatie waarop de website ophoudt een communicatiemiddel te zijn en een flessenhals wordt. Dat moment is zelden dramatisch. Het sluipt erin. Eerst is het een update die drie weken wacht op een developer die het op zijn planning moet zetten. Dan is het een productpagina die verouderd is maar niemand weet hoe hij het aanpast. Dan is het een campagne die vertraging oploopt omdat de landingspagina niet snel genoeg live kan. En dan is het een team van tien mensen dat collectief wacht op één persoon met de juiste toegang tot het systeem.

Op dat moment is de website geen asset meer. Het is een bottleneck. En de manager die verantwoordelijk is voor de communicatie, de marketing of de operaties van de organisatie, staat voor een probleem dat hij niet heeft zien aankomen: het systeem dat er moest zijn om de organisatie te bedienen, werkt de organisatie tegen.

Dit document gaat over dat probleem. Hoe het ontstaat, waarom het zo moeilijk op te lossen is binnen bestaande systemen, en wat er structureel anders moet om een website met grote hoeveelheden content beheersbaar te maken voor een team dat er dagelijks mee werkt.

Wat er misgaat als content sneller groeit dan het systeem

Content groeit. Dat is geen wet van de natuur maar het is wel wat er in de praktijk gebeurt bij elke organisatie die serieus is over haar communicatie. Productpagina’s komen bij als het aanbod groeit. Blogartikelen stapelen zich op als er een contentmarketingstrategie is. Vacatures verschijnen en verdwijnen. Cases worden toegevoegd na afgeronde projecten. Nieuwspagina’s, persberichten, evenementen, landingspagina’s voor campagnes, het groeit.

Het systeem groeit doorgaans niet mee. Het werd ooit gebouwd voor wat er toen nodig was, niet voor wat er over drie jaar nodig is. En wat er in de tussentijd groeit is niet alleen de hoeveelheid content maar ook het aantal mensen dat die content wil beheren. De marketingmedewerker die de blogsectie beheert. De HR-manager die vacatures wil plaatsen. De salescollega die de productpagina wil aanpassen na een klantgesprek. De directeur die wil dat de over-pagina wordt bijgewerkt na een personeelswisseling.

Die mensen werken allemaal voor de organisatie. Ze hebben allemaal een legitieme reden om iets op de website te willen aanpassen. Maar als het systeem dat niet toelaat zonder tussenkomst van een developer, hebben ze een probleem. En de developer die elke aanpassingsvraag moet verwerken, heeft ook een probleem. En de manager die het allemaal moet coördineren, heeft het grootste probleem.

De redacteur die niet kan redigeren

Het meest concrete symptoom van een CMS dat de organisatie niet meer dient, is de redacteur die niet kan redigeren. Dit is de medewerker die verantwoordelijk is voor de content maar niet in staat is die content zelf bij te werken zonder hulp van iemand met technische kennis. Die situatie is absurder dan hij klinkt, en hij komt voor bij organisaties van alle groottes.

De oorzaak is vrijwel altijd hetzelfde: het CMS is gebouwd voor developers, niet voor redacteuren. De interface is technisch genoeg dat het voor een developer vanzelfsprekend is maar voor iemand zonder technische achtergrond een obstakel. Velden die onduidelijk zijn gelabeld. Een structuur die niet aansluit bij hoe de redacteur over content denkt. Handelingen die meerdere stappen vereisen die nergens worden uitgelegd. En een foutmelding als er iets misgaat die de redacteur niet begrijpt en die hem doet besluiten het systeem maar niet meer te gebruiken.

Het gevolg is een website die niet wordt bijgehouden, omdat de mensen die hem moeten bijhouden het systeem hebben opgegeven. En een website die niet wordt bijgehouden, communiceert dat de organisatie zichzelf niet bijhoudt. Dat is geen signaal dat je wil afgeven aan potentiële klanten, partners of nieuwe medewerkers die je site bezoeken voordat ze solliciteren.

Het consistentieprobleem bij meerdere contentbeheerders

Als er meerdere mensen content beheren op een website, zonder een gedeeld systeem van afspraken en structuren, is inconsistentie het onvermijdelijke resultaat. Niet omdat die mensen slordig zijn. Maar omdat ze allemaal andere gewoontes hebben, andere stijlkeuzes maken en andere interpretaties hebben van wat de website moet communiceren.

De ene medewerker schrijft productnamen met een hoofdletter, de andere niet. De ene schrijft in de eerste persoon meervoud, de andere in de derde persoon enkelvoud. De ene voegt altijd een call to action toe aan het eind van een artikel, de andere vergeet het consequent. De ene uploadt afbeeldingen op de juiste afmeting, de andere in welk formaat dan ook beschikbaar was.

Die inconsistentie is nauwelijks zichtbaar voor de individuele bijdrager. Maar voor de bezoeker die meerdere pagina’s van de site bekijkt, voelt het rommelig aan. Niet bewust rommelig. Maar onprofessioneel genoeg om het vertrouwen net iets te verlagen. En in de professionele dienstverlening, waar de website een directe weerspiegeling is van hoe de organisatie te werk gaat, is net iets minder vertrouwen genoeg om een potentiële klant te laten doorklikken naar de concurrent.

De oplossing is geen stijlgids die niemand leest. De oplossing is een CMS dat consistentie afdwingt via de structuur, niet via de goede wil van individuele medewerkers. Vaste velden met duidelijke labels. Afbeeldingsvelden die alleen de juiste afmeting accepteren. Tekstblokken met een maximale lengte. Een publicatieflow waarbij content wordt goedgekeurd voordat het live gaat. Dat zijn systeemoplossingen voor een systeemprobleem.

Wat een goed CMS doet dat een slecht CMS niet doet

Een goed CMS is onzichtbaar voor de bezoeker maar onmisbaar voor het team. Het stelt mensen in staat te doen wat ze moeten doen, content beheren, bijwerken, publiceren, zonder dat ze technische kennis nodig hebben, zonder dat ze afhankelijk zijn van een developer voor routinetaken en zonder dat ze het systeem kunnen gebruiken op een manier die de website kapot maakt.

Dat vraagt een CMS dat is ontworpen vanuit de gebruiker die de content beheert, niet vanuit de developer die het systeem bouwt. Die twee perspectieven zijn fundamenteel anders. Een developer denkt in databastabelstructuren en veldtypes. Een redacteur denkt in verhalen en publicatieritmes. Een goed CMS vertaalt het eerste naar het tweede, zodat de redacteur kan werken vanuit zijn eigen perspectief zonder te hoeven begrijpen hoe het systeem daaronder is opgebouwd.

Concreet betekent dat: veldnamen die de redacteur begrijpt. Een interface die aanvoelt als een teksteditor, niet als een databasebeheerder. Een duidelijk onderscheid tussen wat gepubliceerd is en wat nog een concept is. Een eenvoudige manier om afbeeldingen te uploaden en te vervangen. En een structuur die ervoor zorgt dat de redacteur niet per ongeluk iets kan kapotmaken dat hij niet had mogen aanraken.

Gestructureerde content: de kracht van collecties

Het meest krachtige concept in een goed CMS voor organisaties met grote hoeveelheden content is de collectie. Een collectie is een database van gelijksoortige items met een vaste structuur. Blogartikelen, vacatures, producten, cases, teamleden, evenementen. Elk item in de collectie heeft dezelfde velden, dezelfde structuur, dezelfde publicatieflow.

Dat heeft twee voordelen die op het eerste gezicht misschien niet voor de hand liggen. Het eerste is consistentie: als elk blogartikel dezelfde structuur heeft, dezelfde verplichte velden en dezelfde publicatiechecks, is het onmogelijk om een artikel te publiceren dat de structuur doorbreekt. De consistentie is ingebakken in het systeem, niet afhankelijk van de discipline van de redacteur.

Het tweede voordeel is schaalbaarheid. Als je vijf blogartikelen hebt, kun je ze handmatig beheren. Als je tweehonderd blogartikelen hebt, heb je een systeem nodig dat ze ordent, doorzoekbaar maakt, filtert op categorie en tag, en ervoor zorgt dat gerelateerde artikelen automatisch worden getoond bij elk artikel. Een collectie maakt dat mogelijk. Een handmatig beheerde pagina niet.

Voor organisaties die serieus zijn over contentmarketing, die maandelijks nieuwe artikelen publiceren, die een groeiende bibliotheek van cases bouwen, die hun eventkalender bijhouden via de website, is een collectiestructuur geen luxe maar een basisvereiste. Zonder die structuur groeit de website in volume maar daalt hij in kwaliteit. Met die structuur groeit hij in beide.

Contentgovernance: wie beheert wat

Contentgovernance is het systeem van afspraken en toegangsrechten dat bepaalt wie welke content mag aanpassen, wie content moet goedkeuren voor publicatie en wie verantwoordelijk is voor de kwaliteit van de content als geheel. Het is een onderwerp dat bij de meeste organisaties pas aandacht krijgt als het te laat is, als er iets mis is gegaan dat nooit had mogen live gaan.

Een goed contentgovernance-systeem begint bij de vraag wie er toegang nodig heeft tot welke onderdelen van de website. De HR-manager heeft toegang nodig tot de vacaturepagina’s maar niet tot de productpagina’s. De marketingmedewerker heeft toegang nodig tot de blogsectie maar niet tot de technische specificaties van het assortiment. De directeur wil op de over-pagina de teamomschrijving kunnen aanpassen maar hoeft de eventkalender niet te kunnen wijzigen.

Een CMS dat die rolverdeling ondersteunt, geeft elke beheerder toegang tot precies wat hij nodig heeft. Niet meer en niet minder. Dat vermindert het risico op onbedoelde wijzigingen, maakt het makkelijker om verantwoordelijkheid toe te wijzen voor de kwaliteit van specifieke secties, en zorgt ervoor dat de developer die het systeem bouwt niet ook degene hoeft te zijn die elke aanvraag voor een kleine wijziging verwerkt.

In de praktijk is Webflow op dit moment beperkt in zijn rol-en-rechtenbeheer voor grotere teams. Het platform biedt basisrollen voor editors en admins maar geen fijnmazige toegangscontrole per collectie. Dat is een eerlijk punt om te maken. Voor organisaties waarbij meerdere tientallen medewerkers in het CMS werken, vraagt dat aanvullende afspraken en werkprocedures. Voor teams van twee tot tien beheerders is de basisstructuur van Webflow voldoende.

Workflows bouwen rondom content

Een workflow is de weg die een stuk content aflegt van idee tot publicatie. In een organisatie zonder expliciete contentworkflow loopt die weg door de inbox van de meest beschikbare persoon, via een WhatsApp-bericht aan de developer en eindigt hij op een willekeurig moment als er tijd voor is. Dat is geen workflow. Dat is hopen dat het goed komt.

Een expliciete contentworkflow beschrijft de stappen, de verantwoordelijkheden en de tijdlijn voor elk type content. Een vacature: HR schrijft de tekst, manager keurt goed, HR publiceert zelfstandig. Een blogartikel: marketingmedewerker schrijft, content manager reviewed op toon en consistentie, director keurt goed voor publicatie, marketingmedewerker publiceert op de geplande datum. Een productupdate: productmanager initieert, copywriter herschrijft, marketing leidt publicatie op een gekozen moment.

Die workflows zijn geen CMS-functies, ze zijn organisatorische afspraken. Maar een goed CMS maakt ze makkelijker te handhaven. Een conceptstatus die duidelijk aangeeft dat een item nog niet klaar is voor publicatie. Een eenvoudige manier om een item ter review te delen zonder het te publiceren. En een publicatiedatum die gepland kan worden, zodat content op het juiste moment live gaat zonder dat iemand op dat moment achter een laptop hoeft te zitten.

Hoe Webflow dit oplost voor organisaties met volume

Webflow is niet het enige antwoord op het contentbeheervraagstuk voor grotere organisaties, maar het is voor veel situaties een sterk antwoord. De redenen zijn specifiek en de moeite waard om te benoemen.

De collectie-structuur van Webflow is krachtig en flexibel. Je definieert de velden per collectie, je bepaalt welke verplicht zijn en welke optioneel, en je kunt per veld bepalen welk type content er in mag. Tekst, datum, afbeelding, link, switch, getal, de combinaties zijn zo goed als onbeperkt. Dat betekent dat de structuur van de content volledig is afgestemd op wat de organisatie nodig heeft, niet op een template die een platform heeft bedacht.

De editor-interface van Webflow is toegankelijk voor niet-technische gebruikers. Redacteuren werken in een overzichtelijk dashboard dat aanvoelt als een teksteditor, niet als een databasesysteem. Ze kunnen items toevoegen, bewerken en archiveren zonder te hoeven begrijpen hoe de onderliggende structuur werkt. De drempel om te beginnen is laag. De training na de oplevering duurt doorgaans een uur, niet een dag.

De technische basis van Webflow is schaalbaar. De hosting via een wereldwijd content delivery network zorgt ervoor dat de site snel blijft ook als de hoeveelheid content groeit. Er zijn geen server-configuraties die bijgesteld moeten worden als het verkeer stijgt. En de code die Webflow genereert is schoon en consistent, ongeacht hoeveel items er aan een collectie worden toegevoegd.

Webflow heeft ook native ondersteuning voor meertalige sites. Voor organisaties die in meerdere talen communiceren, is dat een directe tijdsbesparing: dezelfde collectiestructuur, meerdere taalversies, beheerd vanuit één CMS.

De migratie van een rommelig systeem naar een schoon systeem

De meeste organisaties die met dit probleem worstelen, hebben al een website. Ze hoeven niet van nul te beginnen, ze moeten migreren. En migratie is het woord dat bij veel managers een lichte paniek oproept, niet ongegrond.

Een migratie van een rommelig contentbeheersysteem naar een goed gestructureerd Webflow-systeem vraagt een aantal dingen. Ten eerste: een audit van de bestaande content. Wat is er? Wat is actueel? Wat mag worden gearchiveerd? En wat moet worden herschreven voordat het meegenomen wordt naar het nieuwe systeem? Die audit is tijdsintensief maar onmisbaar, het heeft geen zin een rommelig systeem netjes te kopiëren naar een nieuw platform.

Ten tweede vraagt een migratie een heldere collectiestructuur voor het nieuwe systeem. Welke contenttypen zijn er? Welke velden heeft elk type nodig? Hoe worden ze gecategoriseerd en gefilterd? Die structuur bepalen voordat er iets wordt gebouwd, is het verschil tussen een migratie die één keer goed wordt gedaan en een migratie die binnen twee jaar opnieuw nodig is.

Ten derde vraagt een migratie een realistische tijdlijn. Een website met tweehonderd pagina’s migreer je niet in een weekend. Maar je hoeft ook niet alles tegelijk te migreren. Een gefaseerde aanpak, kritieke pagina’s eerst en de lange staart daarna, maakt het project beheersbaar zonder dat de organisatie maandenlang met een half-gemigreerde website werkt.

De SEO-implicaties van een migratie verdienen aparte aandacht. Elke URL die verandert, krijgt een 301-redirect. Geen uitzonderingen. De linkwaarde die is opgebouwd op de oude URL blijft dan behouden. Een migratie die dit niet serieus neemt, kan maanden van organisch verkeer kosten.

Wat dit vraagt van een manager

Een goed contentbeheersysteem lost een technisch probleem op, maar het vraagt een organisatorische beslissing. De manager die dit vraagstuk aanpakt, moet bereid zijn drie dingen te doen die buiten zijn comfort zone kunnen liggen.

Ten eerste: een eerlijk oordeel vellen over het huidige systeem. Werkt het, of werkt het niet? Als het team structureel afhankelijk is van een developer voor routinetaken, als redacteuren het systeem hebben opgegeven, als de website niet wordt bijgehouden omdat het te ingewikkeld is, dan werkt het niet. En dan is het goedkoper om dat nu te erkennen dan over twee jaar.

Ten tweede: de contentstructuur voor de toekomst expliciet bepalen, niet organisch laten groeien. Welke contenttypen zijn er? Wie beheert ze? Wat zijn de afspraken over toon, stijl en publicatieflow? Die afspraken maken voordat het nieuwe systeem wordt gebouwd, niet erna.

Ten derde: de overstap serieus plannen. Een migratie is een project. Het vraagt tijd van het team, het vraagt een duidelijke verantwoordelijke en het vraagt een partner die het technisch kan uitvoeren op een manier die de organisatie daarna echt verder helpt.

Een website die voor een team van vijftien mensen werkt als een beheersbaar en betrouwbaar systeem, is een competitief voordeel. Niet omdat de technologie indrukwekkend is, maar omdat de organisatie erdoor snel kan handelen en consistent kan communiceren. Dat is wat een goed CMS voor een manager oplevert.

Ben je zelf interim manager of zelfstandig consultant en vraag je je af hoe een goed ingerichte website direct bijdraagt aan het binnenhalen van opdrachten, zonder bureau als tussenpersoon? Lees dan Webflow website voor interim managers. Over persoonlijk merk, thought leadership en hoe je direct in beeld bent bij opdrachtgevers voordat zij een bureau bellen.