Week 4 · Fase 2: Verdiepen STRETCH

Projectupdate schrijven voor twee doelgroepen

Eén update, drie doelgroepen: manager, klant, team. Eén keer schrijven, Copilot doet de rest.

Tijd
15 min
Level
Level 2 🔥🔥
Wat je leert

Dezelfde bron, andere versies, zichtbaar verschil

Projectupdates lekken. Interne zorgen belanden in klantmails, klantdetails in MT-rapporten. Het probleem is zelden schrijfvaardigheid. Het is context-management: je geeft Copilot niet genoeg sturing over wie het leest en waarom.

Je genereert twee versies van dezelfde update uit dezelfde Planner- en Teams-bron. Je wijzigt alleen doelgroep + doel in de prompt. Copilot past toon, lengte en detailniveau automatisch aan. Je legt de versies naast elkaar en ziet wat er verandert: niet de feiten, wel de framing.

Dat naast-elkaar-leggen is het didactische moment. Welke zinnen zijn letterlijk hetzelfde? Welke zijn fundamenteel anders? Daar zit het principe: dezelfde brondata, andere doelgroep-prompt, fundamenteel ander document.

Nog nooit een multi-doelgroep-update met Copilot geschreven? Geen probleem. Je hebt alleen een lopend project nodig waarvan de status in Planner staat en recente updates in een Teams-kanaal. De twee prompts hieronder draai je in één Copilot Chat-sessie.

Het framework

Drie knoppen die het verschil sturen

Drie knoppen die het verschil sturen

B
Bron
P
Publiek
D
Doel

Elke update-prompt heeft drie knoppen. Bron (de Planner, het Teams-kanaal, het dossier) blijft gelijk voor beide versies. Publiek (MT, klant, partner, team) bepaalt toon en detailniveau. Doel (bottlenecks, voortgang, risico, actie) bepaalt wat Copilot vóóraan zet. Verander P + D en je krijgt een ander document uit dezelfde B.

A/B · Vergelijk naast elkaar

Twee prompts, een bron

Versie A
Versie A · MT-update
Schrijf een management-update over project [naam] op basis van de laatste Teams-berichten en Planner-status. Doelgroep: MT. Doel: strategische highlights en bottlenecks. Lengte: 120 woorden. Toon: zakelijk, beslisgericht.
Waarom werkt dit

Doelgroep (MT) + doel (strategische highlights + bottlenecks) sturen de inhoud. Toon-tag maakt het zakelijk in plaats van informeel. Bewaar deze draft; je gaat 'm straks naast versie B leggen.

Versie B
Versie B · klantupdate
Schrijf een klantupdate over hetzelfde project op basis van dezelfde bronnen. Doelgroep: klant. Doel: voortgang deze week + vervolgstap. Lengte: 100 woorden. Toon: behulpzaam, helder, zonder interne jargon.
Waarom werkt dit

Zelfde bron, andere doelgroep + doel. In dezelfde Copilot Chat-sessie draaien: Copilot houdt de bron-context vast en past alleen publiek en doel aan. Vergelijk met versie A: welke feiten zijn letterlijk gelijk, welke framing is anders?

AAN DE SLAG

Oefeningen

Pak een echt lopend project waarvan zowel management als klant deze week op de hoogte moet blijven. Geen fictief voorbeeld: je eigen werk. Je draait beide prompts in één Copilot Chat-sessie en legt de output naast elkaar.

Werkblad 3 stappen
  1. Bron Stap 1 van 3

    Noem Planner en Teams letterlijk

    Open Copilot Chat in Work-mode. Begin met: 'Gebruik Planner [naam] en Teams-kanaal [naam] (laatste 5 berichten) als bron voor de volgende twee updates.' Copilot bevestigt dat hij de bronnen kan zien voordat je de prompts draait.
  2. Versie A Stap 2 van 3

    Draai de MT-update

    Plak versie A (MT-update, 120 woorden, zakelijk-beslisgericht). Copilot genereert op basis van Planner + Teams. Bewaar de output in een Loop-pagina of nieuw Word-document; je legt 'm zo naast versie B.
  3. Versie B Stap 3 van 3

    Draai de klantupdate in dezelfde sessie

    Plak direct versie B onder versie A. Niet een nieuwe chat openen: Copilot moet de bron-context vasthouden. Vergelijk de output: welke drie zinnen zijn fundamenteel anders dan in versie A?

Hint: Geen lopend project met dubbele doelgroep? Gebruik een fictief projectscenario maar maak de Planner- en Teams-bron echt (bijvoorbeeld een intern initiatief dat je zelf trekt). Het vier-knoppen-patroon werkt op elke update waar bron + publiek + doel in het spel zijn.

De A/B vergelijking is het wow-moment. Niet omdat het mooi is, maar omdat je in drie minuten een principe formuleert dat je de rest van de Sprint hergebruikt.

Werkblad 3 stappen
  1. Wat is gelijk? Stap 1 van 3

    Identificeer de feit-zinnen

    Onderstreep (of highlight) de zinnen die in beide versies letterlijk hetzelfde zijn, of alleen qua formulering verschillen. Dit zijn je feit-zinnen: hier zit de bron, niet de framing.
  2. Wat is anders? Stap 2 van 3

    Identificeer de framing-zinnen

    Onderstreep in een andere kleur de zinnen die alleen in één versie voorkomen of fundamenteel anders zijn geformuleerd. Dit zijn framing-zinnen: publiek + doel sturen deze zinnen, de bron niet.
  3. Principe Stap 3 van 3

    Formuleer je eigen regel

    Schrijf één zin op die jouw observatie samenvat. Bijvoorbeeld: 'Feiten staan in beide; bottlenecks alleen in MT; vervolgstap alleen in klant.' Dit is je eigen A/B-principe; je gebruikt het bij iedere update die je de rest van deze Sprint schrijft.

Na deze oefening heb je geen abstracte regel, maar een zin die je op jouw werk heeft getest. Die zit beter vast dan elke didactische uitleg.

Hint: Zet beide drafts in dezelfde Loop-pagina met een dunne lijn ertussen. Onderstreep met twee kleuren (bijvoorbeeld geel = gelijk, blauw = anders). Daarna zie je met één blik wat publiek + doel heeft gedaan.

Let op

Wat vaak misgaat

Waarom dit werkt

Waarom dezelfde feiten een ander document worden

Copilot kent de Planner en de Teams-berichten, maar weet niet wie de update gaat lezen. Zonder expliciete publiek + doel-instructie kiest hij een default: beleefd, generiek, middenregister. Dat past bij niemand precies. Drie knoppen aandraaien kost één zin; weglaten kost een herschrijving.

  • Geen expliciete bron Copilot improviseert of valt terug op training-data; feiten zijn niet verifieerbaar
  • Geen publiek-instructie Default-toon: nette middle-register die nergens raakt
  • Geen doel-instructie Copilot zet alles in gelijke volgorde; de lezer vindt de pointe niet
  • Geen lengte 120 woord of 400 woord is gokwerk; vaak disclaimer-proza dat je alsnog inkort

Twee versies schrijven kost één minuut extra prompten. Een update achteraf herschrijven voor een tweede doelgroep kost tien.

Dezelfde feiten, andere framing. Dat is waarom klantupdates geen MT-updates zijn.
Tips

Tips die het verschil maken

Probeer: dezelfde bron, twee versies. Gebruik exact dezelfde Planner-status en Teams-berichten voor beide versies. Wijzig alleen doelgroep + doel in de prompt. Zo isoleer je de variabele en zie je wat publiek-sturing echt doet met identieke feiten.

Probeer: specificeer doel per versie. MT wil bottlenecks en beslispunten. Klant wil voortgang en vervolgstap. Team wil wie wat doet. Het verschil zit in het doel, niet alleen de toon. Noem het letterlijk: 'doel: strategische beslispunten' versus 'doel: voortgang deze week + vervolgstap'.

Probeer: leg ze naast elkaar in Word. Open de twee versies in een Loop-pagina of twee kolommen in Word. Welke zinnen zijn letterlijk hetzelfde? Welke zijn fundamenteel anders? Dit is de leerervaring: je ziet welke zinnen doelgroep-gestuurd zijn en welke feit-gestuurd.

Morgen anders

Eerstvolgende projectupdate: twee versies, één sessie

Morgen kies je een project waar je deze week een update voor moet schrijven. In plaats van één mail voor iedereen:

  1. Open één Copilot Chat in Work-mode. Noem Planner en Teams-kanaal letterlijk als bron.
  2. Draai versie A (MT of partner, met eigen doel + lengte). Bewaar de draft.
  3. Draai versie B (klant of team, met eigen doel + lengte) in dezelfde sessie.
  4. Leg beide drafts naast elkaar in Loop of Word. Check: geen lek tussen versies.

Bewaar de twee prompts in je bibliotheek onder 'projectupdate-MT' en 'projectupdate-klant'. Volgende keer 30 seconden werk per versie.

Check jezelf
Kernboodschap

Dezelfde feiten, ander doel + doelgroep, ander document. Dat verschil zit in je prompt, niet in de brondata.

Inleveren

Lever je werk in

Kies wat je wil inleveren voor MW-15.

Rubric
Output
Reflectie
Morgen
Rubric

Werkt het bij jou?

Drie korte vragen op je eigen output.