Het korte antwoord: maak een beslisregister, geen verlanglijst
Een website briefing maken begint met besluiten die een leverancier nodig heeft om dezelfde opdracht te begrijpen. Leg per onderwerp vast wat al besloten is, wat nog onderzocht moet worden, wie daarover beslist en welk bewijs later voldoende is. Wie een website laat maken, hoeft het ontwerp of de techniek niet zelf voor te schrijven. De briefing moet wel voorkomen dat drie bureaus drie verschillende problemen begroten.
Gebruik hiervoor zes vaste velden per onderdeel: besluit, reden, status, eigenaar, aanlevermoment en acceptatiebewijs. Voeg een zevende veld toe voor de open vraag die de leverancier moet beantwoorden. “Nog te bepalen” is daarmee toegestaan, maar alleen wanneer zichtbaar is wie het besluit neemt en vóór welke fase dat nodig is. Dat is eerlijker dan een schijnexacte scope en bruikbaarder dan losse notulen na een intake.
Begin bij bedrijfsdoel, doelgroep en gewenste actie
Schrijf eerst waarom de website moet veranderen. Benoem het bedrijfsprobleem, de belangrijkste doelgroep en de actie die een geschikte bezoeker na een pagina moet kunnen nemen. “Professioneler overkomen” is te breed. “Technische inkopers moeten per dienst bewijs en toepassingsgrenzen kunnen beoordelen en daarna een inhoudelijke aanvraag doen” geeft richting aan structuur, inhoud en contactroute zonder een conversiegarantie te beloven.
Scheid primaire en secundaire doelgroepen. Een beslisser kan behoefte hebben aan risico, investering en aanpak, terwijl een gebruiker vooral functies, werkwijze en ondersteuning wil begrijpen. Leg per doelgroep vast welke vraag de website oplost, welk bewijs geloofwaardig is en welke vervolgstap past. Vermijd fictieve persona-details die niemand heeft onderzocht; werk liever met echte rollen, bekende vragen uit gesprekken en expliciete onzekerheden.
Maak ook duidelijk wat buiten het eerste project valt. Een klantportaal, webshop, meertaligheid of volledige contentbibliotheek kan later waardevol zijn, maar verandert nu de architectuur, rechten, contentproductie en testlast. Zet zulke wensen in een latere-lijst met reden en afhankelijkheid. Zo kan een leverancier rekening houden met uitbreidbaarheid zonder alles direct in de eerste offerte te stoppen.
Maak een pagina- en contentkaart met eigenaar en bewijs
Vertaal de bezoekersvragen naar paginarollen: bijvoorbeeld dienst, vergelijking, bewijs, uitleg, over ons en contact. De gids over benodigde MKB-websitepagina's helpt bij die inventaris, maar kopieer geen standaardmenu zonder per pagina een taak te benoemen. Leg voor iedere route vast wie hem nodig heeft, welke hoofdvraag hij beantwoordt, welke actie volgt en welke andere pagina's ervoor of erna liggen.
Maak daarna per pagina een aanleverregel. Noteer de inhoudseigenaar, broninformatie, beschikbare tekst, ontbrekend bewijs, beelden, rechten, gewenste actiedatum en degene die inhoudelijk goedkeurt. “Teksten door opdrachtgever” is geen werkverdeling. Bepaal of het bureau interviewt, schrijft, redigeert of alleen plaatst en wie controleert of prijzen, teamgegevens, cases en andere feiten werkelijk actueel en publiek bruikbaar zijn.
Bewijs verdient een eigen kolom. Gebruik alleen verifieerbare voorbeelden, procesuitleg, teaminformatie en klantmateriaal waarvoor toestemming bestaat. Geen gefabriceerde resultaten, reviews, keurmerken of partnerlogo's. Kan een sterke claim nog niet worden onderbouwd, formuleer dan de werkwijze en acceptatiegrens in plaats van een uitkomst te beloven. Dat maakt de briefing misschien minder spectaculair, maar de uiteindelijke pagina aantoonbaar betrouwbaarder.
Beschrijf functies als gebruikersroute met foutpad
Schrijf een functie niet op als zelfstandig naamwoord. “Contactformulier”, “calculator” of “CRM-koppeling” zegt onvoldoende. Beschrijf wie de route start, welke gegevens nodig zijn, welke validatie geldt, waar de uitkomst terechtkomt, wie hem opvolgt en wat de bezoeker ziet wanneer een stap mislukt. Neem ook mobiel gebruik, toetsenbordbediening, foutmeldingen, ontvangstbevestiging en een bruikbaar alternatief kanaal mee.
Classificeer iedere functie als noodzakelijk, gewenst of later. Noodzakelijk betekent dat de primaire bezoekersroute zonder deze functie niet bruikbaar eindigt. Gewenst heeft duidelijke waarde, maar kan veilig handmatig of in een volgende fase. Later betekent dat vraag, brondata of eigenaarschap nog niet bewezen is. Laat de leverancier per noodzakelijk onderdeel de aannames, technische afhankelijkheden en testvorm terugschrijven.
Voor koppelingen hoort een klein datacontract in de briefing: bron, bestemming, velden, leidend systeem, rechten, duplicatecontrole, foutmelding en herstelverantwoordelijke. Een logo van een CRM of nieuwsbriefdienst is geen scope. Geef nooit wachtwoorden of geheime sleutels in de briefing. Benoem alleen welke toegang later via een veilige, afgesproken route nodig is en wie die gebruikersstap uitvoert.
Leg SEO, meten, privacy en toegankelijkheid als oplevering vast
“SEO-vriendelijk” is niet controleerbaar. Benoem welke pagina een unieke taak krijgt, wie titels en descriptions maakt, hoe headings en contextlinks worden ingericht en welke partij canonicals, redirects, sitemap, robots en structured data controleert. Leg bij een bestaande website vast welke URL's en bewezen inhoud behouden, verplaatst of samengevoegd worden. Rankings of indexatie kun je niet garanderen; een consistente indexeerbare basis en livecontrole wel.
Verandert de URL-structuur, voeg dan een migratiekaart toe met oude URL, nieuwe bestemming, redirect, canonical, interne ingangen, sitemapstatus en livebewijs. De gids over website migreren werkt die technische overdracht verder uit. Laat dit vóór de bouw begroten: achteraf redirects reconstrueren uit geheugen is kwetsbaar en maakt onduidelijk wie de inhoudelijke bestemming heeft goedgekeurd.
Maak voor meten een gebeurteniskaart. Noteer per belangrijke actie wat de bezoeker doet, wanneer de gebeurtenis pas geslaagd is, waar die wordt geregistreerd en wie controleert of de ontvangst werkelijk plaatsvond. Een klik op verzenden is nog geen ontvangen aanvraag. Leg daarnaast vast wie keuzes rond toestemming, bewaartermijnen, formulierteksten en toegankelijkheid beoordeelt. De briefing is praktische projectspecificatie en geen vervanging voor juridisch advies.
Maak stijlrichting bruikbaar zonder het ontwerp al dicht te zetten
Geef voor uitstraling geen lijst met losse bijvoeglijke naamwoorden. “Modern, rustig en professioneel” kan bijna alles betekenen. Verzamel enkele concrete voorbeelden en benoem per voorbeeld welk principe helpt: informatiedichtheid, typografie, fotografie, ritme, bewijsplaatsing of mobiele navigatie. Benoem ook wat niet past en waarom. Laat de ontwerper vervolgens een richting voorstellen die de gekozen doelgroep en taak ondersteunt.
Lever beschikbare merkbestanden met bron, formaat en gebruiksrecht aan. Noteer wie logo, kleur, lettertype, fotografie en illustraties goedkeurt. Beslis of echt project- of teambeeld beschikbaar komt en wanneer. Placeholderbeeld mag een ontwerp verkennen, maar hoort niet ongemerkt als definitieve publieke claim te eindigen. Controleer alternatieve tekst, uitsnede op mobiel, bestandsgrootte en hoe belangrijk beeld in delen of previews verschijnt.
Zet planning op besluiten en aanleveringen, niet alleen op bouwweken
Een planning is pas bruikbaar wanneer afhankelijkheden zichtbaar zijn. Noteer vóór ontwerp wie pagina's en inhoud goedkeurt; vóór bouw welke functies en koppelingen zijn besloten; vóór vullen welke teksten en beelden definitief zijn; vóór livegang wie accepteert. Geef iedere aanlevering één eigenaar en één datum. Een groepsnaam als “marketing” is geen eigenaar wanneer niemand het laatste woord heeft.
Plan vaste beslismomenten met duidelijke invoer en uitkomst. Een review van een wireframe beoordeelt structuur en prioriteit, niet kleurdetails. Een ontwerpreview beoordeelt visuele hiërarchie en gedrag op relevante schermen. Een prototypecontrole beoordeelt routes en foutgedrag. Nieuwe wensen gaan terug naar het register met impact op scope, prijs en planning; ze worden niet stilzwijgend als feedback in dezelfde ronde opgenomen.
Leg ook de interne tijd vast. Interviews, bronmateriaal verzamelen, foto's organiseren, inhoud controleren, testscenario's uitvoeren en collega's trainen vragen werk van het MKB-team. Een leverancier kan die inzet verminderen of begeleiden, maar niet doen alsof beslissingen zonder eigenaar ontstaan. De planning wordt eerlijker wanneer zowel bureauwerk als klantwerk op dezelfde afhankelijkhedenkaart staat.
Definieer acceptatie en beheer vóór je offertes vergelijkt
Schrijf per primaire route een acceptatiescenario met invoer, stappen, verwachte uitkomst, foutvariant en menselijke beslisser. Controleer minimaal navigatie, inhoud, mobiel gedrag, toetsenbordroute, formulieren, ontvangst, metadata, redirects, meting, toestemming en toegang tot beheer. “Werkt volgens ontwerp” is te zwak wanneer niet duidelijk is welk ontwerp, welke data en welk productiebewijs worden bedoeld.
Bepaal wat bij oplevering wordt overgedragen: beheeraccounts, domein- en hostingtoegang, analytics, bronbestanden, content, documentatie, back-up- en herstelroute en waar relevant exportmogelijkheden. Leg daarnaast vast wie na livegang updates, monitoring, kleine wijzigingen en incidenten behandelt. De precieze juridische rechten horen in de overeenkomst; de briefing moet wel voorkomen dat noodzakelijk beheer pas na de keuze wordt ontdekt.
Stuur pas daarna dezelfde briefing naar leveranciers en vergelijk voorstellen op dezelfde beslissingen, open vragen en bewijslast. De zevenveldenmatrix voor websiteoffertes zet doel en routes, scope, content, techniek, meten, acceptatie en overdracht op één gelijke basis. Een leverancier mag een betere route voorstellen, maar moet dan expliciet maken welk briefingbesluit verandert en wat dat doet met prijs, risico en planning.
Kopieer deze minimale briefingstructuur
Projectkader — probleem, doel, doelgroep, gewenste actie, eerste fase en expliciete uitsluitingen. Pagina- en contentkaart — route, bezoekersvraag, eigenaar, bron, bewijs, status en aanleverdatum. Functieregister — gebruiker, invoer, systeemactie, foutpad, menselijke eigenaar en prioriteit. Randvoorwaarden — SEO, migratie, meten, privacy, toegankelijkheid, techniek en veilige toegang.
Besluitlog — besluit, reden, datum, eigenaar en gevolgen voor scope. Planning — aanlevering, reviewdoel, beslisser en afhankelijkheid. Acceptatie — scenario, verwacht bewijs, blokkerende fout en go-no-go-eigenaar. Overdracht — accounts, bestanden, documentatie, beheer, monitoring en herstel. Zet onder ieder blok alleen vragen die een echt besluit veranderen; algemene inspiratie hoort in een aparte bijlage.
Neem deze structuur mee naar een eerste websitegesprek en markeer vooraf wat vaststaat, wat onzeker is en waar je hulp bij nodig hebt. Softora kan de primaire bezoekersroute, pagina's, functies en acceptatie samen afbakenen voordat een bouwscope wordt vastgezet. Bekijk de websitepakketten alleen als startpunt voor het gesprek: de passende aanpak volgt uit de opdracht en wordt niet door een standaardlijst gegarandeerd.
