Mittaus, KPI ja jatkuva parantaminen: mitä seurata ja miten?

Voitot:

• Mahdollisuus lukea klassisia KPI-mittareita (AHT, FCR, CSAT, NPS, CES) ja tekoälykohtaisia mittareita laadun tasapainottimella jokaiselle tuottavuusmitalle
• Kyky mitata vastausten tarkkuutta ja ajautumista säännöllisesti ja välttää ansaan lukittumasta yhteen mittariin
• Kyky tehdä jatkuvaa parannusta 'en tiedä' -kirjauksen, liikevaihdon syiden ja epäonnistuneiden virtojen perusteella PDCA-syklin avulla

Vaarallisin virhe, kun tekoäly saapuu puhelinkeskukseen, on sanoa "asensimme sen, näyttää siltä, ​​​​että se toimii, se riittää". Botti, avustaja tai itsepalveluvirta ei ole täydellinen sillä hetkellä, kun se julkaistaan, eikä se pysy siellä. Sitä on jatkuvasti mitattava, seurattava ja parannettava. Lisäksi väärän mittarin seuraaminen on joskus haitallisempaa kuin oikean mittarin seuraamatta jättäminen – koska se lähettää sinut juoksemaan väärään suuntaan. Tässä osiossa näemme puhelinkeskuksen avainindikaattoreita (KPI), tekoälykohtaisia ​​mittareita ja ohjeet jatkuvan parannussyklin luomiseen.

Ensinnäkin varoitus: mittarit ovat keino saavuttaa päämäärä, eivät itse päämäärä. Tavoitteena on ratkaista asiakkaan ongelma hyvin ja tehokkaasti. Jos jahdat yhtä mittaria (esim. AHT) erillään, edustajat katkaisevat puhelun ratkaisematta asiakasta, ja todellinen tarkoitus vahingoittuu. Tätä kutsutaan metriikka pakkomielle; Lue jokainen mittari vastapainolla.

Peruspuhelukeskuksen KPI:t

KPI (Key Performance Indicator) on luku, joka mittaa prosessin suorituskykyä. Puhelinkeskuksen perusasiat:

KPI

Mitä toimenpiteitä

tasapainottaja

AHT (keskimääräinen käsittelyaika)

Yhteyden kesto

FCR, CSAT (lyhyt, mutta ei liukenematon)

FCR (Resoluutio ensimmäisessä kontaktissa)

Kertaluonteinen ratkaisu

CSAT (älä sano, että ratkaisit sen etkä ratkaise sitä)

CSAT (asiakastyytyväisyys)

Yhteydenoton jälkeinen pistemäärä

Vastausprosentti (on harhaanjohtava, jos harvat täyttävät)

NPS (suosituspisteet)

Uskollisuus/suositus

Perimmäinen syy (miksi alhainen?)

CES (Customer Effort Score)

Kuinka vaikea asia olikaan

—

SL (palvelutaso)

% puhelusta vastattu x sekunnissa

Luopumisprosentti

Poistumisprosentti (abandon)

Puhelu jätettiin pitoon

SL, jäähdytys

CES (Customer Effort Score) mittaa kuinka kovasti asiakas yrittää ratkaista ongelmansa; pieni vaiva liittyy vahvasti korkeaan tarkkuuteen. Asiakas, joka sanoo "Ratkaisin sen helposti", on usein arvokkaampi kuin "Olen erittäin tyytyväinen".

Tekoälykohtaiset mittarit

Klassisten tehokkuusindikaattoreiden lisäksi AI-sovelluksille on lisätty erityisiä mittareita:

• Suojaus-/poikkeutusnopeus: Kosketusnopeus, jonka botti/itsepalvelu ratkaisee luovuttamatta sitä ihmiselle. Mutta se yksin pettää; tulee lukea yhdessä liuoksen kanssa (loukku yksikössä 8).
• Botin resoluutio: Yhteystiedot, jotka botti todella ratkaisi (asiakas lähti tyytyväisenä) – eivät "jääneet bottiin".
• Liikevaihto ja syy: Kuinka paljon siirretään ja miksi (yksikkö 10).
• Vastauksen tarkkuus: Nopeus, jolla botin/avustajan antamat vastaukset ovat oikeita – mitattuna otoksella ja ihmisen valvonnalla.
• Hyväksyminen: nopeus, jolla edustajat käyttävät agentin apuehdotuksia (osa 6).
• Yhteenvetotarkkuus: Taajuus, jolla automaattiset yhteenvedot/tunnisteet korjataan ihmisen hyväksynnällä (yksikkö 4).
• Hallusinaatiot/virheprosentti: keksittyjen tai väärien vastausten esiintymistiheys – tavoite lähellä nollaa.

Vinkki: Yhdistä jokainen tekoälymittari "laadunvakaimen" kanssa. "Säilytys korkea" ei yksin ole hyvä; "rajoitus on korkea JA bot-ratkaisutyytyväisyys on korkea" on hyvä. Älä koskaan erota tehokkuusmittaria laatumittarista.

Jatkuva parannussykli

Hyvä tekoälyohjelma on pyörivä pyörä, ei kertaluonteinen projekti. Klassinen PDCA-sykli (Plan-Do-Check-Act; PDCA) toimii täällä:

1. Suunnitelma: Mitä mittaria aiot parantaa ja miksi? Aseta tavoite (esim. "nosta botin tuottoprosenttia 60 prosentista 75 prosenttiin".
2. Käytä: Tee muutos (lisää tietokantakohde, korjaa kulku, paranna kehotetta).
3. Tarkista: Onko mittari todella parantunut? Onko sivuvaikutuksia (ovatko muut mittarit rikki)?
4. Ryhdy varotoimiin: Jos se toimii, tee siitä pysyvä; Jos se ei toimi, ota se takaisin ja opi.

Tämän syklin polttoaineena ovat tiedot: "en tiedä" -lokit (yksikkö 5), liikevaihdon syyt (yksikkö 10), epäonnistuneet virtaukset (yksikkö 8), matalapisteiset keskustelut (osa 7). Nämä resurssit kertovat, missä voit parantaa.

Varoitus: AI-mallit ja asiakkaiden käyttäytyminen muuttuvat ajan myötä; Tätä kutsutaan driftiksi. Nykyään 95-prosenttisesti toimiva botti voi hiljaa heiketä, jos sen tietopohja vanhentuu tai asiakkaan kysymysmalli muuttuu. Siksi mittaus ei ole kertaluonteinen, vaan jatkuva. Se mitä et mittaa, hajoaa hiljaa.

Neljä kopioitavaa mallia

1) KPI-kojelaudan suunnittelu:

Luo kuukausittainen KPI-hallintapaneeli luonnos puhelinkeskuksen tekoälyohjelmaani varten. Jokaiselle mittarille: määritelmä, tavoite, korvausmittari, tietolähde, hälytyskynnys (hälytys tämän arvon ylä-/alapuolella). Mittarit: AHT, FCR, CSAT, eristäminen, bot-ratkaisunopeus, kiertonopeus, vastauksen tarkkuus. Älä anna kuvitteellisia numeroita; Aseta malli niin, että täytän kentät.

2) Mittarin tulkinta (perussyy):

Tulkitse alla olevia KPI-tietoja kuin CX-analyytikko.(1) Merkittävin muutos, (2) mahdollinen perimmäinen syy HYPOTEESIT (todista), (3) mitä muuta mittaria kannattaa tarkastella (offset), (4) 2 ehdotettua toimenpidettä.Hae luvut tiedoista; Merkitse hypoteeseihin "täytyy vahvistaa". Tiedot: <<...>>

3) A/B-vertailuarvio:

Vertaa kahta botti/stream-versiota (A ja B) näillä tiedoilla: <<data>>. Kumpi on parempi suojauksen, botin resoluution ja CSAT:n suhteen? Näyttääkö ero merkittävältä vai onko se vähäistä/melua? Onko tuottavuuden kasvu laadun heikkenemisen kustannuksella? Anna selkeä suositus, mutta osoita myös mahdolliset epävarmuustekijät.

4) Jatkuvan parantamisen palautteen yhteenveto:

Yhdistä seuraavat parannusresurssit (en tiedä loki, luovutuksen syyt, epäonnistuneet vuot). Priorisoi kolme suurinta vaikutusten parantamismahdollisuutta: ongelma / vaikuttanut mittari / ehdotettu muutos / odotettu vaikutus. Luota vain tietoihin. Lähteet: <<...>>

Heikko kehote / Vahva kehote

Heikko kehote:

Kerro minulle, ovatko tämän kuukauden luvut hyviä vai huonoja.

Epäselvä: mikä mittari, mikä tavoite, mikä stabilointiaine, mikä perimmäinen syy - tuottaa pinnallisen ja harhaanjohtavan arvion.

Tehokas kehotus:

Tässä kuussa suojaus nousi 58 %:sta 71 %:iin, mutta CSAT putosi 4,1:stä 3,6:een, ja vaihtuvuus laski 30 %:sta 19 %:iin. Tulkitse tätä kaaviota: tuliko tuottavuuden kasvu asiakastyytyväisyyden kustannuksella (voivatko asiakkaat jäädä bottiin)? Millä tiedoilla minun pitäisi vahvistaa? Ehdota 2 toimenpidettä.

Ero: kysymys mittareista, tasapainotuksesta ja validoinnista on selvä; Tulkinta on järkevä (tässä on "rajoitus"-trap-signaali, koska suojan kasvu tulee CSAT-vähennyksen mukana).

kolme minilaukkua

Tapaus 1 – Väärä metriloukku. Yksi puhelinkeskus palkittiin vain AHT:lla. Agentit katkaisivat yhteyden asiakkaisiin ilman, että he päättivät lyhentää aikaa; Lyhyellä aikavälillä AHT laski 15 %, mutta uusintapuhelut kasvoivat 28 % ja FCR romahti. Kokonaistaakka ja kustannukset ovat itse asiassa kasvaneet. Tasapaino saatiin aikaan, kun AHT:ta, FCR:ää ja CSAT:ta seurattiin yhdessä. Oppitunti: yksi mittari valehtelee.

Tapaus 2 – Hiljainen ajautuminen. Pankin botti toimi ilman ongelmia 6 kuukautta, kukaan ei mitannut sitä. Kun uusia tuotteita tuli markkinoille, tietopohja jäi taakse; Botin tarkkuus putosi huomaamattomasti 94 prosentista 79 prosenttiin ja valitukset lisääntyivät. Kun säännöllinen tarkkuusmittaus saatiin aikaan, luisto havaittiin aikaisin. Oppitunti: järjestelmä, jota ei mitata, hajoaa hiljaa.

Tapaus 3 – Paranemissyklin voima. Verkkokauppayritys valitsi kuukausittaisella PDCA-syklillä kolme eniten vaikuttanutta parannusta kuukausittain (ei tiedä lokista + liikevaihdon syistä + epäonnistuneista virroista). Kuudessa kuukaudessa botin resoluutio nousi 52 %:sta 74 %:iin, CSAT 3,8:sta 4,4:ään – ei yhtenä suurena läpimurtona, vaan pieninä, mitatuina parannuksina peräkkäin. Jatkuva parantaminen tulee johdonmukaisuudesta, ei harppauksin.

Yleisiä virheitä

• Keskittyminen yhteen mittariin. Pelkästään AHT:n tai eristämisen harjoittaminen heikentää laatua; Jokaisessa mittarissa on oltava stabilointiaine.
• Tuottavuusmittarin irrottaminen laadusta. "Botti ratkaisee paljon" ja "asiakas on tyytyväinen" ovat kaksi eri asiaa; Lue yhdessä.
• Aseta se kerran ja anna sen mennä. Drift on hiljainen; Jatkuva mittaus on välttämätöntä.
• Pidetään CSAT yksin todellisena. Matala vastausprosentti johtaa CSAT:n harhaan. Katso kuka sen täytti.
• Ei yhdistä parannusta tietoihin. Priorisoi "en tiedä loki/kanavanvaihto/epäonnistunut kulku" -tiedoilla, ei intuitiolla.

Yhteenvetona

Mittaus ja jatkuva parantaminen muuttavat tekoälyn kerta-asennuksesta eläväksi järjestelmäksi. Seuraa klassisia KPI:itä (AHT, FCR, CSAT, NPS, CES) ja tekoälykohtaisia ​​mittareita (rajoitus, botin ratkaisunopeus, vastauksen tarkkuus, suositusten käyttö) yhdessä; lue jokainen tuottavuusmittari laadunvakaimen avulla; Älä koskaan kiinnitä huomiota yhteen mittariin. Paranna jatkuvasti PDCA-silmukan avulla ja käytä "ei tiedä" -lokeja, liikevaihdon syitä ja epäonnistuneita virtauksia silmukan polttoaineena. Muista: mallit ja asiakkaat ajautuvat ajan myötä; Se mitä et mittaa, rauhoittuu hiljaa.

Sovellustehtävä

Suunnittele omalle AI-ohjelmallesi KPI-hallintapaneeli, joka koostuu seitsemästä mittarista; aseta kullekin mittarille määritelmä, tavoite, korvausmittari ja hälytyskynnys (käytä mallia "1) KPI-koontinäyttö". Luo sitten kuvitteellinen kuukausittainen tietojoukko ja suorita perussyyanalyysi 2) Metric interpretation -mallin avulla. Lopuksi priorisoi kolme eniten vaikuttavaa parannusta seuraavalle kuukaudelle "4) Jatkuvan parannuksen palauteyhteenveto".

tarkistuslista

• [ ] Seuraan klassisia KPI:itä ja tekoälykohtaisia mittareita yhdessä.
• [ ] Jokaisessa tuottavuusmittarissa on laadunvakain; En keskity yhteenkään mittariin.
• [ ] Luin suojauksen/botin ratkaisun määrän sekä asiakastyytyväisyyden.
• [ ] Mittaan vastausten tarkkuutta ja ajaudun säännöllisesti.
• [ ] Teen jatkuvaa, datalähtöistä parannusta PDCA-syklin avulla.
• [ ] Asetan etusijalle parannukset "en tiedä" -lokin, luovutuksen syiden ja epäonnistuneiden kulkujen avulla.