Claude Projects: gedeelde kennis die je team niet steeds opnieuw hoeft uit te leggen

Claude Projects laat je een gedeelde werkruimte opzetten voor je team: met vaste instructies, geüploade documenten en organisatiespecifieke context. Claude weet in elk gesprek direct hoe jullie werken, wat jullie toon is en welke informatie relevant is. Je legt het één keer uit — niet bij elke nieuwe chat opnieuw.

De meeste teams die Claude gebruiken, werken met losse gesprekken. Iedere medewerker begint elke ochtend met een lege chat en legt opnieuw uit wie hij is, hoe de organisatie werkt en wat de gewenste schrijfstijl is. Dat werkt — maar het is inefficiënt. Bij elk nieuw gesprek verdwijnt de opgebouwde context. Projects lost dat op.

Wat zijn Projects?

Projects zijn gecentraliseerde werkruimtes in Claude. Je maakt een Project aan voor een team, afdeling of specifieke werkstroom. In dat Project stel je vast: welke instructies Claude altijd volgt, welke documenten of bestanden Claude kan raadplegen, en welke toon en aanpak van toepassing zijn.

Alle gesprekken die medewerkers voeren binnen dat Project, starten met die context geladen. Claude hoeft niet meer 'opgewarmd' te worden. De context is er al — bij elk gesprek, voor elke medewerker die toegang heeft.

Projects zijn beschikbaar in Claude Pro (persoonlijk gebruik) en Claude Teams/Enterprise (gedeeld teamgebruik). Het fundamentele verschil: bij Teams en Enterprise deel je de Project-omgeving — inclusief instructies en documenten — met collega's. Iedereen in het Project werkt met dezelfde kennisbasis.

Persoonlijk vs. gedeeld.

Niet elk Project hoeft gedeeld te zijn. Voor individuen zijn persoonlijke Projects al waardevol — voor teams pas echt transformatief. Dit is het verschil:

Persoonlijke Projects zijn krachtig voor individuen met vaste werkstromen: een analist die altijd dezelfde type rapporten genereert, een marketeer die altijd in dezelfde schrijfstijl werkt. Gedeelde Projects zijn wat de meeste organisaties zoeken: consistentie over het hele team, zonder dat iedereen het wiel opnieuw moet uitvinden.

Project instructies schrijven.

De Project instructions zijn het fundament van elk Project. Dit is de tekst die Claude bij elk gesprek in dat Project als startpunt krijgt. Schrijf ze niet als een lijst regels — schrijf ze als een introductie van je organisatie en haar verwachtingen.

Effectieve Project instructions bevatten vier elementen:

1. Wie je bent als organisatie. Niet de volledige bedrijfsomschrijving, maar de essentie: type bedrijf, sector, doelgroep, kernactiviteit.
2. Hoe je communiceert. Formeel of informeel? Directe taal of diplomatiek? Welke terminologie gebruik je? Welke woorden vermijd je?
3. Wat Claude weet over het team. Welke rollen werken in dit Project? Welke taken voeren ze het vaakst uit? Wat zijn de meest voorkomende verzoeken?
4. Wat Claude nooit doet. Uitsluitingen, drempelwaarden, gevoelige gebieden. Wat is off-limits voor dit Project?

Een concreet voorbeeld voor een juridisch team:

Je werkt als assistent voor het juridische team van [Organisatie].
Communicatiestijl: formeel, nauwkeurig, zonder vakjargon voor niet-juristen.

Team: contractjuristen, paralegal medewerkers en de compliance officer.
Meest voorkomende taken: contractreview, clausule-analyse, interne adviesnota's.

Gebruik altijd "opdrachtgever" voor de klant en "opdrachtnemer" voor ons.
Verwijs bij twijfel nooit naar externe rechtsbronnen zonder dit expliciet te vermelden.
Maak geen inhoudelijke juridische beoordelingen — signaleer en beschrijf.
Het oordeel is altijd aan de jurist.

Goede instructies zijn specifiek zonder te rigide te zijn. Ze geven Claude genoeg richting om zelfstandig de juiste keuzes te maken — zonder dat je bij elke randcase een aparte regel moet schrijven.

Documenten toevoegen.

De tweede pijler van een Project is de kennisbasis: documenten die je uploadt en die beschikbaar blijven voor alle gesprekken in dat Project. Claude kan de inhoud raadplegen zonder dat medewerkers de bestanden telkens opnieuw hoeven bij te voegen.

Wat goed werkt als Project-document:

• Huisstijlgids of schrijfwijzer — zodat toon en woordkeuze altijd kloppen
• Productinformatie of dienstbeschrijvingen — als grondstof voor klantcommunicatie
• Contractsjablonen of standaardclausules — voor juridische workflows
• Procesbeschrijvingen of werkinstructies — voor operations en support
• Frequently asked questions — intern of extern, als referentiekader
• Bestaande rapporten als format-referentie — zodat nieuwe rapporten de juiste structuur volgen

Wat je niet hoeft te uploaden: documenten die per gesprek wisselen. Projectspecifieke data, actuele cijfers of klantspecifieke informatie voeg je per gesprek toe. De Project-documenten zijn de stabiele achtergrond — de dingen die altijd waar zijn voor dit team.

“Elke nieuwe medewerker die we aannemen, heeft binnen tien minuten toegang tot een Claude-omgeving die al weet hoe wij schrijven, wat onze producten zijn en welke tone of voice we hanteren. Dat is onboarding die we vroeger handmatig deden.”— Hoofd marketing, zakelijke dienstverlener, 85 medewerkers

Voorbeelden per afdeling.

Hoe Projects in de praktijk worden ingericht, verschilt per team. Dit zijn vier configuraties die we regelmatig opzetten:

Marketing en communicatie.

Project instructions: schrijfstijl, tone of voice, merkwaarden, doelgroepomschrijving, aanspreekvorm. Documenten: contentstrategie, huisstijlgids, bestaande teksten als referentie. Typische taken: blogdrafts, social media-posts, nieuwsbrieven, campagneteksten, persberichten.

Juridisch en compliance.

Project instructions: formaliteitsniveau, vaste terminologie, uitsluitingen voor inhoudelijke beoordelingen. Documenten: standaardcontracten, AVG-beleid, interne compliance-richtlijnen. Typische taken: contractreview, adviesnota's, samenvatten van nieuwe wetgeving, compliance-checklists.

Operations en projectmanagement.

Project instructions: interne procesterminologie, rapportageformat, escalatieprocedures. Documenten: proceshandleidingen, SLA-afspraken, projecttemplates. Typische taken: statusrapporten opstellen, incidentsamenvatting, werkinstructies verfijnen, projectplannen doorlichten.

IT en development.

Project instructions: technische standaarden, codeerstijl, architectuurprincipes, naamgeving. Documenten: API-documentatie, technische specificaties, architectuurdocumenten. Typische taken: codereview, documentatie schrijven, technische uitleg voor stakeholders, impactanalyse van wijzigingen.

Best practices.

Een Project opzetten duurt tien minuten. Een goed Project bouwen vraagt meer zorgvuldigheid — maar de investering betaalt zich terug bij elk gebruik daarna.

• Begin smal. Richt je eerste Project in voor één team of één afgebakende werkstroom. Geen allesomvattend organisatieproject als startpunt.
• Test voor je uitrolt. Voer tien representatieve gesprekken in het Project. Is de output consistent? Zijn er blinde vlekken in de instructies?
• Wijs een eigenaar aan. Iemand is verantwoordelijk voor het onderhouden van instructies en het bijwerken van documenten. Zonder eigenaar veroudert een Project snel.
• Evalueer per kwartaal. Welke instructies zijn nog relevant? Zijn er nieuwe documenten die erbij horen? Wat vragen medewerkers het vaakst?
• Combineer met Skills. Projects leveren de context — Skills leveren de structuur voor terugkerende taken. Samen zijn ze sterker dan elk afzonderlijk.

Volgens onderzoek van Anthropic werken teams die Claude Projects gebruiken met gedeelde instructies en documenten gemiddeld 30 tot 40 procent efficiënter per AI-taak dan teams die met losse gesprekken werken. Het verschil zit niet in de capabilities van het model — het zit in de context die het model meekrijgt.

Wil je weten hoe je Projects inricht voor jouw team? We begeleiden de eerste setup en helpen de instructies zo schrijven dat Claude direct waardevol is. Dertig minuten, vrijblijvend.