Naar de inhoud
← Blog

Gidsen

Een briefing schrijven, ook als je niet technisch bent

Een goede briefing beschrijft je probleem in je eigen woorden. Welke vragen je beantwoordt, wat je mag openlaten en hoe dat er op papier uitziet.

9 november 2026 · 5 min lezen

Een briefing is de tekst die je aan een ontwikkelaar of bureau geeft om uit te leggen wat je zoekt. Je hebt er geen technische kennis voor nodig. Beschrijf je probleem en je werk, want daar weet jij meer over dan wie ook, en laat de oplossing aan de vakmensen. Een of twee pagina’s in gewone taal is genoeg.

De meeste vragen hieronder stel ik ook zelf als ik met een founder rond de tafel zit. Heb je ze al op papier, dan kan zo’n eerste gesprek meteen over de details gaan.

Wat heb je nodig, en waarom?

Vertel het in je eigen woorden, in één of twee zinnen. Schrijf er daarna bij waarom. Een tool die je team tijd moet besparen, ziet er anders uit dan een app waarmee je nieuwe klanten wil binnenhalen, ook als de functies op het eerste gezicht op elkaar lijken.

Hoe doe je het nu?

Beschrijf hoe het werk vandaag loopt, stap voor stap. Manueel? In Excel? Via mail en telefoon? Schrijf ook de uitzonderingen op en de trucjes die niemand ooit heeft opgeschreven, zoals de klant die altijd apart gefactureerd wordt. Schrijf erbij waarom je ervan af wil.

Stuur mee wat je hebt: het Excel-bestand, een schermafbeelding, een foto van het papieren formulier. Haal er wel eerst namen en andere gegevens van echte klanten uit, of vervang ze door verzonnen voorbeelden. Is het idee gevoelig, vraag dan eerst om een NDA, een overeenkomst waarin iemand belooft je informatie geheim te houden. Ik teken er met plezier een.

Welke woorden gebruik je?

Maak een kort lijstje met de woorden die in je bedrijf iets specifieks betekenen, met een zin uitleg per woord. Ook gewone woorden kunnen erop staan. Is een “klant” bij jou de winkel die bestelt of de persoon die in de winkel koopt? Dat soort verschillen komen anders pas boven als er al iets gebouwd is.

Wanneer is het een succes?

Schrijf op wat er anders moet zijn als het werkt. Dat mag eenvoudig zijn: minder telefoontjes, minder fouten in je administratie, klanten die de app gebruiken zonder dat je ze moet helpen. Noteer ook wat er weg kan en waar niet over te onderhandelen valt. Die twee lijstjes helpen later om te kiezen wat in een eerste versie hoort.

Wie gebruikt het, en hoe?

Noem de mensen die het zullen gebruiken: je klanten, je team, een chauffeur onderweg, jijzelf aan de toonbank. Loop daarna per persoon de stappen door. Als je hierop drukt, verschijnt dit. Je hoeft niets te tekenen, al mag dat natuurlijk op een stuk papier. Denk ook aan de momenten waarop het misgaat: wat gebeurt er als iemand zich vergist, of als er geen bereik is?

Die stappen werken beter dan een lijst met functies. “Afspraken beheren” kan voor jou iets anders betekenen dan voor de persoon die het bouwt, en als je de stappen uitschrijft, komt dat verschil vanzelf boven.

Wat je nog kan vermelden

Noem de software die je nu al gebruikt, zoals je kassa, je boekhouding of je agenda, ook als je niet weet of ze ertoe doet. Een koppeling kan veel dubbel werk uitsparen, en de ontwikkelaar kan dan meteen kijken of ze mogelijk is.

Is er een echte datum, zoals een beurs, een opening of het begin van een seizoen, vermeld die dan, met de reden erbij. Is er geen, zeg dat ook. Over geld mag je open zijn. Heb je een grens in je hoofd, schrijf die dan op, en “ik heb geen idee wat dit kost” is ook een goed antwoord. Bij mij begint dat gesprek met wat “veel geld” voor jou betekent. In Wat maakt een app duur of goedkoop? lees je wat de prijs bepaalt.

Wat je mag openlaten

Je hoeft geen programmeertaal of database te kiezen. Of het een app, een webapp of een website wordt, mag ook open blijven: dat komt in het gesprek wel aan bod, en dit artikel helpt je daarbij. Schrijf gewoon “weet ik niet” als je iets niet weet. Dat zegt een ontwikkelaar meer dan een gok, want een gok kan voor waar aangenomen worden.

Heb je wel een vaste voorkeur, bijvoorbeeld omdat je team alleen op iPhones werkt, schrijf die dan op, met de reden.

Een voorbeeld

Stel dat je een kapsalon hebt met drie kappers. Je briefing zou er zo kunnen uitzien:

Wat we nodig hebben: klanten moeten zelf online een afspraak kunnen maken.

Waarom: de telefoon gaat terwijl we aan het knippen zijn. We nemen niet altijd op, en dan belt de klant soms een andere zaak.

Hoe het nu gaat: afspraken staan in een papieren agenda aan de kassa. Elke kapper heeft zijn eigen kolom. Vaste klanten sturen soms een berichtje naar de gsm van hun kapper, en dat schrijven we dan over.

Onze woorden: een “behandeling” is knippen, kleuren of een combinatie. Kleuren duurt langer, en tijdens het inwerken van de kleur kan een kapper iemand anders knippen.

Wanneer het een succes is: minder telefoontjes tijdens het werk, en geen dubbele afspraken meer.

Wat kan wachten: cadeaubonnen en betalen op voorhand.

Waar we niet over onderhandelen: elke kapper bepaalt zelf zijn uren.

De weg van de klant: ik open de pagina op mijn telefoon, kies een behandeling en een kapper, zie de vrije momenten, kies er een en krijg een bevestiging. De kapper ziet de afspraak meteen in de agenda.

Wat we al gebruiken: een kassasysteem, en Google Agenda op de telefoon van één kapper.

Wat we niet weten: of dit een app moet zijn, en wat het zou kosten.

Een ontwikkelaar haalt hier meteen een vraag voor het eerste gesprek uit: hoe gaat een online agenda om met een kapper die iemand anders knipt terwijl de kleur inwerkt?

Lees ook

Wat is jouw idee?

Vertel me wat je wil bouwen. Ik probeer binnen één werkdag te antwoorden.