Je hebt net een lange, gestructureerde update aan een klant in Gmail afgerond. Je drukt op verzenden, schakelt over naar Slack en aarzelt even. Je vingers willen in diezelfde formele toon doorgaan. Verkeerde app. Verkeerde sfeer.
Dus je wist de "Ik hoop dat dit bericht u in goede gezondheid bereikt" die je bijna typte en begint opnieuw met een vriendelijkere begroeting. Drie apps later zit je opnieuw te herschrijven voor een Notion-document. En daarna nog eens voor een code review-opmerking. Telkens weer doe je hetzelfde kleine stukje denkwerk: uitvogelen welke toon de app verwacht.
De gemiddelde kenniswerker wisselt zo'n 1.200 keer per dag tussen apps, en elke wissel komt met eigen schrijfconventies. Je brein kent ze, maar betaalt er telkens een belasting voor om opnieuw af te stemmen. Slimme schrijfregels zijn de oplossing. Ze laten je tools de toon automatisch per app aanpassen, zodat jij dat niet meer hoeft.
Waarom één schrijftoon niet bij elke app past
Elke app die je gebruikt is gebouwd voor een ander soort communicatie. De conventies die erin zijn ingebakken vertellen je welk soort schrijfwerk daar thuishoort, vaak zonder dat je het doorhebt.
Slack is gebouwd op snelheid. Berichten zijn kort, lopen in threads en worden vaak alleen vluchtig gelezen. Een formele "Beste team," voelt stijf of vaag passief-agressief. Slacks eigen onderzoek naar communicatie op de werkvloer toonde aan dat 70% van de werknemers informele communicatie van collega's verkiest boven strikt zakelijke taal.
E-mail is het tegenovergestelde. Het is de plek voor gestructureerd denken, documentatie en berichten die misschien jaren bewaard of doorgestuurd worden. Een nonchalante "hey" werkt prima in Slack maar valt verkeerd in een klantmail. Het formaat zelf — onderwerpregel, aanhef, ondertekening — nodigt uit tot een meer doordachte toon.
Dan zijn er documenten. Notion, Google Docs, Confluence-pagina's. Die zitten ergens daartussenin: gestructureerder dan chat, minder uitgesproken dan e-mail. Lijsten en koppen doen ertoe. Zinnen worden langer.
Code-editors en CLI's vragen een heel andere stijl. Commentaar en commitberichten horen beknopt, specifiek en in de tegenwoordige tijd te zijn. "Handles the case where the user is null" wint het van "Hoi team, ik heb een kleine wijziging gemaakt voor een lastig randgeval."
Posts op X (Twitter) vormen hun eigen wereld: pittig, met regelafbrekingen, vaak bewust wat ruw aan de randen om aan te sluiten bij de feed. LinkedIn-posts zijn warmer en persoonlijker. Projecttools zoals Linear en Jira willen platte, beslissingsgerichte opmerkingen zonder inleiding.
Dit weet je allemaal al. Je past het constant toe. De prijs is alleen dat je het bij elk bericht handmatig doet.
De verborgen kosten van handmatig schakelen tussen tonen
Wisselen van toon voelt gratis omdat elke afzonderlijke wissel klein is. Maar de totalen lopen snel op.
Asana's Anatomy of Work Index wees uit dat kenniswerkers ongeveer 10 verschillende apps per dag gebruiken en daar zo'n 25 keer tussen schakelen. Een aparte studie in Harvard Business Review zette het cijfer op bijna 1.200 wissels per dag tussen applicaties en websites — ongeveer één wissel elke 24 seconden gedurende een achturige werkdag.
Bij de meeste van die wissels komt schrijven kijken. Een Slack-antwoord, een e-mailconcept, een Linear-opmerking, een aanpassing in een document. Elk vraagt een snelle mentale herafstemming: - Hoe formeel moet dit zijn? - Hoe lang? - Mag ik hier emoji gebruiken? - Opsommingstekens of alinea's? - Sluit ik af, of stop ik gewoon?
Vermenigvuldig die microbeslissingen met honderden berichten per dag en je hebt een serieuze cognitieve belasting. 45% van de werknemers zegt dat schakelen tussen te veel apps hen minder productief maakt, en 43% ervaart het als mentaal uitputtend. Een deel van die belasting gaat zitten in uitvogelen welk soort schrijfwerk de volgende app verwacht.
Wat "slimme schrijfregels" eigenlijk inhouden
Een slimme schrijfregel bestaat uit twee aan elkaar geplakte onderdelen: een trigger (in welke app je zit) en een prompt (hoe de AI je tekst moet herschrijven of polijsten). Wanneer je in de actieve app schrijft of inspreekt, vuurt de regel af en wordt de output gevormd om bij die app te passen.
Je vertelt de tool niet elke keer "maak dit informeel". Je stelt de regel één keer in voor Slack, één keer voor Gmail, één keer voor Notion. De tool detecteert welke app actief is en past de bijbehorende stijl toe.
Het resultaat: je typt of dicteert overal op dezelfde manier, en de gepolijste output past zich aan waar het naartoe gaat. De wrijving van toonwisselingen daalt van "bij elk bericht" naar "één keer instellen".
Dit is iets anders dan een generieke AI-toonomzetter waar je tekst plakt, een toon uit een dropdown kiest en het resultaat terugkopieert. Daar blijft het werk bij jou liggen. Slimme regels halen de dropdown weg.
Anatomie van een goede schrijfregel
Een goede regel voor één app heeft ongeveer vijf onderdelen. Sla er één over en de output begint af te drijven.
1. Mate van formaliteit
Informeel, neutraal, zakelijk of technisch. Dit bepaalt de temperatuur van het hele bericht: woordkeus, samentrekkingen, zinsritme.
2. Doellengte
Kort en direct (Slack), middellang en gestructureerd (e-mail), of wat de app ook vraagt. Regels zonder lengtekader hebben de neiging standaard te veel uit te leggen.
3. Structuur
Opsommingstekens, genummerde lijsten, alinea's, koppen. Een regel voor Notion moet structuur aanmoedigen. Een regel voor Slack moet die juist ontmoedigen.
4. Beleid voor emoji en leestekens
Sommige apps zijn dol op emoji, andere niet. Sommige gemeenschappen gebruiken kastlijntjes, andere niet. Door het beleid expliciet te maken, voorkom je dat de AI een standaardkeuze maakt die niet bij je team past.
5. Afsluitgedrag
E-mail heeft een afsluiting nodig. Slack niet. Code-commentaar ook niet. Specificeer je dat niet, dan krijg je inconsistente einden. De helft van je Slack-berichten sluit dan willekeurig af met "Bedankt," omdat het model dat beleefd vindt.
Samen vormen deze vijf instellingen een vaag "maak het passend voor deze app" om tot een regel die elke keer consistente output levert.
Dit is precies wat de Smart Rules-functie van Voicr doet op macOS. Je houdt de FN-toets ingedrukt, spreekt vanuit elke app, en de regel voor die app polijst je uitspraak automatisch. De output staat al in de juiste toon voordat hij op je klembord belandt. Geen dropdowns, geen toonkiezers, geen "wacht, laat me dat even herschrijven."
Voorbeeldregels die je zo kunt overnemen
Hieronder staan regelprompts voor de apps die je waarschijnlijk het vaakst gebruikt. Ze zijn geschreven in gewone taal, zoals je elk model zou aansturen. Plak ze in Voicr, een Raycast AI-commando, een Shortcuts-actie, of welke tool dan ook die je tekst door een LLM haalt.
Slack-regel
``` Herschrijf de input als een informeel, vriendelijk Slack-bericht. Houd het bij maximaal 2-3 zinnen. Gebruik samentrekkingen. Laat begroetingen en afsluitingen weg. Gebruik geen opsommingstekens tenzij ik letterlijk dingen opsom. Lichte emoji is prima als het natuurlijk past. Sla "Hoop dat het goed met je gaat" en vergelijkbare opvulling over. ```
E-mailregel (Gmail, Outlook, Apple Mail)
``` Herschrijf de input als een zakelijke maar warme e-mail. Begin met een korte begroeting die de voornaam van de ontvanger gebruikt als ik die heb genoemd. Gebruik heldere alinea's van 2-4 zinnen elk. Sluit af met een beleefde groet ("Met vriendelijke groet," of "Bedankt,"). Gebruik geen emoji. Gebruik samentrekkingen spaarzaam om de toon te verzachten zonder onprofessioneel te worden. ```
Notion / Docs-regel
``` Herschrijf de input als heldere, gestructureerde documenttekst. Gebruik korte alinea's en opsommingen waar dat past. Geef de voorkeur aan platte koppen boven vetgedrukte tekst in de lopende zin. Schrap eerste-persoonsvulling zoals "ik denk" of "ik wil zeggen". Laat het klinken als een afgewerkt onderdeel, niet als een chatbericht. ```
Linear / Jira-regel (engineering-tickets)
``` Herschrijf de input als een gerichte engineering-opmerking op een ticket. Wees direct en beknopt. Gebruik de tegenwoordige tijd. Begin met de conclusie of beslissing. Gebruik opsommingstekens als er meerdere punten zijn. Geen begroetingen, geen afsluitingen. ```
Code-editor-regel (VS Code, Cursor, Xcode)
``` Herschrijf de input als een kort code-commentaar. Tegenwoordige tijd. Geen "ik" of "we". Eén zin is ideaal, twee maximaal. Herhaal niet wat de code overduidelijk doet — leg het waarom of het niet-vanzelfsprekende stukje uit. ```
X (Twitter)-regel
``` Herschrijf de input als een tweet. Pittig, met regelafbrekingen voor leesbaarheid, geen corporate taal. Kleine letters zijn prima. Schrap relativeringen als "naar mijn mening". Maximaal 240 tekens. Geen hashtags tenzij ik ze er zelf bij zet. ```
Dit zijn startpunten. Schaaf aan de formulering tot de output klinkt als *jij*, niet als de standaard AI-stem.
Regels koppelen aan de apps die je daadwerkelijk gebruikt
Je hebt geen regel nodig voor elke app die je opent. Je hebt regels nodig voor de apps waarin je veel schrijft.
Loop je laatste week door en let op waar je typwerk daadwerkelijk naartoe ging. Voor de meeste mensen is dat een kort lijstje: 1. Eén chat-app — Slack, Teams, Discord of iMessage 2. Eén e-mailclient — Gmail, Outlook, Apple Mail 3. Eén documenten- of notitie-app — Notion, Google Docs, Apple Notes, Obsidian 4. Eén projecttool — Linear, Jira, Asana, Height 5. Eén code-editor of terminal — VS Code, Cursor, Xcode, iTerm 6. Eventueel één sociale app — X, LinkedIn, Bluesky
Stel regels in voor die zes (of minder). Al het andere kan terugvallen op een verstandige standaard-polijstregel. Er is geen beloning voor 30 regels. Wel een straf, want dan moet je onthouden welke waar geldt.
Voor een diepere blik op de dictatiezijde van elke app, zie onze gidsen over spraak naar tekst in Slack, e-mails dicteren op de Mac en steminvoer in Notion.
Veelgemaakte fouten bij het opzetten van schrijfregels
De meeste regelopzetten gaan op een paar voorspelbare manieren mis.
Regels die te vaag zijn
"Laat het zakelijk klinken" geeft de AI te veel ruimte. Specificeer lengte, structuur, afsluitgedrag en emoji-beleid. Hoe concreter de regel, hoe consistenter de output.
Regels die te strak zitten
De omgekeerde valkuil. Als je Slack-regel een maximum van vijf woorden afdwingt, komt elk bericht er afgekapt en raar uit. Stel richtlijnen op, geen handboeien.
Identieke regels met verschillende namen
Het is verleidelijk om je e-mailregel te kopiëren naar "Confluence" en "Notion" en "Jira" en het daarbij te laten. Elk verdient een eigen touch. Zijn twee regels echt identiek, voeg ze dan samen en laat één regel beide apps afhandelen.
Regels die tegen je stem in werken
Jouw schrijven heeft persoonlijkheid. Een regel die alles in corporate boilerplate verandert, zorgt ervoor dat je de tool binnen een week niet meer gebruikt. Het doel is om je stem te vertalen naar het juiste register per app, niet om hem te vervangen door die van iemand anders.
De fallback vergeten
Wat gebeurt er als je schrijft in een app waar geen regel voor is? De meeste tools vallen terug op een generieke polijst. Zorg dat die fallback iets is waar je tevreden mee bent, want hij zal vaker draaien dan je denkt.
Slimme schrijfregels in de praktijk brengen
Als je één ding meeneemt uit dit stuk, laat het dit zijn: de kosten van toonwisselingen zijn reëel en stapelen zich snel op. Elke microherschrijving, elke kleine herafstemming telt op gedurende een werkdag. Slimme schrijfregels zijn hoe je stopt met die belasting betalen.
Begin klein. Kies de twee apps waar je het meeste schrijft — meestal Slack en e-mail — en schrijf één regel voor elk. Gebruik ze een paar dagen. Let op wat niet helemaal lekker zit en pas de formulering aan. Voeg dan een derde regel toe voor de app die qua wekelijks schrijfvolume daarna komt.
Wil je dit liever niet zelf in elkaar knutselen, dan doet Voicr het standaard op macOS. Houd FN ingedrukt in elke app, spreek natuurlijk, en de regel voor die app polijst je woorden onderweg naar het klembord. Slack-berichten komen er informeel uit, e-mails zakelijk, code-commentaar beknopt — en je hoefde over niets ervan na te denken. Dat is het doel: schrijven dat past bij de ruimte, zonder dat je het zelf hoeft te herschrijven.