AI tērzēšanas robota maršrutēšanas testēšana: kļūdas, nodošana un lokalizāciju salīdzinājums

Tīmekļvietnes tērzēšanas robots var sākt daudz sarunu un tomēr izvēlēties nepareizu maršrutu. Liels potenciālo klientu, atrisinātu sesiju vai nodošanu skaits maz liecina par to, vai konkrētais lēmums bija saturiski pareizs. Iespējams, vienkāršs atbalsta jautājums tika novērtēts kā interese par pirkumu, nopietns interesents palika iestrēdzis biežāk uzdoto jautājumu lokā vai pieprasītā nodošana nonāca pie nepareizās komandas.

Tāpēc, lai pārbaudītu AI tērzēšanas robota maršrutēšanu, nepietiek ar vispārīgu KPI informācijas paneli. Izšķiroša nozīme ir pārbaudāmiem paredzētajiem ceļiem, skaidri nosauktām kļūdu klasēm, notikumiem visā piltuvē un regulārām sarunu izlases pārbaudēm. Šajā rokasgrāmatā aprakstīta praktiska pieeja tīmekļvietņu, atbalsta, mārketinga un produktu komandām.

Kāpēc maršrutēšanas kvalitāte ir atsevišķs mērīšanas uzdevums

Esošajā pārskatā par AI tērzēšanas robotu KPI ir izskaidrots, kā savstarpēji saistās atrisinājumu īpatsvars, potenciālo klientu kvalitāte un ieguldījumu atdeve. Tomēr operatīvai uzlabošanai mērījumi jāveic vienu līmeni dziļāk: vai izvēlētais ceļš bija pareizs konkrētajam pieprasījumam?

Tērzēšanas robots var formāli atzīmēt sesiju kā “atrisinātu”, lai gan atbilde neatbilda lietotāja vajadzībai. Savukārt nodošana cilvēkam var būt tieši vēlamais un saimnieciski pareizais rezultāts. Tāpēc maršrutēšanas kvalitāte nevērtē, vai nodošanu ir pēc iespējas mazāk, bet gan to, vai atbilde, kvalificēšana, atbalsts, nodošana vai atteikums atbilst situācijai.

Vispirms definējiet paredzētos ceļus un kļūdu klases

Pirms notikumu vai informācijas paneļu izveides katram būtiskam pieprasījuma veidam ir nepieciešams paredzētais mērķa ceļš. Bieži pietiek ar vienkāršu maršrutēšanas matricu: jautājums par produktu, interese par pirkumu, esošs klients ar problēmu, vēlme runāt ar cilvēku un neatbalstīts pieprasījums. Rakstā par daudzvalodu potenciālo klientu kvalificēšanu parādīts, kādi jautājumi un nodošanas var veidot šos ceļus.

Kļūdaini pozitīvs rezultāts: tērzēšanas robots saskata potenciālo klientu, lai gan tāda nav

Kļūdaini pozitīvs rezultāts rodas, piemēram, ja jautājums “Cik maksā piegāde?” uzreiz sāk potenciālā klienta apstrādes ceļu vai esoša kliente atkārtoti tiek reģistrēta kā jauns kontakts. Tas apgrūtina gan pārdošanas komandas, gan lietotāju darbu. Tāpēc mēriet, cik daudz sarunu, ko tērzēšanas robots novirzīja kā potenciālos klientus, pārdošanas komanda vai redakcionāla pārbaude vēlāk atzina par neatbilstošām.

Kļūdaini negatīvs rezultāts: patiesa interese netiek atpazīta

Kļūdaini negatīvs rezultāts rodas, ja konkrēts nodoms pirkt beidzas ar vispārīgu atbildi un netiek piedāvāta piemērota saziņas iespēja. Šo kļūdu informācijas panelī ir grūtāk pamanīt, jo potenciālā klienta notikums netika aktivizēts. To galvenokārt atklāj ar testa gadījumiem, meklēšanas modeļiem izlasēs un salīdzinājumu ar vēlāk izmantotiem saziņas ceļiem.

Nodošanas kļūda: nodošana sākta, bet nav sekmīga

Arī nodošanai ir vairāki kļūdu veidi: pārāk agra eskalācija, apspiesta vēlme runāt ar cilvēku, nodošana nepareizajai komandai vai tehniski sākta nodošana bez pieņemšanas. Rakstā par nodošanu cilvēkam AI tērzēšanas robotā aprakstīti saturiskie kritēriji; pēc tam analītikai jāparāda, vai process tiešām tika pabeigts.

Zelta kopa maršrutēšanai, ne tikai atbildēm

Atbilžu kvalitātes zelta kopu var papildināt ar maršrutēšanas gaidām. Google Cloud Dialogflow testa gadījumos cita starpā dokumentē gaidītos atpazītos nolūkus, aktīvās lapas, plūsmas un rīkus. Šis princips ir noderīgs arī neatkarīgi no konkrēta pakalpojuma sniedzēja: testa gadījumā apraksta ne tikai gaidīto atbildi, bet arī gaidīto ceļu.

Katrā maršrutēšanas testa gadījumā jāiekļauj vismaz:

• reāla vai reālistiski formulēta lietotāja ievade bez personas datiem;
• lokalizācija, kanāls un nepieciešamais sarunas konteksts;
• gaidītais pieprasījuma veids un pieļaujamā alternatīvā klasifikācija;
• gaidītais mērķa ceļš: atbilde, atbalsts, kvalificēšana, nodošana vai atteikums;
• pieļaujamie papildu jautājumi un datu lauki;
• gaidītais nodošanas iemesls un mērķa komanda;
• kļūdas smagums un par saturisko apstiprināšanu atbildīgā persona.

Iekļaujiet skaidrus gadījumus, neviennozīmīgus formulējumus, drukas kļūdas, noliegumus un robežgadījumus. Frāze “Es nevēlos piedāvājumu, tikai piegādes laiku” potenciālo klientu atpazīšanai bieži ir vērtīgāka par ideāli formulētu demonstrācijas pieprasījumu.

Sajaukuma matrica: precizitātes un tvēruma praktiska interpretācija

NIST AI riska pārvaldības satvars iesaka precizitāti saistīt ar reālistiskām testa kopām, kas pārstāv paredzēto lietojumu, un rezultātus atsevišķi izvērtēt dažādiem segmentiem. Tajā kļūdaini pozitīvu un kļūdaini negatīvu rezultātu īpatsvars ir skaidri minēts kā būtisks rādītājs. Tērzēšanas robota maršrutēšanai no tā var izveidot nelielu sajaukuma matricu.

• Potenciālo klientu precizitāte: pareizi atpazīto potenciālo klientu īpatsvars visās sarunās, kuras tērzēšanas robots novirzīja kā potenciālos klientus.
• Potenciālo klientu tvērums: atpazīto patieso potenciālo klientu īpatsvars visās pārbaudītās izlases sarunās, kurās tiešām bija interese par pirkumu.
• Nepareiza atbalsta maršrutēšana: esošo klientu pieprasījumu īpatsvars, kas kļūdaini nonāk pārdošanas ceļā.
• Nodošanas trāpījumu īpatsvars: to gadījumu īpatsvars, kuros paredzētais nodošanas iemesls un mērķa komanda ir pareizi.

Ar vienu rādītāju nepietiek. Ļoti augstu precizitāti var panākt ar pārlieku piesardzīgiem noteikumiem, kas neievēro daudzus patiesus potenciālos klientus. Savukārt augstu tvērumu var iegūt uz pārāk daudzu kļūdaini pozitīvu rezultātu rēķina. Tāpēc katrai kļūdu klasei definējiet pieņemamu slieksni un atšķirīgu steidzamības pakāpi.

No sarunas līdz izmērāmai nodošanas piltuvei

Piltuvei jāpadara redzams lēmuma ceļš, nevis jāvāc viss sarunas saturs. Noderīgi tehniskie notikumi ir, piemēram, chat_started, intent_detected, route_selected, qualification_started, handoff_offered, handoff_requested, handoff_accepted, handoff_completed, lead_submitted un route_corrected.

Katram notikumam parasti pietiek ar pseidonimizētu sesijas ID, lokalizāciju, atpazīto nolūka klasi, izvēlēto ceļu, rezultāta iemeslu, nodošanas kanālu un robota versiju. Neapstrādāti sarunu atšifrējumi nav automātiski jāievieto katrā analītikas sistēmā. Ja izmantojat Google Analytics, pabeigtus uzņēmējdarbības rezultātus var papildus sasaistīt ar ieteiktajiem potenciālo klientu notikumiem, piemēram, generate_lead, qualify_lead vai disqualify_lead. Piltuves izpēte pēc tam palīdz analizēt pārtraukumus starp definētajiem soļiem.

Pieņemta nodošana ir svarīgāka par sāktu nodošanu

Microsoft savu aģentu analītikā cita starpā nošķir atrisinātas, eskalētas un pārtrauktas sesijas, kā arī paredzētas, neparedzētas un lietotāja pieprasītas eskalācijas. Šis nošķīrums ir noderīgs arī pašu mērīšanas loģikai. Aktivizēts nodošanas notikums vēl nepierāda, ka sarunu ir pārņēmis cilvēks.

Tāpēc atsevišķi reģistrējiet vismaz piedāvājumu, pieprasījumu, pieņemšanu un pabeigšanu. Nodošanas pieņemšanas īpatsvars ir pieņemto nodošanu daļa no visām pieprasītajām nodošanām. Nodošanas pabeigšanas īpatsvars parāda, vai pēc pieņemšanas tika reģistrēts saprotams rezultāts. Papildus pārbaudiet gaidīšanas laiku, pārtraukšanu pirms pieņemšanas, nepareizu mērķa komandu un atkārtotu pārsūtīšanu.

Lokalizāciju salīdzinājumi bez ranžēšanas slazda

Maršrutēšanas problēmas var būt valodai specifiskas. Īss pirkuma nodoms vācu valodā var šķist nepārprotams, bet pieklājīgs, netiešs formulējums citā valodā var pārāk agri tikt klasificēts kā nesaistošs. Tāpēc salīdziniet precizitāti, tvērumu, nodošanas pieņemšanu un pārtraukšanu pēc lokalizācijas, taču nekad bez gadījumu skaita un datplūsmas sastāva.

• Katrā lokalizācijā izmantojiet tos pašus saturiskos pamatscenārijus.
• Pievienojiet vietēji dabiskus sinonīmus, pieklājības formas un noliegumus.
• Nošķiriet valodas kļūdas no atšķirīgiem piedāvājumiem, darba laikiem vai saziņas kanāliem.
• Nelielas izlases neuzskatiet par uzticamu ranžējumu.
• Pārbaudiet neparastus segmentus, izmantojot konkrētas, anonimizētas sarunas.

Apvienojiet produkcijas uzraudzību un regresijas testus

Bezsaistes testi un tiešraides rādītāji atbild uz dažādiem jautājumiem. Zelta kopa pirms izmaiņām parāda, vai zināmie ceļi joprojām darbojas. Produkcijas dati atklāj jaunus formulējumus, sezonālas tēmas un neparedzētas uzvedības izmaiņas. Google Cloud apraksta saglabātus testa gadījumus un nepārtrauktus testus kā veidu, kā padarīt redzamas nolūku, plūsmu un pāreju regresijas.

Praktisks ritms ietver testus pirms katras būtiskas izmaiņas, iknedēļas neparastu kļūdainu maršrutu pārskatīšanu un ikmēneša sliekšņu salīdzināšanu. Neizraisiet trauksmi par katru svārstību, bet gan par skaidrām novirzēm no dokumentētas bāzes līnijas, piemēram, būtisku neparedzētu nodošanu pieaugumu noteiktā lokalizācijā.

Plānojiet datu ziņā taupīgu analītiku

Maršrutēšanas analītika var ietvert personas datus, īpaši, ja tiek sasaistīti sarunu atšifrējumi, kontaktinformācija vai CRM rezultāti. Eiropas Komisija VDAR principus cita starpā apkopo kā nolūka ierobežojumu, datu minimizēšanu, glabāšanas ierobežojumu, kā arī integritāti un konfidencialitāti. Praksē tas nozīmē: nosauciet nolūkus, reģistrējiet tikai nepieciešamos notikumu laukus, ierobežojiet piekļuvi un definējiet dzēšanas vai pārbaudes intervālus.

Daudziem maršrutēšanas jautājumiem pietiek ar apkopotiem rādītājiem un pseidonimizētiem notikumiem. Pilni teksti jāizmanto tikai pamatotā un aizsargātā pārskatīšanas procesā. Konkrētajā gadījumā piemēroto juridisko pamatu un glabāšanas termiņu jāizvērtē speciālistam; šis raksts nav juridiska konsultācija.

14 dienu sākuma plāns

1. 1.–2. diena: nosakiet piecus svarīgākos pieprasījumu veidus un to paredzētos ceļus.
2. 3.–4. diena: definējiet kļūdaini pozitīvus un kļūdaini negatīvus rezultātus, kā arī nodošanas kļūdas un to smagumu.
3. 5.–6. diena: katram ceļam pievienojiet vismaz skaidrus, neviennozīmīgus un negatīvus testa gadījumus.
4. 7. diena: dokumentējiet notikumu nosaukumus, atļautās īpašības un datu aizsardzības robežas.
5. 8.–9. diena: pārbaudiet piltuvi no sarunas sākuma līdz pieņemtai nodošanai vai kvalificētam pieprasījumam.
6. 10.–11. diena: izveidojiet pirmo sajaukuma matricu katrai svarīgajai lokalizācijai.
7. 12. diena: redakcionāli pārbaudiet desmit neparastas sesijas un atzīmējiet cēloņus.
8. 13.–14. diena: ieviesiet vienu mērķtiecīgu izmaiņu, atkārtoti izpildiet zelta kopu un vērojiet tiešraides rādītājus.

Uzticamas maršrutēšanas kontrolsaraksts

• Paredzētie ceļi un mērķa komandas ir saturiski dokumentētas.
• Kļūdaini pozitīvi un kļūdaini negatīvi rezultāti tiek mērīti atsevišķi.
• Nodošanas piedāvājums, pieprasījums, pieņemšana un pabeigšana ir atsevišķi soļi.
• Precizitāte un tvērums netiek interpretēti bez izlases apjoma.
• Lokalizāciju segmentos ir dabiski un redakcionāli pārbaudīti testa gadījumi.
• Regresijas testi tiek veikti pirms izmaiņām; tiešraides pārskatīšana notiek regulāri.
• Analītikā tiek reģistrēti tikai definētajam nolūkam nepieciešamie dati.

Secinājums

Labu AI tērzēšanas robota maršrutēšanu nenosaka pēc iespējas vairāk potenciālo klientu vai pēc iespējas mazāk nodošanu. Tā izpaužas kā pieprasījumu uzticama novirzīšana uz piemērotāko nākamo soli. Paredzētie ceļi, maršrutēšanas sajaukuma matrica, pilnīga nodošanas piltuve un lokalizācijām specifiskas pārbaudes veido mērīšanas sistēmu, kas izskaidro kļūdas un ļauj veikt konkrētus uzlabojumus.

Sāciet ar nelielu apjomu: pieciem ceļiem, pārskatāmu zelta kopu un dažiem skaidri definētiem notikumiem. Tādējādi vispārīga tērzēšanas robota analītika kļūst par uzticamu kvalitātes procesu atbalstam, pārdošanai un lietotāju pieredzei.

Avoti

• NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Google Cloud: Dialogflow CX Test Cases
• Google Cloud: Continuous Tests and Deployment
• Microsoft Learn: Copilot Studio Analytics Overview
• Microsoft Learn: Analyze Conversational Agents
• Google Analytics: Report on a Lead Generation Form
• Google Analytics: Suggested Audiences for Lead Generation
• Eiropas Komisija: personas datu apstrādes principi saskaņā ar VDAR