Kundeservice prompts

Skriv et svar på følgende besked fra en kunde hos [virksomhed]: [kundens besked].

Kontekst: Problemet skyldes [oprindelse: vores fejl, en leverandør, en misforståelse, kunden selv]. Det vi kan tilbyde: [mulige løsninger: tilbagebetaling, tilgodebevis, ombytning, kommerciel kompensation]. Det vi ikke kan gøre: [begrænsninger].

Struktur: Anerkend det specifikke problem (omformuler kundens ord, brug ikke standardsætninger), forklaring kort hvad der skete uden at fralægge os ansvaret eller skyde skylden på en kollega, annoncer den konkrete løsning og tidshorisonten, og fortæl hvad vi gør for at det ikke sker igen, hvis det er relevant.

Tone: Menneskelig og direkte. Forbudt: "Vi beklager ulejligheden", brug af passiv form ("det burde være sket"), gentagne undskyldninger, eller løfter om noget der ikke står i [mulige løsninger].

Opret en base med 10 svar-makroer til supporten hos [virksomhed], der sælger [produkt eller ydelse] til [kundetype]. Vores kanaler: [kanaler: e-mail, chat, telefon]. Vores hyppigste kontaktårsager: [årsager, f.eks. ordrestatus, login-problemer, anmodning om refundering, spørgsmål til faktura].

For hver makro: Eksplicit internt navn, præcis brugssituation, komplet tekst med felter til personalisering i parentes ([fornavn], [ordrenummer], [frist]...), og betingelsen for hvornår man skal forlade makroen til fordel for et personligt svar.

Krav: Hver makro skal svare fuldstændigt på henvendelsen (ingen "vi vender tilbage" uden en dato), tonen skal matche vores stil [stil: du/De, formel/uformel], og der skal være en kort version til chat, hvis kanalen kræver det.

Vi har et aktuelt driftsproblem hos [virksomhed]: [hændelsens art, f.eks. systemet er nede, generelle leveringsforsinkelser, faktureringsfejl]. Effekt: [hvem er ramt og hvordan]. Årsag: [kendt / undersøges]. Forventet normal drift: [estimat eller ukendt].

Skriv den komplette sekvens: Første annoncering (sendes inden for en time: hvad sker der, hvem er berørt, hvad gør vi, hvornår kommer der nyt: uden at gætte på årsagen), statusopdatering (genanvendelig struktur hver [frekvens]), besked om løsning (hvad er rettet, eventuel kompensation: [planlagt kompensation]), og en besked efter hændelsen til de kunder, der har åbnet en sag.

Regler: Minimer aldrig problemet ("små forsinkelser" hvis alt er nede), angiv tidspunkt for næste opdatering selv uden ny info, én stemme på tværs af kanaler. Lav den første annoncering i 3 formater: E-mail, banner til hjemmesiden (1 sætning), og standardsvar til supportteamet.

En kunde hos [virksomhed] beder om [kundens ønske, f.eks. refundering efter fristen, en funktion vi ikke har, en ekstraordinær rabat]. Vi må sige nej, fordi [reel årsag til afslag]. Kundens værdi: [kontekst: anciennitet, omsætning, historik]. Muligt alternativ: [alternativ eller intet].

Skriv svaret: Bekræft modtagelse af anmodningen og vis at den er forstået, giv et klart afslag allerede i andet afsnit (gem ikke nej'et bag omsvøb), giv den reelle årsag i enkle vendinger (en regel der gælder for alle er lettere at forsvare end en dårlig undskyldning), foreslå alternativet hvis det findes uden at oversalge det, og lad døren stå på klem.

Tone: Fast og respektfuld. Forbudt: Brug af ordet "desværre" mere end én gang, falske forhåbninger ("vi vil undersøge det"), eller henvisning til en anden afdeling uden opfølgning. Tilføj en variant til hvis kunden truer med at skifte til [konkurrent].

Analyser kontaktårsagerne hos supporten for [virksomhed] for at identificere, hvad der kan reduceres ved kilden. Data: [eksport eller resumé af sager: årsager, volumen, behandlingstid, kanal, periode]. Supportteamets størrelse: [antal medarbejdere]. Vores nuværende dokumentation: [status på FAQ / hjælpecenter].

Udform: En prioritering af årsager efter volumen og omkostning (volumen × behandlingstid). For hver af de top 5 årsager skal du angive den sandsynlige rodårsag og en passende handling: Produktrettelse, tydeliggørelse af kunderejsen eller bekræftelsesmail, hjælpeartikel, eller proaktiv besked på det rette tidspunkt.

For handlingen "hjælpeartikel": Skriv overskrifterne til artiklen. For handlingen "proaktiv besked": Skriv selve beskeden. Afslut med et estimat over andelen af undgåelige sager og de 3 vigtigste handlinger for denne uge. Gør opmærksom på, hvad dataene ikke giver svar på.

Skriv det offentlige svar fra [virksomhed] på denne negative anmeldelse på [platform: Google, Trustpilot, App Store]: [anmeldelsens tekst].

Intern kontekst: Hvad skete der reelt: [intern version af fakta]. Det vi kan tilbyde: [mulig løsning eller intet].

Regler: Svaret er rettet lige så meget mod de hundreder af fremtidige læsere som mod anmelderen. Anerkend det valide punkt uden at indrømme fejl, der ikke er fastslået. Gå aldrig til modangreb og drag ikke kundens gode tro i tvivl offentligt. Foreslå at fortsætte dialogen privat via en specifik kanal ([e-mail eller telefonnummer]) uden at det ligner en flugt. Ingen personhenførbare data om kunden i svaret.

Begrænsninger: Maksimalt 120 ord, underskrevet med fornavn og titel. Lav også en variant til hvis anmeldelsen indeholder faktuelle fejl: Ret dem sagligt uden at kalde kunden en løgner.

Opret 5 modeller til svar på positive anmeldelser for [virksomhed], der sælger [produkt eller ydelse]. Platforme: [platforme]. Vores tone: [stil: saglig, varm, du/De].

Hver model skal svare til en type anmeldelse: En detaljeret anmeldelse der nævner noget specifikt, en kort anmeldelse som "meget godt", en anmeldelse der nævner en medarbejder ved navn, en positiv anmeldelse der dog indeholder en lille kritik, og en anmeldelse fra en loyal kunde der vender tilbage.

Regler: Inddrag et konkret element fra anmeldelsen for at bevise, at et menneske har læst den (feltet [citeret element] skal tilpasses), tak uden at være underdanig, indbyg aldrig salgsargumenter i svaret, og adresser kritikken i den blandede anmeldelse i stedet for at ignorere den. Maksimalt 50 ord pr. svar.

Output-format: De 5 modeller med felter i parentes, samt en intern regel for hvilke anmeldelser der skal besvares inden for 24 timer, og hvilke der kan vente.

Du er træner i håndtering af svære kunderelationer. En kunde hos [virksomhed] er aggressiv på [kanal: telefon, e-mail, chat]: [resumé af situationen og tonen]. Kernen i anmodningen: [ønske]. Hvad vi kan gøre: [råderum].

Giv mig metoden til deeskalering i 4 trin: Lad kunden tale ud uden at afbryde eller retfærdiggøre for tidligt, valider følelsen uden at validere anklagerne (præcise formuleringer), fokusér på det der kan løses, og lås en aftale med en dato.

Skriv ord-for-ord formuleringer til: At afbryde en monolog der kører i ring på en høflig måde, svare på et personligt angreb mod medarbejderen, nægte at fortsætte hvis fornærmelserne fortsætter (2 advarsler og derefter afslutning, formulering af hvert trin), og genoptage samtalen senere når der er faldet ro på.

Præcisér hvad der ændrer sig mellem telefon og skrift, og hvornår medarbejderen skal give sagen videre til sin leder.

En kunde hos [virksomhed] truer med at [trussel: kontakte advokat, gå til Forbrugerklagenævnet, kontakte pressen, starte en sag]. Tvisten handler om [emne, beløb]. Historik: [resumé af dialogen].

Hjælp supporten med at håndtere denne besked uden at lege jurist: Skriv det midlertidige svar, der bekræfter modtagelse, forbliver sagligt og høfligt, ikke indrømmer fejl, ikke bestrider kundens ret til at handle, og annoncerer en præcis tidsfrist for et fuldstændigt svar.

Tilføj: En intern tjekliste før besvarelse (stop sletning af data relateret til sagen, saml tidslinje og dokumentation, underret [ansvarlig]), de 3 formuleringer man absolut skal undgå i denne kontekst (alt hvad der anerkender ansvar eller lover et resultat), og det enkle kriterium for hvornår sagen skal overdrages til ledelsen eller virksomhedens juridiske rådgiver i stedet for at fortsætte i supporten. Giv ingen juridisk rådgivning om selve sagen.

Skriv svar på anmodninger om refundering for [virksomhed], der sælger [produkt eller ydelse]. Vores politik: [regler for refundering: frister, betingelser, undtagelser]. Modtaget anmodning: [kundens besked og årsag].

Lav 3 versioner: Godkendt refundering (bekræft præcist beløb, betalingsmetode, reel tidsfrist i bankdage, og hvad kunden skal gøre hvis pengene ikke dukker op), delvis refundering eller tilgodebevis (forklar beregningen uden regnskabsjargon, præsenter tilgodebeviset uden at lade som om det er en gave), afslag (reglen der gælder, hvorfor den findes, og hvad der stadig er muligt).

Fælles regler: Annoncer beslutningen i de første 2 linjer, ingen uklar fremtidsform ("bør blive refunderet"), og undgå gentagne "ekstraordinære løsninger", der udvander politikken. Format: De 3 komplette e-mails med felter i parentes, samt den interne note der skal gemmes på sagen i hvert tilfælde.

Du er kundeservicechef hos [virksomhed] ([produkt eller ydelse], gennemsnitlig ordreværdi [beløb], vejledende avance [niveau]). Medarbejderne giver i dag kompensation efter mavefornemmelse uden sammenhæng.

Opbyg det interne skema for kommerciel kompensation: De 5 til 8 typiske situationer ([hyppige situationer: forsinkelse, produktfejl, vores fejl, subjektiv skuffelse, utilfreds loyal kunde]), og for hver situation: Standardkompensation, maksimum uden godkendelse, og grænsen for hvornår en leder skal ind over.

Principper der skal overholdes: Kompensationen dækker det reelle tab, den køber ikke tavshed. En kunde der råber højt skal ikke have mere end en høflig kunde i samme situation. Tilgodebevis foreslås før refundering, når det er legitimt, men aldrig som en fælde.

Format: Tabel med situation / standard / maksimum / eskalering, formuleringer til at annoncere hver kompensation uden at oversalge den, og 3 månedlige nøgletal for at kontrollere at skemaet følges.

En kunde hos [virksomhed] gør indsigelse mod sin fakturering: [problemets art: dobbelt trækning, forkert beløb, faktureret efter opsigelse, rabat ikke fratrukket]. Intern kontrol: [hvad viser vores system: bekræftet fejl, delvis fejl, korrekt fakturering men misforstået].

Skriv svaret baseret på kontrollen. Hvis fejlen er bekræftet: Anerkend det uden omsvøb, angiv det præcise beløb der refunderes, tidsfristen i bankdage, og hvad der er rettet for at undgå gentagelser. Hvis faktureringen er korrekt: Forklar pædagogisk linje for linje hvor beløbet kommer fra, uden at få kunden til at føle sig dum, og vis hvor de selv kan finde disse detaljer næste gang.

Begrænsninger: Ingen faktureringsjargon ([eksempler på interne termer der skal undgås]), kun præcise tal, aldrig "trækningen vil snart fremgå" uden en dato. Tilføj en kort version til chat og den interne note.

Lav standardsvar for [virksomhed] til leveringsforsinkelser. Vores leveringsløfte: [annonceret frist]. Transportører: [transportører]. Hvad vi kan gøre: [muligheder: genforsendelse, refundering af fragt, kompensation, undersøgelse hos transportør og dens varighed].

Lav 4 svar baseret på situationen: Lille forsinkelse på få dage hvor tracking stadig opdateres, tracking har stået stille i [varighed], pakke markeret som leveret men ikke modtaget (tjekliste til kunden: naboer, pakkeshop, uden at mistænkeliggøre dem), pakke formodentlig bortkommet (igangsæt genforsendelse eller refundering uden at vente på transportørens undersøgelse, hvis vores politik tillader det).

Regler: Skyd aldrig skylden 100% på transportøren (det er os kunden har betalt), giv altid en ny dato for hvornår vi vender tilbage. Format: De 4 e-mails med felter i parentes.

En kunde hos [virksomhed] melder om et defekt eller forkert produkt: [beskrivelse af problemet]. Produkt: [produkt, pris]. Vores proces: [muligheder: returlabel, direkte ombytning, refundering, reparation; hvem betaler fragt].

Skriv det første svar: Kort og oprigtig empati (én sætning, ikke tre), de 2 eller 3 spørgsmål eller billeder der er nødvendige for diagnosen (kun det strengt nødvendige, hver dialogrunde koster tid), og en klar udmelding om de mulige løsninger afhængig af diagnosen, så kunden ved hvad de kan forvente.

Skriv derefter løsningssvaret når fejlen er bekræftet: Den valgte løsning, de konkrete trin for kunden (nummereret, med vedhæftet returlabel), og tidsfristen for hvert trin.

Regler: Bed aldrig kunden om at bevise sin gode tro ud over det rimelige, lad ikke kunden bære omkostningen for vores fejl. Felter i parentes, 2 komplette e-mails.

Lav standardsvar til "hvor er min ordre" for [virksomhed]. Vores ordreflow: [trin: bekræftelse, plukning, afsendelse, levering, med tidsfrister for hver]. Værktøjer: [hvad medarbejderen ser i back-office].

Lav et svar for hvert trin i flowet, som hver især fortæller: Præcis hvor ordren er, hvad der sker næste gang, og hvornår der sker noget synligt for kunden. Forbudt: At kopiere transportørens rå status ("ankommet til hub") uden at oversætte den, og svar der intet nyt fortæller ("din ordre er under behandling").

Tilføj: Svaret til en ordre som medarbejderen kan se er gået i stå internt ([hyppige årsager: restordre, betalingstjek, mangelfuld adresse]): Fortæl sandheden om årsagen, giv en realistisk tidsfrist, og giv en udvej (ændre eller annullere). Format: Komplette svar med felter i parentes, versioner til e-mail og chat.

Du er kvalitetsansvarlig for en kundesupport. Vores medarbejdere hos [virksomhed] stiller spørgsmål drypvis: Hver sag tager 3 dialogrunder i stedet for én. Relevante emner: [emner, f.eks. teknisk fejl, mangelfuld sag, transportreklamation].

For hvert af disse emner skal du opbygge den ideelle besked til indhentning af info: Alle nødvendige spørgsmål samlet på én gang, nummereret, formuleret til at få præcise svar (lukkede spørgsmål eller valgmuligheder frem for "kan du fortælle mere"), med en linje for hvert spørgsmål der forklarer, hvorfor vi har brug for det, hvis det ikke er indlysende.

Regler: Maksimalt 5 spørgsmål pr. besked, spørg aldrig om info der allerede findes i sagen eller på kundeprofilen (største årsag til irritation), angiv hvad der sker så snart svarene er modtaget. Format: Én besked pr. emne med felter i parentes, plus en intern tjekliste "har jeg spurgt om alt?" pr. emne.

Skriv opfølgningssekvensen for [virksomhed] til en kunde, der har åbnet en sag og derefter ikke svarer. Kontekst: [årsag]; vi venter på: [forventet info eller handling]; tavshed i [varighed].

Lav 3 beskeder. Opfølgning 1 (efter [frist 1]): Kort påmindelse om hvad vi venter på, hvor indsatsen minimeres (omformuler spørgsmålet til én linje, foreslå svarmuligheder hvis muligt). Opfølgning 2 (efter [frist 2]): Gør opmærksom på at sagen lukkes uden svar inden [dato], men præcisér at intet er tabt og hvordan den genåbnes. Lukningsbesked: Luk høfligt, opsummer hvor sagen stod, og giv den nemmeste måde at genoptage den på.

Regler: Ingen skyldfølelse ("da vi ikke har hørt fra dig..." i en bebrejdende tone), frister tilpasset sagens alvor (forskellige frister for en kritisk fejl og et spørgsmål om præferencer). Felter i parentes.

Lav beskeder til lukning af sager for supporten hos [virksomhed]. Vores værktøj: [ticketing-system]. Tilfredshedsundersøgelse sendt ved lukning: [ja/nej, hvilken].

Lav 4 beskeder: Lukning efter bekræftet løsning fra kunden (opsummer løsningen på 2 linjer til fremtidig brug), lukning efter formodet løsning uden bekræftelse (formulering der ikke påstår det er løst, men at vi lukker pga. manglende feedback, med nem genåbning), lukning af en dublet-sag (henvis til hovedsagen), lukning af en forespørgsel uden for vores område (sig det klart, henvis til [alternativ] hvis det findes).

Regler: Brug aldrig "tøv ikke med at kontakte os" som en tom floskel: Giv et link eller en specifik metode til at genåbne netop DENNE sag uden at forklare alt forfra. Beskeden skal være forståelig, hvis den læses 6 måneder senere. Felter i parentes, versioner til e-mail og chat.

En kunde hos [virksomhed] beder om en funktion, som vores produkt ikke har: [ønske]. Reel intern status: [status: planlagt til X kvartal, under overvejelse uden løfte, bevidst fravalgt, aldrig vurderet]. Eksisterende workaround: [workaround eller ingen].

Skriv svaret tilpasset den reelle status. Hvis planlagt: Angiv tidshorisont uden at love en fast dato, tilbyd at give besked ved lancering. Hvis under overvejelse: Sig ærligt at der ikke er taget beslutning, forklar hvordan kundeønsker påvirker vores valg. Hvis fravalgt: Giv den reelle årsag i enkle vendinger (produktvalg, ikke ligegyldighed) og forklar workarounden hvis den findes. Hvis aldrig vurderet: Tak for input, registrer det, uden falske forhåbninger.

Regler: Lad ALDRIG som om "det kommer snart" for at få fred, tak for det præcise input, registrer ønsket i [system] med de præcise ord. Lav de 4 komplette varianter og den interne registreringslinje.

Her er den tekniske diagnose fra vores team til en kundesag hos [virksomhed]: [rå teknisk diagnose]. Kunden: [profil, f.eks. butiksejer uden teknisk indsigt, privatperson, avanceret bruger]. Oprindeligt spørgsmål: [kundens spørgsmål].

Oversæt denne diagnose til et kundesvar: Start med den konkrete konsekvens for kunden (hvad virker, hvad virker ikke, hvad skal de gøre), forklar årsagen med en hverdagssammenligning hvis det virkelig hjælper (ellers lad være), giv de nummererede trin til løsning med estimeret tid for hvert.

Regler: Ingen nedladende toner ("det er meget enkelt" er forbudt, hvis det ikke er det for dem), ingen tekniske termer uden umiddelbar forklaring i parentes, forenkl ikke så meget at det bliver forkert: Gør mig opmærksom på, hvis en forenkling ofrer præcision. Format: Det komplette svar, derefter listen over tekniske termer du har oversat og hvordan.

Skriv en artikel til hjælpecenteret for [virksomhed] om emnet: [emne, f.eks. skift adgangskode, returnering af produkt, forstå din første faktura]. Kilde: [medarbejdernes standardsvar eller intern procedure]. Læsere: [kundeprofil].

Struktur: En titel formuleret som kunden ville søge (ikke som vi taler internt), svaret på spørgsmålet inden for de første 3 linjer til dem der har travlt, derefter detaljerede nummererede trin (én handling pr. trin, med info om hvor man skal klikke og hvad man skal se), sektionen "virkede det ikke?" med de 2 eller 3 hyppigste fejl og deres løsninger, og en vej videre til supporten med info om hvad man skal oplyse for at få hurtig hjælp.

Regler: Ingen antagede screenshots (angiv hvor de skal indsættes med [billede: beskrivelse]), brug kundens sprog og ikke internt sprog ([interne termer der skal undgås]), korte sætninger, ingen "du skal bare". Giv også 3 varianter af titlen til søgemaskiner.

Opbyg en FAQ for [produkt eller ydelse] hos [virksomhed]. Råmateriale: [spørgsmål modtaget af supporten, kunde-mails, salgsindsigelser]. Kunderejse: [trin: før køb, bestilling, brug, fakturering, opsigelse].

Udform: En liste med 15 til 20 udvalgte spørgsmål, formuleret som kunderne stiller dem (behold deres sprog), sorteret efter trin i rejsen, med et komplet men kort svar til hver (maksimalt 80 ord, præcise tal når de findes: frister, beløb, betingelser: [data der skal integreres]).

Regler: Et reelt svar pr. spørgsmål (aldrig "kontakt support" som eneste svar), vær ærlig om de svære svar (gebyrer, ventetider, produktbegrænsninger) frem for at udelade dem: En FAQ der undviger skaber flere sager. Marker de spørgsmål hvor svaret kræver at jeg opfinder info: List dem til sidst som "skal udfyldes". Format: FAQ organiseret i sektioner, klar til udgivelse.

Du er ansvarlig for kundeoplevelsen. Strukturér hjælpecenteret for [virksomhed] ([produkt eller ydelse], kundetype [kundetype]). Eksisterende: [nuværende status: intet, en rodet FAQ, spredte artikler]. Vigtigste kontaktårsager: [årsager efter volumen].

Udform den komplette arkitektur: 5 til 7 kategorier navngivet efter kundens hensigt ("Min ordre", "Betaling og refundering"...) og aldrig efter interne afdelinger. For hver kategori: Liste over artikler der skal oprettes, prioriteret efter volumen af undgåelige sager, det passende format (step-by-step, tabel over frister, kort video) og en søgeoptimeret titel.

Tilføj: De 5 artikler der skal skrives først med begrundelse, regler for vedligeholdelse (hvem læser korrektur, hvor ofte, hvad trigger en opdatering når produktet ændres), og placering af kontaktpunkter til menneskelig support (synlige uden at ødelægge selvbetjeningen). Format: Indrykket arkitektur + handlingsplan.

Skriv scenarierne til support-chatbotten hos [virksomhed]. Henvendelser der skal dækkes: [3 til 5 simple og hyppige årsager, f.eks. ordrestatus, åbningstider, returprocedure]. Hvad botten teknisk kan: [evner: læse ordrestatus, oprette en sag, give links]. Menneskelig eskalering: [medarbejdernes tilgængelighed].

For hver årsag skal du skrive det komplette dialogtræ: Velkomstbesked for flowet, spørgsmål fra botten med klikbare valgmuligheder (2 til 4 muligheder, aldrig åbne spørgsmål når et valg er nok), endelige svar, og punktet for overdragelse til et menneske.

Ikke-forhandlebare regler: Botten præsenterer sig som en bot (aldrig et falsk menneskenavn), udgangen til en medarbejder skal være tilgængelig i hvert trin, botten sender alt hvad kunden allerede har sagt videre til medarbejderen (kunden gentager ALDRIG sig selv), ved 2. fejl i forståelsen tilbydes et menneske. Format: Et træ pr. årsag med de skrevne replikker.

Lav modeller til live-chat hos [virksomhed] ([produkt eller ydelse], tone [stil]). Situationer der skal dækkes: Velkomst og modtagelse, anmodning om tålmodighed mens medarbejderen undersøger noget (med angivet tid, ikke bare "et øjeblik" der varer 8 minutter), anmodning om info, annoncering af løsning, overdragelse til en kollega (med forklaring og kontekst), afslutning med resumé, besked ved fravær uden for åbningstid med alternativer.

Begrænsninger for chat: Maksimalt 2 sætninger pr. besked, én information pr. besked frem for en tekstblok, giv besked før hver pause på over 2 minutter, ingen falsk øjeblikkelighed ("jeg kigger på det med det samme" efterfulgt af 10 minutters tomhed).

For hver model: Teksten med felter i parentes, den præcise brugssituation og den klassiske fejl den undgår. Tilføj reglen for skift: De 3 tegn på at man bør foreslå et opkald frem for at fortsætte skriftligt.

En kunde henvender sig offentligt til [virksomhed] på [medie: X, Instagram, Facebook, LinkedIn]: [indhold af den offentlige besked]. Intern kontekst: [hvad vi ved om sagen]. Synlighed: [rækkevidde: få visninger, ved at sprede sig, influencer].

Skriv: Det offentlige svar (maksimalt 2 sætninger: Anerkend, vis at der er taget hånd om det, inviter til privat dialog uden at det ligner censur; offentligheden dømmer virksomheden på dette svar, ikke på den oprindelige fejl), den første private besked der samler op på sagen uden at kunden skal gentage sig, og det offentlige svar til afslutning når problemet er løst, hvis tråden stadig er synlig.

Regler: Svar hurtigt selv uden en løsning (bekræftelse af modtagelse skrives uden at kende sagens kerne), aldrig detaljer om sagen offentligt (personhenførbare data), aldrig en defensiv eller ironisk tone selvom kunden er urimelig, slet ikke kommentaren medmindre den er decideret injurierende. Tilføj kriteriet for intern eskalering: Hvornår skal denne tråd sendes til [ansvarlig].

Du er supportchef hos [virksomhed] ([produkt eller ydelse], [volumen] sager pr. [periode], team på [antal]). I dag behandles sagerne i den rækkefølge de kommer ind, og reelle hastesager venter bag mindre vigtige forespørgsler.

Opbyg vores prioriteringssystem: 3 eller 4 prioritetsniveauer defineret ud fra den reelle påvirkning for kunden (blokeret i sin aktivitet, udfordret med en workaround, spørgsmål uden hast), med konkrete eksempler for hvert niveau baseret på vores årsager ([hyppige årsager]), målsætning for første svar og løsning, og reglen for afvejning når alt virker vigtigt.

Tilføj: Kriterier der opgraderer en sag (kunde i en kritisk periode [kontekst, f.eks. bryllup, flytning, regnskabsafslutning], gentagelse af samme problem, overskredet aftale fra vores side), og hvad der IKKE opgraderer en sag (kunden der råber højest, ordrestørrelsen alene). Testen på 10 sekunder: En medarbejder skal kunne prioritere uden at tænke sig om. Format: Skema + 10 eksempler på sager, prioriteret og begrundet.

Hjælp mig med at fastlægge svartider (SLA) for supporten hos [virksomhed]. Situation: [volumen af sager pr. kanal og periode], bemanding [antal og åbningstider], nuværende svartider [nuværende tider hvis kendt]. Kundernes forventning: [konkurrencesituation eller nuværende løfte].

Foreslå: SLA for første svar og løsning pr. kanal (e-mail, chat, telefon, sociale medier) og pr. prioritetsniveau, i overensstemmelse med vores reelle bemanding: Sig det ærligt, hvis en ambition er umulig at nå med de beskrevne midler, og hvad der skal til for at nå den.

Skel mellem: Intern SLA (teammål) og det løfte vi giver kunderne (altid mere forsigtigt end det interne), og det første REELLE svar (en reel behandling, ikke bare en automatisk bekræftelse der snyder uret). Tilføj: Måling (hvilke tal, hvordan tælles åbningstider), ugentlig opfølgning, og proceduren når en SLA er ved at blive overskredet: Giv kunden besked før fristen, ikke efter. Format: Tabel over SLA + regler for anvendelse.

En sag hos [virksomhed] har ligget i [varighed] uden svar, hvilket er over vores standard ([normal svartid]). Reel årsag: [årsag: spidsbelastning, sag tabt ved overdragelse, menneskelig fejl]. Kundens forespørgsel: [oprindelig forespørgsel].

Skriv svaret til genoptagelse: Undskyldningen i ÉN sætning, oprigtig og uden drama (kunden vil have sit svar, ikke vores selvmedlidenhed), en ærlig forklaring i én sætning hvis den findes (uden at udlevere interne processer eller kolleger), og så ØJEBLIKKELIGT det fuldstændige svar på den oprindelige forespørgsel: Det er svaret der gør det godt igen, ikke undskyldningen. Hvis et komplet svar endnu ikke er muligt: Hvad der er gjort, hvad der mangler, og en fast dato for næste opdatering.

Tilføj: Eventuel kompensation hvis forsinkelsen har medført et reelt tab ([kompensationspolitik]), varianten når kunden har rykket flere gange med irritation, og varianten når forsinkelsen skyldes info VI ventede på fra dem, men som var dårligt formuleret. Maksimalt 120 ord pr. version.

Lav en skabelon til overdragelse af sager fra niveau 1 til niveau 2 (eller [teknisk team]) hos [virksomhed]. Nuværende problem: Eskalerede sager sendes videre med spørgsmål der allerede er stillet til kunden, og N2 spilder tid på at stykke historikken sammen.

Skabelonen skal indeholde: Resumé af problemet på 2 linjer (observeret symptom, ikke fortolkning), kundepåvirkning (blokeret eller ej, siden hvornår, hyppighed), miljø og referencer ([relevante felter: ordrenummer, version, browser, konto-ID]), hvad der allerede er forsøgt med resultatet af hvert forsøg, hvad kunden allerede har indsendt (bilag, screenshots), det præcise spørgsmål til N2 (en eskalering uden spørgsmål er bare at skubbe ansvaret), og det løfte der er givet til kunden (forventet tid).

Tilføj: De 3 objektive kriterier der retfærdiggør eskalering (og 2 tilfælde der ikke gør), beskeden til kunden om overdragelsen uden internt jargon, og reglen om ejerskab: Hvem svarer kunden under eskaleringen. Format: Skabelon med felter + udfyldt eksempel.

Dokumentér den interne refunderingsprocedure for supportmedarbejderne hos [virksomhed]. Værktøjer: [værktøjer: betalingsplatform, back-office, ticketing-system]. Kommerciel politik: [regler for berettigelse og beløbsgrænser pr. medarbejderprofil].

Skriv den komplette trin-for-trin guide: Forudgående kontrol (berettigelse jf. politik, er der allerede refunderet på denne ordre, er den oprindelige betalingsmetode stadig gyldig), indtastning i [værktøj] trin for trin, det præcise beløb (kun produkt, fragt, delvis betaling med tilgodebevis eller gavekort), beskeden til kunden med realistisk banktid pr. betalingsmetode, og dokumentation (hvad skal gemmes på sagen: beløb, årsag, godkendelse).

Tilføj: De 4 specialtilfælde der driller mest ([hyppige tilfælde, f.eks. udløbet kort, delvis returnering, afbetaling]) med deres håndtering, og tabellen over godkendelsesgrænser pr. medarbejderniveau. Format: Nummereret procedure, "OBS" bokse om fælder, og en afsluttende tjekliste.

Opbyg et evalueringsskema for svarkvalitet hos supporten for [virksomhed] ([kanaler], tone [stil]). Brug: Gennemgang af [antal, f.eks. 5 sager pr. medarbejder pr. måned] af [hvem gennemgår].

Kriterier bygget op omkring det der betyder noget for kunden: Er forespørgslen reelt forstået (ikke et svar ved siden af), komplet svar i første forsøg (alle kundens spørgsmål adresseret), korrekthed af info, klarhed (forståeligt for den specifikke kunde), tonen i overensstemmelse med vores stil uden at lyde som en robot, en dato for opfølgning hvis sagen ikke løses med det samme, og korrekt registrering af sagen.

For hvert kriterium: Begrundet vægtning, karakterskala med beskrivelse af hvert niveau, eksempel på godt og dårligt. Regler for brug: Skemaet skal bruges til udvikling, ikke sanktionering. Enhver afvigelse skal kunne påvises i sagen. Format: Skema + en sides guide til den der gennemgår.

Forbered min månedlige kvalitetsdebriefing med [navn], supportmedarbejder hos [virksomhed] siden [anciennetet]. Materiale: [resultater fra månedens kvalitetsskema: observerede styrker, konstaterede afvigelser med sagsnumre]. Eventuel kontekst: [kontekst: travlhed, nye opgaver, svær periode].

Strukturér den 30-minutters samtale: Deres egen evaluering først (præcise spørgsmål til at starte dem), styrkerne med eksempler fra specifikke sager (lige så veldokumenterede som afvigelserne: generel ros er intet værd), derefter ÉT prioriteret udviklingspunkt (ikke fem) illustreret med 2 sager. Find årsagen sammen med dem (mangel på info, uklar procedure, vane) før du foreslår en løsning. Aftal en konkret handling med en deadline, og hvad JEG forpligter mig til at rette, hvis årsagen er mangelfulde værktøjer eller dokumentation.

Skriv formuleringer til de svære passager: En gentagen afvigelse trods tidligere debriefing, en medarbejder der er uenig i vurderingen. Tone: Direkte og anerkendende, aldrig nedladende.

Opbyg træningsforløbet for en ny supportmedarbejder hos [virksomhed] ([produkt eller ydelse], kanaler [kanaler], værktøjer [værktøjer]). Mål for fuld selvstændighed: [varighed]. Tilgængelig træner: [hvem træner og hvor lang tid pr. dag].

Opdel pr. uge: Uge 1, lær produktet at kende som kunde (brug det reelt, læg en ordre, oplev problemerne) og observer medarbejdere (medlyt); uge 2, besvar simple henvendelser ([simple årsager]) med 100% korrektur af alle svar før afsendelse; uge 3, udvid til komplekse årsager med stikprøvekontrol; uge 4, overvåget selvstændighed og hjælp til de første følsomme sager.

For hver uge: Observerbare mål, konkrete øvelser (inkl. svar på anonymiserede reelle sager), kriteriet for at gå videre til næste uge, og statusmøde med træneren. Tilføj listen over 10 ting man skal vide før slutningen ([virksomhedsspecifikke ting]) og formatet for en afsluttende quiz. Format: Ugeplan + tjekliste til godkendelse.

Skriv en tone-of-voice guide til kundesupporten hos [virksomhed] ([produkt eller ydelse], kundetype [kundetype], brandpositionering [positionering]). I dag skriver hver medarbejder på sin egen måde, fra meget kortfattet til for uformelt.

Udform: De 4 eller 5 principper for vores stemme (hver i én sætning, med hvad det indebærer OG dens grænse: "varm" uden overdreven brug af smileys, "direkte" uden at være kort for hovedet), de endelige valg (du eller De alt efter [kontekst], emojis, udråbstegn, humor og dens forbud, hvordan vi omtaler os selv: "jeg" eller "vi"), ordliste (virksomhedsord der skal bruges, interne termer der er forbudt med deres kunde-oversættelse), og 6 før/efter eksempler på vores reelle situationer: Annoncering af ventetid, afslag, undskyldning, gode nyheder, vred kunde, teknisk spørgsmål.

Gylden regel der skal med: Guiden sætter rammen for tonen, aldrig for indholdet. En medarbejder skal kunne afvige fra den, når menneskelighed kræver det, og vi dokumenterer disse tilfælde. Format: Maksimalt 2 siders guide, klar til brug i morgen.

Lav tilfredshedsundersøgelsen til efter en sag for [virksomhed] ([supportkanaler], værktøj: [værktøj]). Mål: Måle supportkvaliteten OG indsamle brugbar viden uden at trætte kunden.

Udform: Tidspunkt for afsendelse (efter lukning, med relevant forsinkelse alt efter årsag: øjeblikkeligt ved simple spørgsmål, senere hvis løsningen skal testes af kunden), det primære tilfredshedsspørgsmål med skala (begrund valget af skala og hold fast i den: ændringer ødelægger historikken), ÉT velformuleret åbent spørgsmål ("hvad kunne vi have gjort bedre?" frem for "kommentarer?"), og et betinget spørgsmål hvis karakteren er lav (tilbyd at blive kontaktet: en dårlig karakter uden opfølgning er en spildt chance).

Skriv: Den komplette e-mail til afsendelse (maksimalt 40 ord før spørgsmålet, karakteren gives med ét klik fra mailen), reglen for at undgå at trætte kunden (en meget aktiv kunde modtager ikke 5 undersøgelser om måneden), og den interne proces for svar: Hvem læser dem, hvem ringer til de utilfredse, og inden for hvilken tidsfrist.

Forbered NPS-kampagnen for [virksomhed] ([produkt eller ydelse], base på [antal] kunder, seneste NPS: [tidligere score eller første måling]).

Udform: E-mailen med undersøgelsen (standardspørgsmålet "hvor sandsynligt er det at du vil anbefale..." med 0-10 skala, en intro-sætning der giver en reel grund til at svare, løftet om at det kun tager 30 sekunder), den enkelte opfølgning til dem der ikke har svaret ([varighed] efter, anden vinkel, ingen skyldfølelse), og planen for behandling pr. svarsegment: Tak til ambassadører (promoters) med en konkret handling ([handling: anmodning om offentlig anmeldelse, henvisningsprogram]: uden aktiv brug er en ambassadør spildt), opfølgende spørgsmål til de passive (hvad mangler for at give et 9-tal?), personlig opringning til kritikere (detractors) inden for [frist] med en samtaleguide (lyt, undgå forsvar, giv et konkret løfte).

Regler: Bed aldrig om en bestemt karakter ("giv os 9 eller 10") da det ødelægger alt, respekter anonymitet hvis det er lovet. Format: E-mails + samtaleguide + kampagnekalender.

Analyser disse kundekommentarer for [virksomhed], fra [kilde: NPS, CSAT, online anmeldelser, sager] i perioden [periode]: [indsæt kommentarer].

Udform: En kategorisering efter temaer der opstår ud fra selve kommentarerne (brug ikke forudindtagede kategorier), med volumen af nævnelser for hvert tema, den dominerende tone, og 2 præcise repræsentative citater (aldrig omformuleret). Skeln mellem faktuelle irritationsmomenter (fejl, ventetid, brudte løfter) og opfattelser (indtryk af at det er dyrt eller komplekst), som skal håndteres forskelligt. Identificer svage signaler: Sjældne men alvorlige nævnelser ([eksempler: trussel om at stoppe, sammenligning med navngiven konkurrent, sikkerhedsproblem]) der skal rapporteres selvom volumen er lille.

Afslut med: Top 3 handlinger foreslået ud fra kommentarerne (hver koblet til de citater der begrunder dem), og hvad dette datagrundlag IKKE giver svar på (stikprøvestørrelse, bias i indsamling, manglende input fra tavse kunder). Opfind ingen kommentarer, og udfyld ikke manglende tal.

En kunde hos [virksomhed] beder om at opsige [abonnement eller ydelse, anciennitet, beløb]. Angivet årsag: [udtrykt årsag]. Kontohistorik: [brug, tidligere hændelser, seneste dialog]. Hvad jeg kan tilbyde: [muligheder: prisjustering, ændret pakke, pause, ekstra hjælp].

Opbyg guiden til fastholdelsessamtalen: Bekræft modtagelse UDEN at spærre vejen (bekræft at opsigelsen vil ske hvis de ønsker det: kunden skal føle sig fri, ikke fanget), derefter ÉT oprigtigt spørgsmål for at forstå den reelle årsag (den angivne årsag er ofte den korte version). Baseret på årsagen gives det passende svar: Løsbart problem (løs det først, fastholdelse bagefter), forkert pakke (foreslå den rette, selvom den er billigere: et ærligt salg i dag er en kunde i morgen), pris (prisjustering ÉN gang med en klar varighed, aldrig evig rabat der straffer loyale kunder), besluttet afgang (opsig pænt og efterlad et godt sidste indtryk).

Skriv formuleringer til hver gren og de 3 forbudte metoder (tvungen fastholdelse, skyldfølelse, bevidst besværlig procedure).

Design det online opsigelsesflow for [abonnement eller ydelse] hos [virksomhed]. Krav: Opsigelse skal være lige så let som tilmelding (det er god skik og ofte et lovkrav, f.eks. en synlig opsigelsesknap), men vi har ret til at forsøge en ærlig fastholdelse undervejs.

Design flowet skærm for skærm: Bekræftelse af hensigt med et faktuelt resumé af hvad kunden mister (data, historik, optjente fordele: informativt, ikke truende), ÉT spørgsmål om årsagen (klikbare valg + valgfrit tekstfelt), ÉT tilbud tilpasset den valgte årsag (billigere pakke hvis for dyrt, pause hvis midlertidig manglende brug, hjælp hvis problemer med brug: aldrig mere end ét modtilbud), derefter bekræftelse af opsigelse med ét klik med slutdato og en opsummerende e-mail.

Skriv alle tekster til skærmene. Forbudt: Misvisende knapper ("Bliv" i stærk farve, "Opsig" grået ud og gemt), gentagne trin, krav om at ringe, skyldfølelse ("dit team vil blive skuffet"). Tilføj bekræftelsesmailen og en velkomst-hilsen hvis kunden vender tilbage en dag.

Skriv genvindingskampagnen for [virksomhed] til kunder, der forlod os for [varighed] siden. Segmenter efter kendt årsag til afgang: [segmenter: pris, manglende funktion, dårlig oplevelse, behov ophørt, ukendt årsag]. Hvad der har ændret sig hos os siden da: [reelle og verificerbare forbedringer].

For hvert segment skal du skrive en specifik e-mail: Anerkend afgangen uden at dramatisere den, annoncer hvad der har ændret sig I RELATION til deres årsag til afgang (til segmentet "manglende funktion" taler vi om den nye funktion, ikke en rabat; lov intet der ikke står på listen over reelle forbedringer), et simpelt tilbud om at vende tilbage ([tilbud hvis planlagt]), og en ordentlig udgang (link til afmelding: skriv aldrig mere til dem der beder om det).

Begrænsninger: Maksimalt 90 ord pr. e-mail, ingen tårevædet "vi savner dig", ingen systematiske rabatter der lærer kunder at gå for at få bedre priser. Tilføj: Rækkefølge for udsendelse til segmenterne og kriteriet for at stoppe kampagnen.

Lav opfølgningsbeskeder efter løsning for [virksomhed] til følsomme sager: [typer af sager: større hændelse, kunde der truede med at gå, givet kompensation, tilbagevendende problem endelig løst].

For hver type skal du skrive beskeden der sendes [varighed, f.eks. 7 dage] efter lukning: Tjek at løsningen holder over tid (præcist spørgsmål om det oprindelige problem, ikke bare et løst "går det godt?"), vis at sagen ikke er glemt så snart den er lukket, og genåbn kanalen uden friktion hvis problemet er vendt tilbage.

Regler: Maksimalt 60 ord, eksplicit reference til det løste problem ([felt: resumé af sagen]), underskrevet af den person der behandlede den (menneskelig kontinuitet betyder noget i følsomme sager), ingen salgsbudskaber i denne besked (opfølgning der ender i reklame ødelægger sin egen effekt).

Tilføj: Reglen for hvornår dette skal sendes (hvilke sager fortjener denne opfølgning, så det ikke udvandes), og hvad man gør hvis kunden svarer at problemet er vendt tilbage: Prioritering og hvem der tager sagen.

Vi har opdaget et problem hos [virksomhed], før de fleste kunder har bemærket det: [problem: forsinkelse i pakning, fejl på et parti, prisfejl, mislykket vedligeholdelse]. Berørte kunder: [identificerbar gruppe]. Rettelse: [plan og tidsfrist]. Historik: De berørte kunder har ikke meldt noget endnu.

Skriv den proaktive besked: Annoncer problemet enkelt før de selv opdager det (at give besked selv forvandler en fremtidig utilfreds kunde til en kunde der føler sig respekteret), sig præcis hvem der er berørt og hvordan man tjekker det, hvad vi gør og tidsfristen, hvad kunden skal gøre hvis der kræves handling fra deres side ([eventuel handling]), og den kompensation der gives automatisk hvis et tab er sikkert ([kompensation]): Uden at kunden skal bede om det.

Lav den i 3 formater: E-mail til berørte kunder, standardsvar til supporten når spørgsmålene kommer, og en boks på hjemmesiden hvis mange er berørt. Regler: Ingen minimering ("lille forsinkelse"), ingen internt jargon, dato for næste opdatering hvis problemet stadig kører.

Du er supportchef hos [virksomhed]. En kunde overskrider gentagne gange grænserne: [adfærd: fornærmelser mod medarbejdere, chikanerende opfølgning, trusler, krav uden for rammerne, dokumenteret ond tro]. Historik: [fakta med datoer]. Kundens kommercielle værdi: [kontekst, husk at det ikke retfærdiggør alt].

Opbyg den gradvise rammesætning: Trin 1, høflig irettesættelse undervejs i en dialog (præcis formulering: vi behandler anmodningen OG italesætter den uacceptable adfærd uden at forhandle om det); trin 2, formelt brev om rammer (fakta med datoer uden følelsesmæssige vurderinger, hvad vi fortsat leverer, reglerne for dialog fremover: kun én kanal, én kontaktperson, standard svartider); trin 3, afslutning af det kommercielle forhold hvis det er kontraktuelt muligt ([kontraktuel situation]), formuleret sagligt med hvad der udestår fra begge parter.

Tilføj: Beskyttelse af teamet (ret til at afslutte en fornærmende samtale, synlig ledelsesopbakning, registrering af hændelser), og den vigtige skelnen: En kunde der er berettiget vred (skal hjælpes) versus en grænseoverskridende kunde (skal rammesættes).

En kunde hos [virksomhed] har gjort indsigelse mod en betaling i sin bank (chargeback) i stedet for at kontakte os: [kontekst: beløb, produkt eller ydelse, tilsyneladende årsag, kundehistorik]. Vores holdning: [vores udlægning: vores fejl, misforståelse, ydelse leveret korrekt, mistanke om bevidst snyd].

Skriv beskeden der skal sendes til kunden: Tag kontakt uden bebrejdelser (mange kunder ved ikke at en chargeback er en formel tvist og ikke bare en refundering), omformuler hvad vi forstår ved deres indsigelse, foreslå en direkte løsning baseret på vores holdning (øjeblikkelig refundering hvis fejlen er vores: hurtigere for dem end bankproceduren; saglig forklaring med beviser hvis ydelsen er leveret), og hvad der sker derefter baseret på deres svar.

Regler: Ingen trusler eller anklagende tone (sagen kan ende i voldgift: hvert ord skal kunne tåle at blive læst af tredjepart), ingen løfter om at opgive vores rettigheder, saglig hele vejen igennem. Tilføj intern note: Dokumentation der skal samles nu til besvarelse af tvisten ([typer af beviser]).

Skriv kommunikationen fra [virksomhed] for at annoncere: [ændring: opdatering af handelsbetingelser, ændring af en funktion, nye åbningstider i supporten, ny bestillingsproces]. Konkret betydning for kunderne: [hvad ændrer sig i deres hverdag, hvem er berørt]. Ikrafttrædelsesdato: [dato]. Eventuelt kontraktuelt varsel: [forpligtelser].

Strukturér e-mailen: Ændringen skal stå klart allerede i emnefeltet og første sætning (ikke noget med "vi udvikler vores tjenester", som intet siger), hvad der konkret ændrer sig FOR DEM i en kort liste (før / efter), hvorfor (den reelle årsag i én sætning, selv når den er praktisk), hvad de skal gøre hvis der kræves handling ([krævet handling eller ingen]), og hvor de kan stille spørgsmål.

Tilføj: Standardsvar til supporten på de 3 forventelige reaktioner ([forventede reaktioner]), varianten til de kunder som ændringen reelt rammer negativt (anerkend det, sig hvad vi tilbyder: [kompensation eller alternativ]), og tidsplanen: Annoncering, påmindelse før ikrafttræden, besked på selve dagen hvis nødvendigt.

Skriv meddelelsen om ophør af [produkt eller ydelse] fra [virksomhed], der stopper d. [dato]. Berørte aktive kunder: [antal og profiler]. Det vi tilbyder: [efterfølger: erstatningsprodukt, hjælp til migrering, forholdsmæssig refundering, intet]. Årsag: [reel årsag].

Struktur: Klar besked fra starten (produktet stopper d. [dato], ingen eufemismer som "ændring i vores sortiment"), den komplette tidsplan (hvor længe alt fungerer, delmål: [delmål: slut på salg, slut på support, lukning]), hvad kunden skal gøre og hvornår, med den nemmeste vej ([migrering eller alternativ]: detaljer trinene og hvad vi hjælper med), den økonomiske håndtering (aktive abonnementer, restbeløb, bindinger), og en dedikeret kontaktkanal.

Regler: Generøst varsel, intet tab af data uden en løsning (eksport mulig indtil [dato]), erstatningen foreslås uden tvang. Lav: E-mail med annoncering, 2 påmindelser, standardsvar til support. Tone: Respektfuld over for kunden, der havde valgt dette produkt.

Opbyg skabelonen til den ugentlige supportrapport for [virksomhed], rettet mod [modtagere: ledelse, produktteam]. Tilgængelige data i [værktøj]: [tilgængelige nøgletal: volumen pr. kanal og årsag, tid for første svar og løsning, tilfredshed, backlog].

Strukturér rapporten på én side: Resumé i 3 sætninger (ugens tendens, vigtigste hændelse, beslutning der kræves hvis nogen), nøgletal i en tabel med sammenligning med ugen før (kun de nævnte tilgængelige tal: lav ikke felter til data vi ikke har), årsager i bevægelse (hvad stiger, hvad falder, og en hypotese om årsagen frem for en påstand), feedback til produktteamet (ugens 3 største irritationer med citater), og status på backlog med en plan hvis den vokser.

Regler: Et tal uden sammenligning eller grænseværdi siger intet (hvert tal skal have en reference), ingen selvros eller dommedagsprofetier, skal kunne læses på 3 minutter. Giv skabelonen og et udfyldt eksempel med fiktive data markeret som sådan.

Organiser det månedlige møde mellem supporten og produktteamet hos [virksomhed]. Nuværende problem: Supporten ser irritationerne først, men deres feedback går tabt; produktteamet opdager problemerne via andre kanaler senere.

Design ritualet: Forberedelse hos supporten (top 5 irritationer for måneden, hver dokumenteret på 4 linjer: symptom, volumen af sager, kundecitat, nuværende workaround brugt af medarbejdere), afvikling på 45 minutter (gennemgang af nye irritationer, eksplicit beslutning om hver: planlagt rettelse med dato, officiel workaround, eller bevidst afslag med årsag: et begrundet afslag er bedre end tavshed), opfølgning på sidste måneds beslutninger som start (hvad er gjort, hvad er skredet), og feedback-loop til medarbejderne: Hvad er besluttet, så de ved hvad de skal sige til kunderne.

Udform: Skabelon til irritations-beskrivelse, dagsorden, tabel til opfølgning på beslutninger, og de 3 fælder der dræber dette ritual (indkøbsseddel uden prioritering, gensidige anklager, beslutninger uden ansvarlig) med deres modtræk.

Forbered supporten hos [virksomhed] på spidsbelastningen ved [begivenhed: jul, udsalg, produktlancering, kampagne], forventet fra [periode]. Referencer: [historik fra sidste spidsbelastning: volumen, dominerende årsager, hvad der gik galt]. Team: [normal bemanding, mulige forstærkninger].

Opbyg planen: Prognose for belastning pr. kanal og årsag (kun ud fra den leverede historik: hvis ingen historik, foreslå en metode til at estimere det uden at opfinde tal), en bevidst og annonceret nødplan (midlertidigt længere svartider: kommunikeret PÅ FORHÅND på [platforme] frem for at lade det ske i tavshed), prioritering af behandling under spidsbelastningen (hvad tager vi først, hvad udskyder vi bevidst), makroer og hjælpeartikler der skal forberedes til de forventede årsager ([forventede årsager]: liste der skal skrives før ræs), forberedelse af forstærkninger (lyntræning, begrænset område til simple opgaver, korrektur), og konkrete grænser for handling: Ved hvilket niveau af backlog gør vi hvad ([mulige tiltag]).

Format: Plan med bagudrettet tidslinje fra start af spidsbelastning + tabel over grænseværdier + præ-skrevne kommunikationsbeskeder.