Anmod om opsummering og klassificering (billettriage)

Gevinster:

• Evne til at omdanne lange og spredte kundeønsker til strukturerede, handlingsrettede resuméer
• Evne til at klassificere forespørgsler efter kategori, haster og kundefølelse med et fast skema
• Evne til at definere et ensartet outputformat (JSON/tabel) egnet til automatisering til bulk billetbehandling

Forestil dig et supportteams morgen: 220 nye billetter (billetter) er samlet i løbet af natten. Nogle er en enkelt linje "Jeg har glemt min adgangskode", nogle er en vred klage i tre afsnit, og nogle er faktisk en salgsmulighed. At læse denne bunke igennem, tildele hver enkelt den rigtige kategori, bestemme dens hastende karakter og rette den til den rigtige person (dette kaldes triage; den samme logik med at sortere patienter efter prioritet på skadestuen) spiser op de første to timer af dagen.

Kunstig intelligens (AI) kan udføre dette job på få sekunder og konsekvent. Men magien ligger ikke i at sige "opsummer denne anmodning"; Det pålægger modellen en fast liste over kategorier, klare hasteniveauer og et uforanderligt outputformat. I denne enhed vil vi etablere et triage-system, der går fra at behandle en enkelt anmodning til at mærke hundredvis af anmodninger på en automatiseringsklar måde.

Bemærk: Kategori- og hastemærkerne genereret af AI er et foreløbigt screeningsværktøj. Især anmodninger mærket "haster" og "klage" skal bekræftes af et menneske, før de behandles.

Hvorfor struktureret resumé?

En gratis oversigt ("kunden har problemer med deres forsendelse") kan ikke søges, sorteres eller automatiseres. Supportchefens behov er dog klart for følgende spørgsmål:

• Hvilken kategori falder denne anmodning ind under? (Forsendelse, retur, betaling, teknisk, produktinformation, klage, salgsmulighed)
• Hvor haster det? (Kritisk/Høj/Middel/Lav)
• Hvad er kundens følelsesmæssige tilstand? (Vred / Skuffet / Neutral / Tilfreds)
• Hvad er dens en-sætnings essens?
• Hvad skal det næste skridt være?

Når du først har defineret disse spørgsmål på forhånd og givet dem til modellen som et skema (konstante felter og mulige værdier), bliver alle 220 anmodninger sammenlignelige og filtrerbare i samme format.

Trin for trin: Etablering af en triage-ordning

1. Fastgør kategorilisten. Lad ikke modellen passe; Giv en lukket liste.
2. Definer kriteriet for uopsættelighed. Konkret, hvad "kritisk" betyder: service helt stoppet, betalingstab, sikkerhedsrisiko.
3. Identificer følelsesetiketter. Brug et begrænset og overskueligt sæt.
4. Importer outputformatet. Til batchbehandling er JSON (maskinlæst dataformat bestående af felt-værdi-par) egnet, til enkelt anmodning er tabel velegnet.
5. Lav en "afkryds hvis ikke sikker"-regel. Hvis modellen er usikker på kategorien, så lad den sige usikker, og mennesket vil se.
6. Verificere. I den første batch skal du manuelt kontrollere nøjagtigheden af ​​etiketterne og indstille prompten.

Kopiérbare prompter

Grundlæggende prompt, der konverterer en enkelt anmodning til en struktureret oversigt:

Rolle: Du er en erfaren support triage specialist. Analyser kundeanmodningen nedenfor. Tilføj en kommentar; bare stol på, hvad der står i teksten. Udfyld følgende felter:- resumé: (max 1 sætning)- kategori: [Forsendelse | Retur | Betaling | Teknisk | Produktinformation | Klage | Salgsmulighed]- haster: [Kritisk | Høj | Medium | Lav]- følelser: [Vred | Skuffelse | Neutral | Tilfreds]- næste_trin: (enkelt sætning, konkret handling)- usikker: ("ja" hvis kategori/hast er uklar, ellers "nej") Anmodning:"""{{ request_text }}"""

Til batchbehandling konverterer prompten flere anmodninger til et JSON-array på én gang:

Behandle de nummererede anmodninger nedenfor. Generer et JSON-objekt for hvert med følgende skema og returner dem alle som et JSON-array. Går uden for ordningen: { "id": "", "summary": "", "category": "", "urgency": "", "emotion": "", "next_step": "", "I'm not sure": "" }Kun kategorier: Forsendelse, retur, betaling, teknisk, produktinformation, klage, salgsmulighed. Anmodninger: {{ numbered_request_list }}

Spørgsmålet, der præciserer hastekriteriet og lærer modellen definitionen af "Kritisk":

Bestem haster i henhold til følgende regel:- Kritisk: tjenesten er fuldstændig utilgængelig, tab af betaling, sikkerhed/datarisiko, juridisk trussel.- Høj: vigtig funktion er brudt, men en løsning findes; vred kunde.- Medium: enkeltstående problem, stopper ikke arbejdsgangen.- Lav: anmodning om information, forslag, generelt spørgsmål. Skriv årsagen til din beslutning i én sætning i feltet "urgency_reason".

Spørgsmål, der fanger salgsmuligheden og etablerer en support/salgsbro:

Ved behandling af anmodningen, hvis kunden viser interesse for at købe et nyt produkt/pakke/tillæg (f.eks. "har du en større pakke", "hvor mange brugere skal der til"), skal du lave kategorien "Salgsmulighed" og tilføje et tip på én sætning til salgsteamet i feltet "salgsnote".

Svag prompt / stærk prompt

Svag prompt

Kraftig prompt

"Opsummer og klassificer denne anmodning"

Lukket kategoriliste + urgency definition + fast JSON-skema

Genererer forskellige etiketter hver gang

Giver altid den samme etiket til den samme anmodning

Han bruger ordet "haster" efter eget ønske.

Anvender konkrete kriterier for "kritisk"

Han finder på det vage

emin_degilim: Sig ja og overlad det til personen

Konsistens er den gyldne regel her: Hvis den samme klage ikke falder ind under samme kategori på to forskellige dage, vil ingen rapportering og automatisering være pålidelig.

Tre mini etuier

Sag 1 — Fortrolig kritiker. I en SaaS-virksomhed (internetlejet software) virkede beskeden "Jeg kan ikke logge ind, hele holdet venter på 40 personer" almindelig, fordi den var kort i længden. Triage-prompten markerede det "Kritisk" takket være hastereglen ("service fuldstændig utilgængelig"-kriterier). Forespørgslen blev behandlet på 6 minutter i stedet for at vente 2 timer i køen; en overtrædelse af SLA (service level agreement, dvs. lovet responstid) er blevet forhindret.

Case 2 — Vredeprioritering. En dag, da AI-tags på 180 anmodninger blev undersøgt, blev det set, at 14 anmodninger med følelsen "Angry" blev sat i en separat kø. Disse anmodninger blev rettet til erfarne repræsentanter, og den negative undersøgelsesscore (CSAT, dvs. kundetilfredshedsscore) den pågældende uge blev væsentligt forbedret sammenlignet med den foregående uge.

Case 3 — Bro fra support til salg. "Min nuværende pakke er til 5 brugere, jeg skal øge den til 20 personer, er det muligt?" AI mærkede beskeden som "Salgsmulighed" og tilføjede en salgsnote. Anmodningen faldt automatisk til salgsteamet; En opsalgsmulighed, der ville være gået ubemærket hen, hvis den var gået tabt i standardsupportkøen, er blevet en gevinst.

Tip: Hold din kategoriliste så kort og diskret som muligt. 20 kategorier vil forvirre modellen (og dit team); 6-8 klare kategorier er mærket mere konsekvent og er meningsfulde i rapporter. Kombiner to ofte forvirrede kategorier.

Tilslutning til automatisering

Den virkelige kraft af det strukturerede JSON-output er, at det flyder automatisk til næste trin: Forespørgslen mærket "Kritisk" giver straks administratoren besked, "Salgsmulighed" falder ind i CRM (customer relationship management software), "Return" går ind i selvbetjeningsflowet. Men den første regel for automatisering: handlinger med stor effekt (refusion, kontolukning) udløses aldrig baseret på AI-tagget alene; Nogle gange er der menneskelig godkendelse.

Forsigtig: Følelsesanalyse er en forudsigelse, ikke en nøjagtig måling. En kunde, som modellen kalder "Neutral", kan faktisk stille og roligt være meget vred. Brug følelsesmærket til at prioritere; men stol ikke på det alene for at drage endelige konklusioner som "denne kunde er allerede tilfreds."

Almindelige fejl

• At overlade kategorilisten til modellen; får forskellige, inkompatible etiketter hver gang.
• At efterlade et relativt ord som "haster" udefineret; Alles anmodning haster.
• Ikke fastsættelse af outputformatet; Nogle gange vises afsnit, nogle gange liste i stedet for JSON.
• Ikke at give en udgangsdør for usikkerhed (jeg er ikke sikker).
• Sammenkædning af storslåede transaktioner (refusion, kontolukning) til AI-tagget uden menneskelig godkendelse.
• Automatisering af hele flowet uden manuelt at verificere den første batch.

Sammenfattende

• Triage sorterer hurtigt gennem bunken af indkommende anmodninger efter kategori, hastende karakter og følelser.
• Nøglen til konsistens: lukket kategoriliste, konkret urgency definition og fixed output format (JSON).
• Urgency- og følelsesmærker fremskynder prioritering; Det bringer kritiske og vrede krav frem.
• Struktureret output kan kobles direkte til automatisering (notifikation, routing, CRM).
• Handlinger med stor indvirkning og tvetydige etiketter bør altid undergå menneskelig verifikation.

Ansøgningsopgave

Batch process the 5 different customer requests you have (or samples) with the JSON array prompt above. Kontroller derefter outputtet manuelt: (1) Er hver kategori korrekt? (2) Stopper de, der er markeret som "kritiske", faktisk tjenesten? (3) Sagde jeg sikkert "ja" de rigtige steder? Ret eventuelle tags, der ikke passer, og opdater prompten (især kategoridefinitioner og hasteregel) i overensstemmelse hermed. Denne øvelse opbygger vanen med at kalibrere skemaet til din egen virkelighed.

tjekliste

• [ ] Jeg har defineret en lukket og diskret liste over kategorier.
• [ ] Jeg beskrev niveauerne af hastende karakter med konkrete foranstaltninger.
• [ ] Jeg rettede outputformatet (JSON/tabel).
• [ ] Jeg tilføjede en udgangsdør for usikkerhed (jeg er_usikker).
• [ ] Jeg bekræftede manuelt den første batch og kalibrerede prompten.
• [ ] Jeg lægger et lag af menneskelig godkendelse på handlinger med stor effekt.