NL EN UA Bespreek je project

Kennisbank · Websites

Website laten maken: checklist voor een goede samenwerking

Wat moet je aanleveren, wie neemt beslissingen en hoe voorkom je vertraging? Gebruik deze checklist voor een duidelijk websiteproject.

Daniel OroszWeb developer & oprichter
Websiteplanning met checklist en ontwerpnotities

Kort antwoord

Dit moet je weten

Wat moet je aanleveren, wie neemt beslissingen en hoe voorkom je vertraging? Gebruik deze checklist voor een duidelijk websiteproject.

Gebruik de details hieronder om de juiste volgende stap te kiezen.

Kerngegevens
Onderwerpwebsite laten maken checklist
RegioKerkrade · Zuid-Limburg · Nederland & België
ActueelGecontroleerd en bijgewerkt: 12 september 2026
Volgende stapEerst afbakenen, daarna een heldere prijsrichting

Je hoeft voor een nieuwe website geen technisch document van honderd pagina’s te schrijven. Je hoeft ook niet zelf de paginastructuur te tekenen of de techniek te kiezen. Dat hoort bij mijn werk. Ik heb wel betrouwbare informatie over je bedrijf nodig. Zonder die informatie neemt zelfs een goede webdeveloper beslissingen op basis van aannames.

Deze negen punten zijn voor de meeste projecten een goede voorbereiding:

  1. Bepaal het doel van de website en de belangrijkste actie voor de bezoeker.
  2. Geef aan welke diensten of producten voorrang hebben.
  3. Beschrijf je klanten en de vragen die zij voor een aankoop stellen.
  4. Bevestig welke prijzen, voorwaarden en feiten openbaar mogen worden gemaakt.
  5. Verzamel bestaande teksten, foto’s, het logo en andere materialen.
  6. Noteer welke functies en gekoppelde systemen nodig zijn.
  7. Zoek uit wie het domein, de hosting en de huidige website beheert.
  8. Noem een budgetrange en de werkelijke gewenste lanceerdatum.
  9. Wijs een coördinator aan en bepaal wie de eindbeslissingen neemt.

Dit hoeft geen perfect ingevulde briefing te worden. Eén document, een e-mailwisseling of een gesprek kan genoeg zijn. Ik wil vooral de feiten, prioriteiten en grenzen van het project begrijpen.

Een briefing is geen examen

OROS werkt nog niet met één algemene vragenlijst die iedere klant voor het eerste contact volledig moet invullen. Ik bereid ieder project afzonderlijk voor. Ik bekijk het bedrijf, de branche en de bestaande website en bepaal welke vragen invloed kunnen hebben op mijn voorstel.

Persoonlijk verzamel ik informatie het liefst stap voor stap in een schriftelijk gesprek. Ik stuur een paar vragen, de klant controleert zo nodig de feiten of vraagt iets na bij een collega en daarna stel ik de volgende vragen. De antwoorden blijven bewaard en zijn later terug te vinden wanneer ik het voorstel en de website uitwerk. Bij een taalverschil geeft deze werkwijze beide partijen meer tijd om precies te formuleren wat zij bedoelen.

Een gesprek via video kan ook waardevol zijn. In een livegesprek komt soms sneller naar boven wat iemand nodig heeft en kan ik direct doorvragen. Een korte kennismaking maakt de samenwerking bovendien persoonlijk. De klant weet wie verantwoordelijk is voor het werk en met wie hij tijdens het project contact heeft. Zeker bij een klein bedrijf vind ik dat een goed teken.

In de praktijk werkt een combinatie vaak prettig. We verzamelen de meeste informatie schriftelijk en plannen een korte videokennismaking of een gesprek voor een lastige beslissing. Niet iedere fase hoeft via video. Wat we tijdens een gesprek besluiten, bevestigen we daarna schriftelijk, zodat er één duidelijke versie van de afspraak bestaat.

Ik zie weinig nut in dezelfde lijst met honderd vragen voor een fotograaf, een webshop en een bedrijf met een lang verkoopproces. Een klant slaat een groot deel over of geeft antwoorden waar niemand iets mee kan. Ik stel liever minder vragen die passen bij het bedrijf en de opdracht.

Na de eerste antwoorden volgen meestal een paar gerichte aanvullingen. Ik onderzoek de markt, werk een richting uit en leg onduidelijke punten opnieuw voor. Zo ontstaat stap voor stap een afgesproken opdracht met de juiste pagina’s en functies.

Wat moet er in een websitebriefing staan?

Een websitebriefing beschrijft de uitgangspunten en grenzen van het project. De briefing hoeft de oplossing niet alvast voor de specialist te ontwerpen. Weet je nog niet hoeveel pagina’s nodig zijn of welke techniek past, dan mag dat openblijven. De zakelijke context is belangrijker.

OnderdeelWat je kunt invullen
AanleidingWaarom een nieuwe website of aanpassing nodig is
DoelWelke hoofdactie de bezoeker moet uitvoeren
DoelgroepVoor wie de website is en welke vragen deze mensen hebben
AanbodPrioritaire diensten, producten, regio’s en voorwaarden
ContentWelke feiten, teksten, foto’s en bronbestanden al bestaan
FunctionaliteitFormulieren, afspraken, betalingen, talen, koppelingen en automatisering
Bestaande systemenDomein, hosting, CMS, CRM en analytics, zonder wachtwoorden in het document
OmvangWelke pagina’s nodig zijn en wat niet in de eerste versie komt
Budget en planningBudgetrange, gewenste datum en gebeurtenissen waarvan die datum afhangt
BesluitvormingCoördinator, eindbeslisser en gebruikelijke reactietijd

Voorbeeld van een websitebriefing: kopieer dit sjabloon

Kopieer de tekst hieronder naar een e-mail of document en geef korte antwoorden. Wat je nog niet weet, kan tijdens de intake worden besproken.

Bedrijf en huidige website:
Aanleiding voor de nieuwe website of aanpassing:
Belangrijkste doel van de website:
Primaire doelgroep en werkgebied:
Prioritaire diensten of producten:
Prijzen, voorwaarden en feiten die gepubliceerd mogen worden:
Beschikbare teksten, foto's en merkmateriaal:
Hulp die nodig is bij de content:
Gewenste pagina's en functies:
Domein, hosting, CMS, CRM en andere bestaande systemen:
Wat in de eerste versie moet staan:
Budgetrange:
Gewenste lanceerdatum en reden voor die datum:
Contactpersoon:
Wie de eindbeslissingen goedkeurt:
Waar alle feedback wordt verzameld:

Zet geen wachtwoorden of herstelcodes in deze briefing. Noteer alleen welke systemen bestaan en wie op een veilige manier toegang kan verlenen.

Wat moet je over het bedrijf vertellen?

Begin niet bij een favoriete kleur of een mooie voorbeeldwebsite. Eerst moet duidelijk zijn waarom iemand de pagina opent.

Welke dienst of productgroep heeft prioriteit? Aan wie wil je die verkopen? In welke plaats of regio werkt het bedrijf? Welke vragen stellen klanten voor zij contact opnemen? Waar twijfelen zij over? En wat moeten zij op de website doen: bellen, een bericht sturen, een afspraak maken, een prijs aanvragen of direct betalen?

Een webdeveloper kan concurrenten bekijken en zien hoe vergelijkbare bedrijven hun aanbod uitleggen. De interne prioriteiten blijven informatie van de klant. Een website kan bijvoorbeeld vijf soorten machines evenveel aandacht geven. Wil het bedrijf vooral één daarvan verkopen, dan kan ik dat niet uit een marktanalyse afleiden.

Hetzelfde geldt voor prijzen, garanties, werkgebieden, levertijden en andere beloftes. Ik kan helpen om ze duidelijk te formuleren. De feiten zelf moeten van het bedrijf komen.

Wat moet je aanleveren voor een website?

Verzamel eerst wat er al is: het logo en de bronbestanden, foto’s, dienstbeschrijvingen, een prijslijst, presentaties, handleidingen, beoordelingen en voorbeelden van werk. Bij een bestaande website ontvang ik graag het adres en een lijst van bekende problemen. Beschikbare statistieken kunnen laten zien welke pagina’s nu al worden bezocht.

Het materiaal hoeft nog niet klaar te zijn voor publicatie. Een ruwe tekst, een tabel met prijzen en een ongeordende map met foto’s zijn bruikbaarder dan de mededeling dat alles later komt. Ik kan dan beoordelen wat geschikt is, wat ontbreekt en wie het resterende werk doet.

Ontbreken teksten of beelden, dan hoeft het project niet stil te vallen. We spreken vooraf af wat de klant maakt en wat ik overneem. Met voldoende informatie kan ik een structuur voorstellen, teksten schrijven en een richting voor het beeld uitwerken. De klant controleert de feiten en keurt de uiteindelijke versie goed.

Controleer ook of het materiaal voor de website gebruikt mag worden. Noteer waar foto’s, partnerlogo’s, beoordelingen en andere bestanden vandaan komen. Zo voorkomen we dat onduidelijk materiaal zonder toestemming online verschijnt.

Beschrijf functies vanuit het gewenste resultaat

Je hoeft geen technische termen of productnamen te kennen. Beschrijf wat er moet gebeuren.

Na een aanvraag moeten de gegevens bijvoorbeeld in de CRM terechtkomen. Een bezoeker moet zelf een afspraak kunnen kiezen, een bestelling betalen of een voorlopige prijs berekenen. Misschien moet een medewerker later bepaalde pagina’s kunnen wijzigen.

Met zo’n beschrijving kan ik een oplossing voorstellen en gerichte vervolgvragen stellen. Voor een CRM, betaling, boekingssysteem of calculator hebben we toegangen en werkregels nodig. Eén regel als “CRM koppelen” kan in de praktijk verschillende processen betekenen.

Zet wachtwoorden en herstelcodes niet in een gewone briefing of e-mail. In het begin is het genoeg om te vermelden welke accounts bestaan, wie de eigenaar is en wie toegang kan verlenen. De overdracht van gevoelige gegevens spreken we apart af.

Wie wordt de contactpersoon voor het websiteproject?

Eén contactpersoon maakt het werk overzichtelijk als die persoon informatie heeft en beslissingen mag nemen. Alleen een naam aanwijzen is niet genoeg.

In een geanonimiseerd voorbeeld droeg een eigenaar het contact over aan een afdelingsmanager. Deze medewerker kon een deel van de vragen beantwoorden, maar kende de productprioriteiten niet en mocht belangrijke keuzes niet goedkeuren. Op concrete vragen kwam het antwoord: “Bekijk het zelf maar en kies iets.” Voor ieder voorstel was daarna alsnog toestemming van de eigenaar nodig.

De eigenaar dacht dat het project was gedelegeerd. De medewerker wachtte op de eigenaar. De webdeveloper bleef communiceren, maar kreeg niet de informatie waarop de website moest worden gebouwd.

Dan zijn er twee mogelijkheden: wachten of verdergaan op basis van aannames. Ik krijg liever eerst een bevestiging. Ook zonder die bevestiging kan ik een mooie pagina maken, maar misschien promoot die de verkeerde dienst, spreekt hij niet de juiste klant aan of staat er een belofte die het bedrijf niet wil doen.

Wanneer moet de eigenaar zelf aansluiten?

Bij een microbedrijf kan de eigenaar meestal het beste uitleggen wat het bedrijf verkoopt, wie de klanten zijn en waar het naartoe wil. Zijn of haar aanwezigheid is daarom vooral aan het begin waardevol. Daarna kan een assistent foto’s, documenten en kleine correcties verzamelen.

Een klein of middelgroot bedrijf kan een coördinator aanwijzen. Die persoon verzamelt materiaal, bundelt opmerkingen en haalt antwoorden op bij collega’s. Spreek vooraf af welke besluiten de coördinator zelf neemt en wanneer de eigenaar of een afdelingshoofd nodig is.

Ook in een grotere organisatie blijft één hoofdcontact praktisch. Marketing, sales, IT en juridische collega’s beoordelen hun eigen onderwerpen. De coördinator zorgt dat ik één definitief antwoord krijg en geen vier losse versies van de opdracht.

De eigenaar hoeft niet aan ieder gesprek deel te nemen. Hij of zij is nodig wanneer we het doel en de positionering bepalen, wanneer budget of omvang verandert en bij keuzes die het bedrijf zelf raken. Materiaal verzamelen kun je delegeren. Een beslissing kun je pas delegeren als de medewerker de informatie en bevoegdheid heeft om haar te nemen.

Goede feedback staat op één plek

Voor mijn projecten werk ik het liefst met één e-mailadres of een gedeeld document. Daar blijft de geschiedenis staan en kan ik opmerkingen voor de volgende fase terugvinden.

Wil de klant liever een berichtenapp gebruiken, maak dan één groep met alle verantwoordelijke personen. Privéberichten van meerdere medewerkers, enkele correcties in WhatsApp, andere opmerkingen per e-mail en nog een lijst in een apart systeem zorgen voor verwarring. Dan moet ik uitzoeken welke reactie de laatste was en wie die heeft goedgekeurd.

Een videogesprek kan helpen om een lastig punt te bespreken, maar moet niet de enige plaats zijn waar beslissingen worden genomen. Schrijf het resultaat daarna in het hoofdkanaal van het project. Anders probeert iedereen een week later uit het geheugen te reconstrueren wat er precies was afgesproken.

Stem tegenstrijdige opmerkingen eerst intern af. De ene medewerker vraagt om een knop groter te maken, de tweede wil hem verwijderen en een derde stuurt rechtstreeks een nieuwe tekst. Ik kan de gevolgen van ieder voorstel uitleggen, maar het interne meningsverschil niet voor het bedrijf oplossen.

Goede feedback beschrijft wat er niet werkt en wat iemand wil bereiken. “Dit blok overtuigt ons nog niet” geeft mij meer houvast dan de losse opdracht om alles twee keer zo groot te maken. Wanneer ik de reden begrijp, kan ik een passende oplossing voorstellen.

Maak ook onderscheid tussen fouten, noodzakelijke wijzigingen en persoonlijke voorkeuren. Een typefout kan direct worden hersteld. Een nieuwe dienst of extra pagina verandert de opdracht en wordt daarom apart beoordeeld op tijd en kosten.

Ook budget en lanceerdatum horen in de briefing

Een budgetrange helpt om een passend project voor te stellen. Het is geen poging om het maximale bedrag uit te geven. Zonder financiële richting kunnen we lang praten over een oplossing die buiten de mogelijkheden valt.

Een gewenste datum heeft eveneens context nodig. “Zo snel mogelijk” vertelt niet wat er gebeurt als de website een week later klaar is. Een advertentiecampagne, opening of beurs zorgt voor een concrete deadline. Dan kunnen we bepalen wat in de eerste versie moet staan en wat naar een volgende fase kan.

Een eerste gesprek of prijsaanvraag reserveert nog geen tijd in mijn agenda. De startdatum wordt bevestigd nadat opdracht, omvang en prijs zijn afgesproken, de aanbetaling is ontvangen en de noodzakelijke informatie beschikbaar is. Lees voor de gebruikelijke termijnen ook hoe lang het duurt om een website te laten maken.

De klant houdt de eindbeslissing

Ik ben bereid zelfstandig keuzes te maken als ik genoeg informatie heb. Eerst stel ik vragen. Daarna onderzoek ik de markt en presenteer ik de oplossing die volgens mij bij de opdracht past.

Zelfstandig werken betekent niet dat de klant niets hoeft te controleren. De eigenaar of bevoegde medewerker beoordeelt prijzen, diensten, beloftes, juridische informatie en de belangrijkste prioriteiten. Ook wanneer de klant niet zelf wil schrijven of beelden wil kiezen, bevestigt hij dat de uiteindelijke website het bedrijf correct weergeeft.

Voor de start helpt het om deze vijf verantwoordelijkheden vast te leggen. In een klein bedrijf kan één persoon meerdere rollen hebben.

OnderwerpWie bevestigt dit meestal?
Doel van de website en prioritaire dienstenEigenaar of commercieel verantwoordelijke
Teksten, foto’s en feitenCoördinator samen met de mensen die de informatie beheren
Budget en uitbreiding van de opdrachtEigenaar of bevoegde manager
Toegang en gekoppelde systemenIT, huidige leverancier of eigenaar van het account
Definitieve lijst met feedbackEén aangewezen coördinator

Een goede voorbereiding hoeft geen bureaucratie te worden

Ik heb geen perfect document nodig. Eerlijke antwoorden, toegang tot de mensen die het bedrijf kennen en een duidelijke manier om besluiten te nemen zijn genoeg om te beginnen.

De intake kan schriftelijk of tijdens een gesprek verlopen. Ik onderzoek de branche en help de vraag om te zetten in een concrete opdracht. Na een paar aanvullingen leggen we de omvang, materialen, rollen en goedkeuringsmomenten vast. De klant houdt de controle, zonder zelf webdesigner of projectmanager te hoeven worden.

Plan je een nieuwe website of zit een bestaand project vast tussen meerdere medewerkers en leveranciers? Beschrijf de situatie schriftelijk. Ik kijk welke informatie ontbreekt, wie bij de beslissing nodig is en welke volgende stap past. Op de pagina website laten maken vind je ook de mogelijke soorten projecten en voorwaarden.


FAQ

Wat moet ik aanleveren als ik een website laat maken?

Lever het doel, de doelgroep, prioritaire diensten of producten, bevestigde feiten en voorwaarden, bestaand tekst- en beeldmateriaal, gewenste functies en informatie over bestaande accounts aan. De materialen mogen nog ruw zijn. Stuur wachtwoorden en herstelcodes niet mee in een gewone e-mail of briefing.

Moeten alle teksten en foto’s klaar zijn voordat het project begint?

Nee. Spreek voor de start af wie het ontbrekende materiaal maakt en wanneer het nodig is. OROS kan helpen met structuur, tekst en de richting van het beeld als de klant de feiten aanlevert en de uiteindelijke versie goedkeurt.

Wie is de beste contactpersoon voor een websiteproject?

Kies iemand die het doel begrijpt, antwoorden bij collega’s kan ophalen en duidelijke bevoegdheden heeft. Blijft de eindbeslissing bij de eigenaar, bepaal dan vooraf op welke momenten zijn of haar goedkeuring nodig is.

Hoe geef je goede feedback op een webdesign?

Bundel de opmerkingen in één e-mail, document of gezamenlijke groep. Los interne tegenstrijdigheden eerst op. Leg uit wat het probleem is en wat je wilt bereiken, zodat de webdesigner een passende oplossing kan voorstellen.

Kan een webdesigner de briefing voor mij maken?

Ja. Bij OROS kan de intake via een korte briefing, een schriftelijk gesprek of een videogesprek verlopen. Daniel bekijkt vooraf het bedrijf, stelt gerichte vervolgvragen en verwerkt de antwoorden in een voorstel en afgesproken projectomvang.

Is een videogesprek verplicht voor een websiteproject?

Nee. De meeste informatie kan stap voor stap via e-mail of één chatkanaal worden verzameld. Een korte videokennismaking is nuttig om elkaar te leren kennen of een ingewikkeld onderwerp te bespreken. Andere fasen hoeven niet via video. Besluiten worden daarna schriftelijk bevestigd.

Wat moet er in een websitebriefing staan?

Neem de aanleiding, het doel, de doelgroep, het prioritaire aanbod, beschikbare content, functies, bestaande systemen, verwachte omvang, budget, gewenste datum en besluitvorming op. Je hoeft de technische oplossing nog niet zelf te bepalen.

Heb ik een websitebriefing nodig voor een offerte?

Een volledig document is niet verplicht. Voor een realistisch eerste voorstel zijn in elk geval het doel, de globale omvang, belangrijkste functies, staat van de content, budgetrange en manier van beslissen nodig. De overige informatie kan OROS schriftelijk of tijdens een gesprek verzamelen.

De auteur

Daniel Orosz

Daniel Orosz

Web developer & oprichter

Daniel bouwt websites en digitale systemen vanuit Kerkrade. Hij werkt al meer dan 16 jaar met webtechniek en vertaalt complexe keuzes naar gewone taal.

Meer over Daniel →

Passende volgende stap

Bespreek je websiteproject schriftelijk

Beschrijf je geplande of vastgelopen project en ontvang een voorstel voor een logische volgende stap.

Beschrijf je project →