# 08\_sjabloon\_diepgaand\_onderzoek\_voorbeeld.md

Doel: voorbeeldinvulling van het onderzoekssjabloon voor een toolselectie met Diepgaand onderzoek. Gebruik dit als startpunt en pas het aan naar jouw organisatie.

## 1\) Beslisdoel

Wat moet er na dit onderzoek besloten worden?

* Beslisdoel: een tool kiezen voor team-samenwerking rond klantdocumentatie (schrijven, reviewen en publiceren op een klantgericht documentatieportaal).
* Deadline: morgen einde werkdag (besluit nodig voor start proefweek).
* Beslisser(s): teamlead Support, teamlead Product en een vertegenwoordiger van IT/security (goedkeuring op SSO en audit).
* Gebruikersgroep: circa twintig interne gebruikers (tien auteurs, vijf reviewers, twee publishers, drie beheerders) en externe lezers (klanten) zonder account.

## 2\) Toolcategorie en use-case

* Toolcategorie: klantdocumentatieplatform (knowledge base voor externe documentatie).
* Use-case: één centrale plek voor productdocumentatie, onboarding, release notes en veelgestelde vragen, met een redactieflow en publicatie op eigen domein.
* Publiek: beide (extern klantportaal, intern redactie- en reviewteam).
* Type content: handleidingen, onboarding, release notes, policies, faq en kennisbankartikelen.

## 3\) Huidige situatie

* Huidige tool(s): Google Docs voor concepten, losse Markdown in GitHub voor technische stukken, en een eenvoudige webpagina voor publicatie.
* Pijnpunten: versies lopen door elkaar, review gebeurt ad hoc, publicatie kost handwerk, er is geen eenduidige bronversie en terugzetten naar een eerdere versie is onhandig.
* Wat moet blijven werken: publicatie op eigen domein, een snelle zoekfunctie voor klanten en de mogelijkheid om content als Markdown te exporteren voor back-up.

## 4\) Eisen (must-haves)

Maak dit zo concreet mogelijk. Gebruik waar kan meetbare criteria.

* Publicatie op eigen domein: ondersteuning voor custom domain (bijvoorbeeld docs.bedrijf.nl) en een nette publieke zoekfunctie.
* Redactieflow: concept → review → live, met duidelijke statussen en toewijzing van reviewers (minimaal twee rollen: auteur en reviewer).
* Versiebeheer: versiegeschiedenis per artikel met mogelijkheid om wijzigingen te vergelijken en terug te zetten (rollback) zonder handmatig kopiëren.
* Toegang: SSO via SAML voor interne auteurs en reviewers; role-based access control voor wie kan publiceren.
* Export en basisinzicht: export of back-up in Markdown (of via API) en basis-analytics zoals zoektermen, no-result searches en artikelprestaties.

## 5\) Wensen (nice-to-haves)

* Meertaligheid: ondersteuning voor Nederlands en Engels met taalvarianten per artikel.
* Integratie met support: koppeling met Zendesk of een vergelijkbaar supportsysteem, zodat supportartikelen en productdocs elkaar versterken.
* Feedbackloop: eenvoudige feedbackmogelijkheid voor lezers (was dit artikel nuttig) en een lijst met artikelen die aandacht nodig hebben.

## 6\) Uitsluitingen

Wat willen we expliciet niet?

* Geen self-hosted oplossing (we kiezen SaaS om beheerlast te beperken).
* Geen tool die alleen intern werkt of primair een wiki is zonder goede externe publicatie en redactieflow.

## 7\) Samenwerking en redactie

* Rollen en rechten: auteur (schrijft), reviewer (keurt goed), publisher (zet live), beheerder (instellingen en rechten).
* Review/approval: minimaal één reviewer verplicht voordat publicatie mogelijk is; reviewers krijgen notificaties en kunnen commentaar geven.
* Versiebeheer: per artikel versiehistorie met diff en rollback; een changelog is wenselijk maar niet vereist.
* Publiceren: conceptomgeving en live omgeving; publicatie per productlijn of sectie; preview moet mogelijk zijn voordat iets live gaat.

## 8\) Integraties en beheer

* Identiteit en toegang: SAML SSO voor interne gebruikers; optioneel ook SSO voor interne lezers.
* Integraties: Slack of Microsoft Teams voor reviewnotificaties, Google Workspace als identity provider, Jira voor koppeling met change requests, Zendesk voor supportkoppeling.
* Import/export: Markdown-export of API voor back-up, plus een eenvoudige importroute voor bestaande Docs of Markdown.
* Analytics: zoektermen, no-result searches, artikelweergaven en trend over tijd (minimaal maandniveau).

## 9\) Compliance en randvoorwaarden

* GDPR / data-afspraken: geen opslag van persoonsgegevens in content; dataverwerkingsovereenkomst beschikbaar; duidelijk beleid voor logdata.
* Audit en logging: auditlog voor wijzigingen en publicaties (wie wijzigde wat, wanneer) en inzicht in publicatiebeslissingen.
* Hostingvoorkeur: SaaS met EU-regio of ten minste contractuele garanties rond gegevensverwerking en opslag.

## 10\) Budget en implementatie

* Budgetrange: 6000–15.000 euro per jaar (indicatief, afhankelijk van licenties en teamgrootte).
* Implementatietijd: twee tot vier weken voor opzet, migratie van kernartikelen en training van het redactieproces.
* Begeleiding/partner nodig: nee, tenzij migratie complex blijkt; we willen standaard migratie tooling en documentatie.

## 11\) Output die je wilt (voor Diepgaand onderzoek)

* Vergelijkingstabel met criteria: publicatie extern, samenwerking en review, versiebeheer, SSO, export, analytics, sterke punten, zwakke punten, risico’s.
* Top drie aanbevelingen met trade-offs: ja.
* Bronnen per belangrijke claim: ja, bij voorkeur officiële documentatie per tool en waar relevant aanvullende onafhankelijke bronnen.
* Risico’s, onzekerheden en verificatiestappen: ja, inclusief wat we in een proefweek moeten testen.
* Eindig met een keuzeadvies voor: een teamlead die morgen moet beslissen (maximaal 250 woorden, met keuze, trade-offs, risico’s en eerstvolgende stap).
