Ieguvumi:
- Spēja pārveidot garus un izkliedētus klientu pieprasījumus strukturētos, praktiski izmantojamos kopsavilkos
- Spēja klasificēt pieprasījumus pēc kategorijas, steidzamības un klientu noskaņojuma ar fiksētu shēmu
- Spēja definēt konsekventu izvades formātu (JSON/tabula), kas piemērots lielapjoma biļešu apstrādes automatizācijai
Iedomājieties atbalsta komandas rītu: pa nakti ir sakrājušās 220 jaunas biļetes (biļetes). Daži no tiem ir vienas rindiņas uzraksts "Es aizmirsu savu paroli", daži ir dusmīga trīs rindkopu sūdzība, bet daži faktiski ir pārdošanas iespēja. Izlasot šo kaudzi, iedalot katru pareizajā kategorijā, nosakot tās steidzamību un novirzot to uz pareizo personu (to sauc par šķirošanu; tāda pati loģika, kā neatliekamās palīdzības nodaļā pacientus kārtot pēc prioritātes), patērē pirmās divas dienas stundas.
Mākslīgais intelekts (AI) šo darbu var paveikt dažu sekunžu laikā un konsekventi. Bet burvība nav tajā, ka sakot "apkopojiet šo pieprasījumu"; Tas modelim uzliek fiksētu kategoriju sarakstu, skaidrus steidzamības līmeņus un nemainīgu izvades formātu. Šajā nodaļā mēs izveidosim šķirošanas sistēmu, kas iet no viena pieprasījuma apstrādes līdz simtiem pieprasījumu marķēšanai automatizācijai gatavā veidā.
Piezīme. AI ģenerētās kategorijas un steidzamības uzlīmes ir sākotnējās pārbaudes rīks. Jo īpaši pieprasījumi ar apzīmējumu "steidzami" un "sūdzība" ir jāapstiprina cilvēkam pirms to apstrādes.
Kāpēc strukturēts kopsavilkums?
Bezmaksas kopsavilkumu (“klientam ir problēmas ar sūtījumu”) nevar meklēt, kārtot vai automatizēt. Tomēr atbalsta vadītāja vajadzība ir skaidra uz šādiem jautājumiem:
- Kurā kategorijā ietilpst šis pieprasījums? (Piegāde, atgriešana, apmaksa, tehniskā, informācija par produktu, sūdzība, pārdošanas iespēja)
- Cik tas ir steidzami? (Kritisks/augsts/vidējs/zems)
- Kāds ir klienta emocionālais stāvoklis? (Dusmīgs / vīlies / neitrāls / apmierināts)
- Kāda ir tā viena teikuma būtība?
- Kādam vajadzētu būt nākamajam solim?
Kad esat iepriekš definējis šos jautājumus un norādījis tos modelim kā shēmu (pastāvīgi lauki un iespējamās vērtības), visi 220 pieprasījumi kļūst salīdzināmi un filtrējami vienā formātā.
Soli pa solim: šķirošanas shēmas izveide
- Piespraudiet kategoriju sarakstu. Neļaujiet modelim piemēroties; Sniedziet slēgtu sarakstu.
- Definējiet steidzamības kritēriju. Konkrēti, ko nozīmē “kritisks”: pakalpojums pilnībā pārtraukts, maksājuma zudums, drošības risks.
- Identificējiet emociju etiķetes. Izmantojiet ierobežotu un skaidru komplektu.
- Importējiet izvades formātu. Pakešu apstrādei ir piemērots JSON (mašīnlasīšanas datu formāts, kas sastāv no lauka vērtību pāriem), vienam pieprasījumam ir piemērota tabula.
- Izveidojiet noteikumu "atzīmējiet, ja neesat pārliecināts". Ja modelis nav pārliecināts par kategoriju, ļaujiet tam teikt, ka nav skaidrs, un cilvēks izskatīsies.
- Pārbaudīt. Pirmajā partijā manuāli pārbaudiet uzlīmju precizitāti un iestatiet uzvedni.
Kopējamās uzvednes
Pamata uzvedne, kas pārvērš vienu pieprasījumu strukturētā kopsavilkumā:
Loma: Jūs esat pieredzējis atbalsta šķirošanas speciālists. Tālāk analizējiet klienta pieprasījumu. Pievienot komentāru; vienkārši paļaujieties uz to, kas ir tekstā.Aizpildiet šādus laukus:- kopsavilkums: (maks. 1 teikums)- kategorija: [Piegāde | Atgriezties | Maksājums | Tehniski | Informācija par produktu | Sūdzība | Pārdošanas iespēja] — steidzamība: [Kritisks | Augsts | Vidēja | Zema]- emocijas: [Dusmīgs | Vilšanās | Neitrāls | Apmierināts]- next_step: (viens teikums, konkrēta darbība)- nepārliecināts: ("jā", ja kategorija/steidzamība nav skaidra, pretējā gadījumā "nē") Pieprasījums:"""{{ request_text }}"""
Pakešu apstrādei uzvedne vienlaikus pārvērš vairākus pieprasījumus JSON masīvā:
Apstrādājiet tālāk norādītos numurētos pieprasījumus. Ģenerējiet JSON objektu katram, izmantojot tālāk norādīto shēmu, un atgrieziet tos visus kā JSON masīvu. Izejot no shēmas: { "id": "", "summary": "", "category": "", "urency": "", "emotion": "", "next_step": "", "Es neesmu pārliecināts": "" }Tikai kategorijas: piegāde, atgriešana, apmaksa, tehniskā, informācija par produktu, sūdzība, pārdošanas iespēja. Pieprasījumi: {{ numbered_request_list }}
Uzvedne, kas precizē steidzamības kritēriju un iemāca modelim definīciju "kritisks":
Nosakiet steidzamību saskaņā ar šādu noteikumu:- Kritiski: pakalpojums pilnībā nav pieejams, maksājuma zaudējums, drošības/datu risks, juridiski draudi.- Augsts: svarīga funkcija ir bojāta, bet pastāv risinājums; dusmīgs klients.- Vidējs: vienreizējs jautājums, neaptur darbplūsmu.- Zems: informācijas pieprasījums, ierosinājums, vispārīgs jautājums. Laukā "urency_reason" vienā teikumā ierakstiet sava lēmuma iemeslu.
Uzvedne, kas atspoguļo pārdošanas iespēju un izveido atbalsta/pārdošanas tiltu:
Apstrādājot pieprasījumu, ja klients izrāda interesi par jauna produkta/pakas/pielikuma iegādi (piem., "vai jums ir lielāka paka", "cik lietotāju nepieciešams"), izveidojiet kategoriju "Pārdošanas iespēja" un laukā "pārdošanas_piezīme" pievienojiet pārdošanas komandai vienu teikumu.
Vāja uzvedne / spēcīga uzvedne
Vāja uzvedne
Spēcīga uzvedne
"Apkopojiet un klasificējiet šo pieprasījumu"
Slēgts kategoriju saraksts + steidzamības definīcija + fiksēta JSON shēma
Katru reizi ģenerē dažādas etiķetes
Vienmēr piešķir vienu un to pašu etiķeti vienam un tam pašam pieprasījumam
Viņš lieto vārdu "steidzami" atbilstoši savām vēlmēm.
Piemēro konkrētus kritērijus "kritiskajam"
Viņš veido neskaidru
emin_degilim: saki jā un atstāj to cilvēka ziņā
Konsekvence šeit ir zelta likums: ja viena un tā pati sūdzība neietilpst vienā kategorijā divās dažādās dienās, ziņošana un automatizācija nebūs uzticama.
Trīs mini futrāļi
1. gadījums — Konfidenciāls kritiķis. Kādā SaaS (internet rented software) uzņēmumā ziņojums "Nevaru pieteikties, visa komanda gaida 40 cilvēkus" šķita parasts, jo bija īss. Šķirošanas uzvednē tas tika atzīmēts kā "Kritisks", pateicoties steidzamības noteikumam (kritēriji "pakalpojums pilnībā nav pieejams"). Pieprasījums tika apstrādāts 6 minūtēs, nevis gaidīja 2 stundas rindā; ir novērsts SLA (service level agreement, t.i., solītā atbildes laiks) pārkāpums.
2. gadījums — dusmu prioritātes noteikšana. Kādu dienu, pārbaudot 180 pieprasījumu AI tagus, tika redzēts, ka atsevišķā rindā tika ievietoti 14 pieprasījumi ar emociju "Dusmīgs". Šie pieprasījumi tika nosūtīti pieredzējušiem pārstāvjiem, un negatīvais aptaujas rezultāts (CSAT, t.i., klientu apmierinātības rādītājs) šajā nedēļā ievērojami uzlabojās salīdzinājumā ar iepriekšējo nedēļu.
3. gadījums — pāreja no atbalsta uz pārdošanu. "Mana pašreizējā pakete ir paredzēta 5 lietotājiem, man tā jāpalielina līdz 20 cilvēkiem, vai tas ir iespējams?" AI atzīmēja ziņojumu kā "Pārdošanas iespēja" un pievienoja pārdošanas piezīmi. Pieprasījums automātiski nonāca pārdošanas komandai; Papildpārdošanas iespēja, kas būtu palikusi nepamanīta, ja tā būtu pazaudēta standarta atbalsta rindā, ir kļuvusi par ieguvumu.
Padoms. Saglabājiet savu kategoriju sarakstu pēc iespējas īsāku un diskrētu. 20 kategorijas mulsinās modeli (un jūsu komandu); 6–8 skaidras kategorijas tiek marķētas konsekventāk un pārskatos tām ir jēga. Apvienojiet divas bieži sajauktas kategorijas.
Savienojuma izveide ar automatizāciju
Strukturētās JSON izvades patiesā jauda ir tāda, ka tā automātiski pāriet uz nākamo darbību: pieprasījums ar apzīmējumu “Kritisks” nekavējoties informē vadītāju, “Pārdošanas iespēja” nonāk CRM (klientu attiecību pārvaldības programmatūra), “Atgriešanās” nonāk pašapkalpošanās plūsmā. Bet pirmais automatizācijas noteikums: spēcīgas darbības (atmaksa, konta slēgšana) nekad netiek aktivizētas, pamatojoties tikai uz AI tagu; Dažreiz ir cilvēku piekrišana.
Uzmanību! Sentimenta analīze ir prognoze, nevis precīzs mērījums. Klients, kuru modele sauc par "neitrālu", patiesībā var būt klusi ļoti dusmīgs. Izmantojiet emociju tagu, lai noteiktu prioritātes; taču nepaļaujieties tikai uz to, lai izdarītu galīgus secinājumus, piemēram, "šis klients jau ir apmierināts".
Biežas kļūdas
- Kategoriju saraksta atstāšana modeļa ziņā; katru reizi iegūstot dažādas, nesaderīgas etiķetes.
- Atstājot nedefinētu relatīvu vārdu, piemēram, "steidzams"; Ikviena lūgums ir steidzams.
- Izvades formāta nelabošana; Dažreiz JSON vietā tiek parādīta rindkopa, dažreiz saraksts.
- Nenodrošinot izejas durvis neskaidrības dēļ (es neesmu pārliecināts).
- Lielas ietekmes darījumu (atmaksa, konta slēgšana) saistīšana ar AI tagu bez cilvēka apstiprinājuma.
- Visas plūsmas automatizācija, manuāli nepārbaudot pirmo partiju.
Rezumējot
- Šķirošana ātri šķiro ienākošo pieprasījumu kaudzi pēc kategorijas, steidzamības un emocijām.
- Konsekvences atslēga: slēgto kategoriju saraksts, konkrēta steidzamības definīcija un fiksēts izvades formāts (JSON).
- Steidzamības un emociju etiķetes paātrina prioritāšu noteikšanu; Tas izvirza kritiskas un dusmīgas prasības.
- Strukturēto izvadi var tieši saistīt ar automatizāciju (paziņošana, maršrutēšana, CRM).
- Ietekmīgas darbības un neskaidras etiķetes vienmēr ir jāpārbauda cilvēkam.
Lietojumprogrammas uzdevums
Pakešapstrādājiet piecus dažādus klientu pieprasījumus (vai paraugus), izmantojot iepriekš norādīto JSON masīva uzvedni. Pēc tam manuāli pārbaudiet rezultātu: (1) Vai katra kategorija ir pareiza? (2) Vai tie, kas atzīmēti kā "kritiski", patiešām pārtrauc pakalpojumu? (3) Vai es noteikti teicu "jā" pareizajās vietās? Izlabojiet visus tagus, kas neatbilst, un attiecīgi atjauniniet uzvedni (jo īpaši kategoriju definīcijas un steidzamības noteikumu). Šis vingrinājums veido ieradumu pielāgot shēmu jūsu realitātei.
kontrolsaraksts
- [ ] Esmu definējis slēgtu un diskrētu kategoriju sarakstu.
- [ ] Es aprakstīju steidzamības līmeņus ar konkrētiem pasākumiem.
- [ ] Es laboju izvades formātu (JSON/tabula).
- [ ] Es pievienoju izejas durvis neskaidrības dēļ (es_neesmu pārliecināts).
- [ ] Es manuāli pārbaudīju pirmo partiju un kalibrēju uzvedni.
- [ ] Es lieku cilvēku apstiprinājuma slāni lielas ietekmes darbībām.