Lancering is een overdracht: de klantklare checklist voor bureaus

Samenvatting

Het meeste lanceeradvies behandelt een website als een eenmalige gebeurtenis. Voor een bureau is elke lancering een overdracht, en herhaalbaarheid is belangrijker dan een perfecte lanceringsdag. Dit artikel geeft je een checklist vóór de overdracht die is gebouwd voor het beheren van meerdere klantprojecten. Het behandelt het vaststellen van een harde overdrachtsdatum, het vroeg vastleggen van content, het testen vanuit het perspectief van de klant, het afstemmen van controles op het type site, en het uitvoeren van beveiligings-, SEO- en runbookpoorten. De laatste stap is een follow-up na 48 uur die de geleerde lessen terugvoert naar het volgende project. Gebruik dit als een levende checklist, niet als een copy-paste-lijst.

Het meeste lanceeradvies is geschreven voor één website, en daarom faalt het binnen een bureau. Het gaat ervan uit dat je onbeperkt de tijd hebt om elke pagina te testen. Die heb je niet. Je hebt meerdere projecten in de lucht, een klant die twee keer het telefoonnummer heeft gewijzigd, en een stakeholder die blijft mailen over één klein ding. Het advies dat werkt, behandelt lancering als een overdracht, niet als een evenement. Je echte product is een herhaalbaar proces dat een website oplevert waar de klant in kan leven zonder jou in paniek te bellen. Deze checklist is dat proces, gebouwd voor bureaus die dezelfde kwaliteitspoort moeten uitvoeren voor verschillende klanten, budgetten en sitetypen. Gebruik het als een ruggengraat, niet als een one-size-fits-all-lijst om te kopiëren.

Schrijf eerst de overdrachtsdatum

Zet de overdrachtsdatum op de kalender voordat je een template kiest. Noem het klantklaar in plaats van lancering. Werk dan achteruit: contentdeadline, designreview, testvenster en een echte buffer omdat de klant zeker minstens twee dagen uitloopt. Schrijf de datum waar iedereen hem kan zien.

Als er geen datum is, heeft scopecreep geen anker. Wanneer een klant om nog een pagina vraagt, kun je zeggen dat dit de overdrachtsdatum verschuift. Als de datum al bestaat, is de afweging zichtbaar; als die niet bestaat, is elk klein verzoek gratis en is elke deadline fictie. Een bureau dat geen overdrachtsdatum kan noemen, kan zijn marges niet beschermen. Wanneer je start met een vage briefing, houdt een herhaalbaar bureauproces dit gesprek bij elk project hetzelfde.

Leg de content vast die niet geïmproviseerd kan worden

Content is waar clientsites uit elkaar vallen, niet in code. Een ontwikkelaar kan een pagina bouwen; hij kan niet het echte adres, de prijzen of de teamprofielen van de klant verzinnen. Stel een harde contentdeadline vóór de designgoedkeuring en maak deze net zo stevig als de overdrachtsdatum.

Gebruik bij elk project één standaard intakeformulier. Vraag naar telefoon, e-mail, fysiek adres, openingstijden en de drie diensten die de klant wil verkopen. De ene klant geeft je een telefoonnummer dat doorverbindt naar een faxapparaat; een ander overhandigt je een logo dat is opgeslagen als een Word-document. Die dingen tijdens de contentverzameling opmerken is goedkoper dan ze opmerken in de footer van een live site.

Als één onderdeel ontbreekt op de deadline, publiceer dan met een duidelijk gemarkeerde placeholder in plaats van het project stil te leggen. Een placeholder met een deadline is beter dan een vastgelopen build. De veelgemaakte fout is om content te behandelen alsof het later kan worden toegevoegd, en zo lanceer je een site met de verkeerde kaart of een dienst die de klant zes maanden geleden al niet meer aanbood. Planning en informatie-architectuur bestaan om deze beslissingen vóór de build af te dwingen.

Test zoals de klant op een slechte dag

Je hebt weken naar de site gestaard, dus je ziet wat je verwacht. De klant ziet wat er daadwerkelijk op het scherm staat. Open de site in een incognitovenster met een nieuwe sessie en doe een ronde met frisse ogen.

Klik op elke link die je ziet, niet alleen op de links die je je herinnert. Verzend elk formulier en test de faalstatussen, niet alleen het succespad. Laad de site op een telefoon, op een trage verbinding en met het menu geopend. Controleer of het telefoonnummer in de header overeenkomt met dat op de contactpagina.

Hier worden kleine vertragingen verhalen. Een heroafbeelding die langzaam laadt, een knop die nergens heen leidt, een sticky header die het telefoonnummer op mobiel bedekt—elk van deze bepaalt de eerste indruk van de klant. Je hebt geen honderd controles nodig; je hebt de paar nodig die onmogelijk te verklaren zouden zijn. Een typfout in een blogpost is te herstellen; een kapotte checkout niet. Als je bij elke klant dezelfde test uitvoert, besteed je de eerste week na de lancering niet meer aan het beantwoorden van e-mails over knop-werkt-niet.

Stem de poort af op de site

Voer bij elk project een scopingronde uit voordat je een checklist gebruikt. Een brochurewebsite van vier pagina's en een winkelcatalogus zijn niet hetzelfde project. Dezelfde controles op beide toepassen is over-engineering of onder-testen. Bepaal vóór je de checklist gebruikt welke controles voor deze klant relevant zijn.

Sitetype	Niet-onderhandelbare controles
Brochuresite	Klantperspectieftest, contactgegevens, SSL, basis-SEO
Landingspagina	Laadtijd, formulierinzending, bedankpagina, analytics
E-commerce	Afrekenpad, betalingstest, productafbeeldingen, back-ups

Houd de gemeenschappelijke poort—overdrachtsdatum, beveiliging, runbook, follow-up—en voeg de controles toe die deze specifieke klant beschermen. Sla je de scopingstap over, dan besteed je je vrijdag aan het testen van een dienstenpagina terwijl de echte zorg van de klant een checkout is die niet werkt. Of je lanceert een e-commercesite zonder het betaalproces te testen, en de klant komt er pas achter wanneer de bestelling van een klant verdwijnt.

Bouw de beveiligingspoort één keer, voer hem elke keer uit

Beveiliging is waar bureaus afdwalen. Je doet een volledige audit voor de e-commerceklant en slaat de brochuresite over omdat die geen gegevens verzamelt. Dat is de verkeerde instinct. De websitebeveiligingsrichtlijn van UpGuard past dezelfde praktijken toe op elke site: houd het platform up-to-date, dwing sterke authenticatie af, beperk gebruikersrechten, maak regelmatig back-ups en serveer alles via SSL/TLS. Een brochuresite kan nog steeds worden gecompromitteerd; het domein van een klant kan nog steeds worden gebruikt om spam te verzenden.

Bouw één gedeelde beveiligingschecklist en voer deze bij elk project uit. Multi-factorauthenticatie ingeschakeld voor elke login. Software en plugins bijgewerkt. Een back-up die daadwerkelijk is getest, niet alleen gepland. SSL/TLS-certificaat geïnstalleerd en live. Gebruikersrechten beperkt tot wat elke persoon nodig heeft.

Maak van beveiliging een ja/nee-poort. Als een antwoord niet "ja" is, is de site niet klantklaar. Voer de poort in staging uit vóór de lanceerweek, omdat certificaatfouten op de lanceringsavond noodgevallen zijn die je niet kunt factureren. Houd de lijst klein genoeg zodat elk item iets betekent. Als een item altijd slaagt, automatiseer het dan of neem het op in je buildtooling. De kosten van het overslaan zijn niet abstract; het is het middernachtelijke bericht van een klant wiens site is beklad.

Maak van SEO een controle, geen hoop

Hier is een lancering die je hebt gezien: de site gaat live, het design ziet er strak uit, en een maand later vraagt de klant waarom ze niet op Google verschijnen. SEO op een kleine site voelt als een toekomstig probleem, dus het wordt overgeslagen. De beginners-SEO-gids van het Digital Marketing Institute behandelt technische opzet als onderdeel van de basis, niet als marketing-onzin: HTTPS, een XML-sitemap en een robots.txt-bestand dat zoekmachines binnenlaat.

Voeg een SEO-sectie toe aan je overdrachtschecklist en maak deze concreet. Bevestig een titeltag en metabeschrijving voor elke belangrijke pagina. Zorg ervoor dat elke pagina ten minste één stuk echte tekstinhoud heeft, niet alleen afbeeldingen. Genereer een XML-sitemap en dien deze in. Controleer of robots.txt de pagina's die je geïndexeerd wilt hebben niet blokkeert.

Niets hiervan is duur. Het is allemaal saai, en daarom wordt het overgeslagen. De kosten zijn een paar weken onzichtbaar, en dan krijg je het telefoontje: waarom staat mijn bedrijf niet op Google? Je kunt dat niet beantwoorden met een overdrachtscontrole; je kunt het alleen beantwoorden met bewijs dat de basis op zijn plaats was vóór de site live ging. Voor de volledige opzet kun je een no-code website lanceren die vanaf dag één scoort. Maak op zijn minst van de SEO-poort een ja/nee-lijst, zodat "we doen SEO later" niet in het project kan sluipen.

Overhandig de sleutels met een runbook

De overdracht is niet compleet wanneer de site live gaat. Het is compleet wanneer de klant kan inloggen zonder jou te bellen. Een link en een wachtwoord is geen overdracht; het is een eerste huiswerkopdracht. De klant zal de instellingenpagina vinden, experimenteren, en iets breken of jou bellen met een vraag die je in een eenpagina-document had kunnen beantwoorden.

Schrijf een runbook. Hoe je inlogt en de homepage-tekst wijzigt. Hoe je een afbeelding vervangt. Waar het domein en de hosting leven. Wanneer het domein verlengt en wie ervoor verantwoordelijk is. Het ICANN-domeinregistratieproces vereist werkende contactgegevens die aan de eigenaar zijn gekoppeld. Als de klant het domein bezit, moeten ze weten waar het account zich bevindt en wat er gebeurt als het verloopt. Zet de verlengingsdatum in het runbook; je wilt niet dat het eerste telefoontje na de lancering is: "onze website is weg omdat niemand het domein heeft verlengd."

Het runbook mag één pagina zijn. Het hoeft geen handleiding te zijn. Maar het moet bestaan, en de klant moet het openen terwijl jij nog aan de telefoon bent.

Volg binnen 48 uur op

Een klant wordt een week stil na de lancering. Je neemt aan dat ze blij zijn. Dan komt de factuurmail binnen en realiseer je je dat ze zes dagen niet wisten hoe ze hun eigen prijzen moesten bijwerken. De nuttigste test vindt plaats na de overdracht, niet ervóór.

Achtenveertig uur nadat de site live is gegaan, stuur je een kort bericht. Stel één specifieke vraag, niet "gaat alles goed?" Specifieke vragen leveren echte antwoorden op. Heb je geprobeerd in te loggen? Komt het contactformulier in je inbox terecht? Klopt het adres in de footer? Log wat de klant rapporteert en voeg het toe aan de checklist van het volgende project.

Dit is het moment waarop je vangt wat je niet had kunnen vangen: het echte telefoonnummer van de klant, hun daadwerkelijke productafbeeldingen, de integratie die alleen met hun data werkt. Elke keer dat een klant een hiaat blootlegt, voeg je het toe aan de volgende overdrachtspoort. Zo blijft de checklist levend in plaats van een document dat niemand leest. Als je op zoek bent naar het grotere systeem, dan begint het volwassenheidsmodel voor onderhoud van klantsites waar deze follow-up eindigt.

Een poort, geen trofee

Het doel is niet om de meest grondige checklist van de branche te hebben. Het is om een poort te hebben die de problemen opvangt die je daadwerkelijk ziet bij je klanten. Dat betekent snoeien. Als een controle in je laatste paar lanceringen geen enkel probleem heeft opgeleverd, heb je hem geautomatiseerd of is het ruis. Een checklist vol items die altijd slagen, geeft je een vals gevoel van voltooiing. De controles die ertoe doen, zijn de controles die af en toe falen, want die voorkomen de gênante telefoontjes.

Voeg geen controles toe om je procesrijk te voelen. Voeg ze alleen toe als ze hun plek verdienen. De beste lanceerchecklist voor een bureau is korter dan je denkt: overdrachtsdatum ingesteld, content vastgelegd, klantperspectieftest geslaagd, beveiligings- en SEO-poorten groen, runbook overhandigd, follow-up na 48 uur gepland. Wanneer die poort bestaat, wordt lanceren geen moment van angst maar een formaliteit. Dat is het verschil tussen een bureau dat websites bouwt en een bureau dat ze oplevert.