“Een website bouwen we eerst, content vullen doen we daarna.”
Klinkt logisch, toch? Vergeet bij deze aanpak alleen niet om de contentcriteria voor een nieuw cms wel al te bespreken. Doe je dit niet, dan zet je het contentteam buitenspel bij het kiezen van een cms. Hierdoor loop je het risico dat het contentteam straks niet goed en efficiënt in het nieuwe cms kan werken, wat je tijd en geld kost.
Een tekstwijziging kost bijvoorbeeld in het ene systeem twee klikken, en in het andere een ticket bij IT en een paar dagen wachttijd.
Of een contentveld dat de redactie zelf zou moeten kunnen aanpassen, blijkt vastgezet in de codebase. Geen van beide systemen faalt op een technische toets, maar maakt wel een groot verschil in hoe snel content aangepast en gepubliceerd kan worden.
Als er een integratie niet werkt, merkt iedereen dat dezelfde dag nog. Bij een onwerkbaar cms is dat subtieler. Het is immers niet kapot, maar kan er wel voor zorgen dat content maken, publiceren en optimaliseren tijdrovend en omslachtig is.
Een omweg hier, een ticket daar, een aanpassing die drie keer langer duurt dan nodig. Dat stapelt zich op en voordat je het weet heeft het contentteam vele uren verloren aan het wachten op development. Tijd waarin ook een nieuwe campagne live had kunnen gaan. Daarnaast doet het development team op deze manier ook werk dat eigenlijk bij het contentteam hoort. Geen wenselijke situatie.
Wie dit pas ontdekt na livegang, kiest tussen twee dure routes: jarenlang werken met omslachtige workflows of een nieuw traject starten om alsnog tot een systeem te komen dat wel werkbaar is.
Maar dit is eenvoudig te voorkomen door contentcriteria toe te voegen aan je lijst met beoordelingscriteria van een nieuw cms, nog vóór de bouwfase begint.
Contentcriteria waar je aan zou moeten denken zijn:
Kan een redacteur een veld, sectie of pagina-opbouw aanpassen zonder een developer erbij te halen?
Werkt het systeem met vaste templates, of stel je zelf een pagina samen uit herbruikbare onderdelen?
Hoe snel kan een nieuwe collega aan de slag in het systeem?
Kunnen meerdere redacteuren tegelijk werken, en zit er een review- en publicatiestap in het systeem zelf?
Vind en hergebruik je bestaande content makkelijk, of begint elke pagina from scratch?
Het zijn maar een paar extra vragen tijdens het cms-selectieproces, maar ze besparen je een hoop leed.
Schuif het contentteam dus aan bij het kiezen van een cms. Dat vraagt geen nieuw proces. Het is dezelfde selectie, maar met extra expertise aan tafel en een aantal vragen die net zo hard meetellen als een securitycertificering. Door ze aan het begin van het proces te stellen voorkom je onwerkbare workflows en verlies van tijd en geld.