Email Generering & Skrivning

Email generering dækker den situation, hvor du bruger en sprogmodel til at producere en færdig eller næsten færdig email ud fra en instruktion, en skabelon eller en indgående besked. Det spænder fra et enkelt svar på en kundehenvendelse til udsendelser, hvor samme grundtekst tilpasses tusindvis af modtagere. Fælles for opgaverne er, at outputtet er kort, har en modtager og skal kunne sendes uden større omskrivning.

Grænsen mod almindelig tekstgenerering går ved formatet og forventningen. En email har en afsender med en identitet, en modtager med en relation og et formål, der ofte er en handling. Det stiller andre krav end en artikel eller et produktresumé.

Use-casen adskiller sig også fra egentlig kundeservice-automatisering. Så snart modellen svarer direkte til kunden uden et menneske imellem, og skal slå op i ordredata eller policies, er du i gang med en agent eller et RAG-setup. Her handler det om udkast, som et menneske godkender.

Den simpleste opsætning er en prompt med tre dele: en systeminstruktion der beskriver afsender, tone og formatkrav, en beskrivelse af modtageren og situationen, og selve opgaven. Modellen får det hele i sit context window og returnerer en emailtekst. For lave volumener kan det klares i et chatinterface uden nogen form for integration.

I produktion lægger du typisk et lag omkring. En skabelon med placeholders fyldes med data fra CRM eller supportsystemet, prompten samles programmatisk, og outputtet sendes til et review-trin før afsendelse. Ved svar på indgående mails indgår den oprindelige besked som kontekst, ofte sammen med tidligere korrespondance i tråden.

Kvaliteten afhænger mest af, hvor konkret konteksten er. En instruktion om at være "professionel og venlig" giver generisk tekst, mens tre eksempler på tidligere sendte mails giver noget genkendeligt. Modelvalget betyder mindre end de fleste tror: Claude Haiku 4.5 og GPT-5 nano klarer rutinesvar til en brøkdel af prisen, mens GPT-5.6 Sol eller Claude Sonnet 5 giver mærkbart bedre resultater på lange tråde og forhandlingstunge emails.

Det hyppigste problem er, at teksten er korrekt og alligevel ubrugelig. Modellen skriver høfligt, velstruktureret og fuldstændig intetsigende, fordi den mangler det, der gør mailen relevant. En sælger, der kender kundens sidste indvending, skriver tre linjer, som modellen ikke kan gætte sig til.

Hallucination er et reelt problem i emails, netop fordi teksten virker troværdig. Modellen opfinder gerne et mødetidspunkt, en leveringsdato eller en rabat, hvis prompten antyder, at der bør stå noget. Det opdages ikke ved hurtig gennemlæsning, fordi det ligner præcis det, der plejer at stå.

Skalering forstærker fejlene. Én dårlig mail er pinlig, femtusind identiske mails med samme fejlagtige påstand er en anden sag. Volumen kræver stikprøvekontrol og en klar afgrænsning af, hvilke oplysninger modellen overhovedet må formulere selvstændigt.

Endelig er der datahåndteringen. Kundemails indeholder navne, ordrenumre og somme tider helbreds- eller økonomioplysninger. Sender du dem videre til en model, skal du vide hvor de behandles, hvor længe de gemmes, og om databehandleraftalen dækker.

Korte, standardiserede mails er sjældent værd at automatisere. En bekræftelse på fem linjer skrives hurtigere end en god prompt, og en klassisk skabelon uden model er både billigere og mere forudsigelig.

Mails med reelle konsekvenser hører heller ikke hjemme her. Opsigelser, klagesvar, prisforhandlinger og alt med juridisk vægt bør skrives af et menneske, eventuelt med modellen som sparringspartner på formuleringer. Gevinsten ligger i mellemlaget: mails der er for individuelle til en skabelon, men ikke vigtige nok til at fortjene tyve minutter.