Yksikkö 2 / 12

Pyydä yhteenvetoa ja luokittelua (Ticket Triage)

Voitot:

  • Kyky muuntaa pitkät ja hajallaan olevat asiakkaiden pyynnöt jäsennellyiksi, toiminnallisiksi yhteenvetoiksi
  • Kyky luokitella pyynnöt luokan, kiireellisyyden ja asiakkaan tunteen mukaan kiinteällä skeemalla
  • Kyky määritellä yhtenäinen tulostusmuoto (JSON/taulukko), joka soveltuu automaatioon joukkolippujen käsittelyyn

Kuvittele tukitiimin aamu: 220 uutta lippua (lippua) on kertynyt yön aikana. Jotkut ovat yksirivisiä "Unohdin salasanani", toiset ovat vihaisia ​​kolmen kappaleen valituksia, ja jotkut ovat itse asiassa myyntimahdollisuus. Tämän kasan lukeminen, kunkin kohdistaminen oikeaan kategoriaan, sen kiireellisyyden määrittäminen ja sen ohjaaminen oikealle henkilölle (tätä kutsutaan triageksi; sama logiikka, jossa potilaat lajitellaan prioriteetin mukaan ensiapupoliklinikalla) syövät vuorokauden kaksi ensimmäistä tuntia.

Tekoäly (AI) voi tehdä tämän työn sekunneissa ja jatkuvasti. Mutta taika ei ole sanomisessa "tiivistä tämä pyyntö"; Se asettaa mallille kiinteän kategorioiden luettelon, selkeät kiireellisyyden tasot ja muuttumattoman tulostusmuodon. Tässä yksikössä luomme triagejärjestelmän, joka etenee yksittäisen pyynnön käsittelystä satojen pyyntöjen merkitsemiseen automaatiovalmiilla tavalla.

Huomautus: Tekoälyn luomat luokka- ja kiireellisyysmerkit ovat alustava seulontatyökalu. Erityisesti "kiireellinen" ja "valitus" merkityt pyynnöt on ihmisen vahvistettava ennen niiden käsittelyä.

Miksi jäsennelty yhteenveto?

Ilmaista yhteenvetoa ("asiakkaalla on ongelmia lähetyksen kanssa") ei voi etsiä, lajitella tai automatisoida. Tukipäällikön tarve on kuitenkin selvä seuraaviin kysymyksiin:

  • Mihin kategoriaan tämä pyyntö kuuluu? (Toimitus, palautus, maksu, tekninen, tuotetiedot, valitus, myyntimahdollisuus)
  • Kuinka kiireellinen se on? (Kriittinen / Korkea / Keskitaso / Matala)
  • Mikä on asiakkaan tunnetila? (Vihainen / Pettynyt / Neutraali / Tyytyväinen)
  • Mikä on sen yhden lauseen olemus?
  • Mikä pitäisi olla seuraava askel?

Kun määrität nämä kysymykset etukäteen ja annat ne mallille skeemana (vakiokentät ja mahdolliset arvot), kaikki 220 pyyntöä ovat vertailukelpoisia ja suodatettavia samassa muodossa.

Askel askeleelta: Triage-järjestelmän luominen

  1. Kiinnitä luokkaluettelo. Älä anna mallin istua; Anna suljettu lista.
  2. Määrittele kiireellisyyden kriteeri. Konkreettisesti mitä "kriittinen" tarkoittaa: palvelu kokonaan pysähtynyt, maksun menetys, turvallisuusriski.
  3. Tunnista tunnemerkit. Käytä rajoitettua ja selkeää sarjaa.
  4. Tuo tulostusmuoto. Eräkäsittelyyn soveltuu JSON (kenttäarvopareista koostuva koneellisesti luettava tietomuoto), yksittäiseen pyyntöön taulukko.
  5. Tee "rasti, jos et ole varma" -sääntö. Jos malli on epävarma kategoriasta, sanotaan epävarma, niin ihminen näyttää.
  6. Vahvista. Tarkista ensimmäisessä erässä tarrojen tarkkuus manuaalisesti ja aseta kehote.

Kopioitavat kehotteet

Peruskehote, joka muuntaa yhden pyynnön jäsennellyksi yhteenvedoksi:

Rooli: Olet kokenut tukiryhmittelyn asiantuntija. Analysoi asiakkaan pyyntö alla. Lisää kommentti; luota vain siihen, mitä tekstissä on.Täytä seuraavat kentät:- yhteenveto: (enintään 1 lause)- luokka: [Toimitus | Palauta | Maksu | Tekninen | Tuotetiedot | Valitus | Myyntimahdollisuus] - kiireellisyys: [kriittinen | Korkea | Keskikokoinen | Matala]- tunne: [Vihainen | Pettymys | Neutraali | Tyytyväinen]- next_step: (yksi lause, konkreettinen toiminta)- epävarma: ("kyllä", jos kategoria/kiireellisyys on epäselvä, muuten "ei") Pyyntö:"""{{ request_text }}"""

Eräkäsittelyssä kehote muuntaa useita pyyntöjä JSON-taulukoksi kerralla:

Käsittele alla olevat numeroidut pyynnöt. Luo jokaiselle JSON-objekti seuraavalla skeemalla ja palauta ne kaikki JSON-taulukkona. Järjestelmän ulkopuolelle siirtyminen: { "id": "", "yhteenveto": "", "luokka": "", "kiireellinen": "", "tuntemus": "", "next_step": "", "en ole varma": "" }Vain luokat: Toimitus, Palautus, Maksu, Tekninen, Tuotetiedot, Valitus, Myyntimahdollisuus. Pyynnöt: {{ numbered_request_list }}

Kehotetta, joka selventää kiireellisyyskriteeriä ja opettaa mallille "kriittisen" määritelmän:

Määritä kiireellisyys seuraavan säännön mukaan: - Kriittinen: palvelu ei ole täysin käytettävissä, maksun menetys, turvallisuus/tietoriski, oikeudellinen uhka.- Korkea: tärkeä toiminto on rikki, mutta kiertotapa on olemassa; vihainen asiakas.- Keskitaso: yksittäinen ongelma, ei pysäytä työnkulkua.- Matala: tietopyyntö, ehdotus, yleinen kysymys. Kirjoita päätöksesi syy yhdellä lauseella "urency_reason" -kenttään.

Kehote, joka vangitsee myyntimahdollisuuden ja muodostaa tuki-/myyntisillan:

Jos asiakas osoittaa pyyntöä käsitellessään kiinnostusta uuden tuotteen/paketin/lisäosan ostamiseen (esim. "onko sinulla suurempi paketti", "kuinka monta käyttäjää se kestää"), tee kategoriaksi "Myyntimahdollisuus" ja lisää myyntitiimille yhden lauseen vihje "sales_note" -kenttään.

Heikko kehote / Vahva kehote

Heikko kehote

Tehokas kehotus

"Tee yhteenveto ja luokittele tämä pyyntö"

Suljettu luokkaluettelo + kiireellisyyden määritelmä + kiinteä JSON-skeema

Luo eri tarroja joka kerta

Antaa aina saman etiketin samalle pyynnölle

Hän käyttää sanaa "kiireellinen" oman toiveensa mukaan.

Käyttää konkreettisia kriteerejä "kriittisille"

Hän keksii epämääräisen

emin_degilim: sano kyllä ja jätä se henkilölle

Johdonmukaisuus on tässä kultainen sääntö: jos sama valitus ei kuulu samaan kategoriaan kahtena eri päivänä, ei raportointi ja automaatio ole luotettavaa.

Kolme minikoteloa

Tapaus 1 – Luottamuksellinen kriitikko. SaaS-yhtiössä (internet vuokrattu ohjelmisto) viesti "En pääse kirjautumaan sisään, koko tiimi odottaa 40 henkilöä" vaikutti tavalliselta, koska se oli lyhyt. Triage-kehote merkitsi sen "kriittiseksi" kiireellisyyssäännön ("palvelu täysin ei saatavilla" -kriteerit) ansiosta. Pyyntö käsiteltiin 6 minuutissa 2 tunnin jonossa odottamisen sijaan; SLA-rikkomus (palvelutason sopimus eli luvattu vastausaika) on estetty.

Tapaus 2 – Vihan priorisointi. Eräänä päivänä, kun 180 pyynnön tekoälytunnisteita tutkittiin, havaittiin, että 14 pyyntöä, joissa oli tunne "Angry", laitettiin erilliseen jonoon. Nämä pyynnöt suunnattiin kokeneille edustajille, ja negatiivinen kyselytulos (CSAT, eli asiakastyytyväisyyspiste) parani tällä viikolla merkittävästi edelliseen viikkoon verrattuna.

Tapaus 3 – Silta tuesta myyntiin. "Nykyinen pakettini on 5 käyttäjälle, minun täytyy lisätä se 20 henkilöön, onko mahdollista?" AI merkitsi viestiin "Myyntimahdollisuus" ja lisäsi myyntiilmoituksen. Pyyntö putosi automaattisesti myyntitiimille; Lisämyyntimahdollisuudesta, joka olisi jäänyt huomaamatta, jos se olisi menetetty vakiotukijonossa, on tullut voitto.

Vinkki: Pidä luokkaluettelosi mahdollisimman lyhyt ja diskreetti. 20 luokkaa hämmentää mallia (ja tiimiäsi); 6–8 selkeää luokkaa on merkitty johdonmukaisemmin ja niillä on merkitystä raporteissa. Yhdistä kaksi usein sekavaa luokkaa.

Yhdistetään automaatioon

Strukturoidun JSON-ulostulon todellinen voima on, että se siirtyy automaattisesti seuraavaan vaiheeseen: Kriittinen pyyntö ilmoittaa välittömästi esimiehelle, Sales Opportunity putoaa CRM:ään (asiakassuhteiden hallintaohjelmisto), Return siirtyy itsepalveluvirtaan. Mutta ensimmäinen automaation sääntö: vaikuttavia toimia (hyvitys, tilin sulkeminen) ei koskaan käynnistetä pelkästään tekoälytunnisteen perusteella; Joskus on ihmisten hyväksyntä.

Varoitus: Tunneanalyysi on ennuste, ei tarkka mittaus. Asiakas, jota malli kutsuu "neutraaliksi", voi itse asiassa olla hiljaa hyvin vihainen. Käytä emotion-tunnistetta priorisoimaan; mutta älä luota siihen yksin tehdäksesi lopullisia johtopäätöksiä, kuten "tämä asiakas on jo tyytyväinen".

Yleisiä virheitä

  • Luokkaluettelon jättäminen mallille; saada erilaisia, yhteensopimattomia tarroja joka kerta.
  • Suhteellisen sanan, kuten "kiireellinen" jättäminen määrittelemättä; Kaikkien pyyntö on kiireellinen.
  • Tulostusmuotoa ei korjata; Joskus kappale, joskus luettelo näkyy JSONin sijaan.
  • Ei tarjoa uloskäyntiovea epävarmuuden vuoksi (en ole varma).
  • Vaikuttavien tapahtumien (hyvitys, tilin sulkeminen) linkittäminen tekoälytunnisteeseen ilman ihmisen hyväksyntää.
  • Koko virtauksen automatisointi ilman ensimmäisen erän manuaalista tarkistamista.

Yhteenvetona

  • Triage lajittelee nopeasti saapuvat pyynnöt luokkien, kiireellisyyden ja tunteiden mukaan.
  • Avain johdonmukaisuuteen: suljettu luokkaluettelo, konkreettinen kiireellisyyden määritelmä ja kiinteä tulostemuoto (JSON).
  • Kiireellisyys- ja tunnetunnisteet nopeuttavat priorisointia; Se tuo esiin kriittisiä ja vihaisia ​​vaatimuksia.
  • Strukturoitu tulos voidaan liittää suoraan automaatioon (ilmoitus, reititys, CRM).
  • Vaikuttavat toimet ja moniselitteiset merkinnät on aina tarkistettava ihmisen toimesta.

Sovellustehtävä

Eräkäsittele 5 erilaista asiakaspyyntöäsi (tai näytettä) yllä olevan JSON-taulukon kehotteen avulla. Tarkista sitten tulos manuaalisesti: (1) Onko jokainen luokka oikein? (2) Pysäyttävätkö "kriittisiksi" merkityt palvelun? (3) Sanoinko varmasti "kyllä" oikeissa paikoissa? Korjaa tunnisteet, jotka eivät sovi, ja päivitä kehote (erityisesti luokkamääritykset ja kiireellisyyssääntö) vastaavasti. Tämä harjoitus kehittää tapaa kalibroida skeema omaan todellisuuteesi.

tarkistuslista

  • [ ] Olen määritellyt suljetun ja erillisen luettelon kategorioista.
  • [ ] Kuvasin kiireellisyyden tasoja konkreettisilla toimenpiteillä.
  • [ ] Korjasin tulostusmuodon (JSON/taulukko).
  • [ ] Lisäsin uloskäyntioven epävarmuuden vuoksi (en_en ole varma).
  • [ ] Vahvistin manuaalisesti ensimmäisen erän ja kalibroin kehotteen.
  • [ ] Annan ihmisen hyväksynnän voimakkaille toimille.