Human Handoff AI tēlkūbotā: kad tīmekļa atbalstam jāpārnāk uz cilvēku

AI tēlkūbotam jāpalīdz tīmekļa vietnes apmeklētājiem ātrāk nonākt pie pareizās atbildes. Atbalsta sფერā tas ir tikai puse no uzdevuma. Otra puse sākas tieši tur, kur bots vairs nav pārliecināts, vairs nav kompetents vai vairs nav noderīgs: pie Human Handoff. Ar to tiek saprotums plānota esošā dialoga nodošana cilvēkam, lai apmeklētājiem nebūtu jāatkārto savs pieprasījums, jāmaina kanāls vai vispirms jācīnās pret botu.

Tīmekļa komandām šis punkts ir stratēģiski svarīgs. Tēlkūbots, kas atbild uz rutīnas jautājumiem, samazina slodzi atbalsta dienestā. Tēlkūbots, kas bloķē reālas eskalācijas, palielina frustrāciju, atkārtotos kontaktus un atteikšanās līmeni. Tāpēc labākais risinājums nav „bots vai cilvēks“, bet gan skaidrs nodošanas mehānisms: bots risina to, ko viņš var uzticami izrisināt, un atver ceļu, tiklīdz cilvēks kļūst par labāko variantu.

Kāpēc Human Handoff nav tēlkūbota neveiksme

Jaunākie Nielsen Norman Group UX pētījumi dēvē „Handoff willingness“ (nodošanas gatavību) par vienu no galvenajām vietnei specifisko AI tēlkūbotu kvalitātēm. Ieteikums ir vienputnīgs: ja lietotāji nepārprotami vēlas runāt ar cilvēku, botam nevajadzētu šo pieprasījumu noraidīt. Arī atkārtota pārformulēšana, pamanāma frustrācija vai nepietiekama atbildēm kvalitāte ir signāli, ka būtu jāpiedāvā nodošana.

Tas saskan ar tehniskiem dizaina modeļiem. Microsoft rakstura Human Handoff kā saplausīgu veidu, ja bots nesaprot pieprasījumu vai ja procesu nevar automatizēt. Google apraksta Handoff Dialogflow sistēmā kā gala lietotāja sarunas nodošanu cilvēk-agentam. Abas perspektīvas rāda: Handoff nav kāds īpašgadījums malē, bet gan pamatdators nopietna atbalsta plūsmas.

Tie, kuri rūpīgi plāno pāreju, var pat padarīt tēlkūbotu spēcīgāku. Apmeklētāji vairāk uzticas botam, ja tas zina savus ierobežojumus. Atbalsta komandas gūst labumu, ja nodošana notiek kopā ar sarunas kopsavurumu, valodu, tēmu, prioritāti un līdz šim sniegtajām bota atbildēm. Tad cilvēkam nav sākt no nulles.

Svarīgākie triggeri nodošanai

1. Apmeklētājs tieši prasa cilvēku

Skaidrākais triggers ir nepārprotama formulēšana, piemēram, „cilvēks“, „atbalsts“, „agents“, „zvaniet man“, „darbinieks“ vai „Live-Chat“. Šim pieprasījumam nevajadzētu būt slēptam aiz trim papildu bota jautājumiem. Isa aklasšana var būt aktuāla, ja tā ir nepieciešama marutēšanai, piemēram, „Vai tas ir saistīts ar rēķinu, tehniku vai pārdošanu?“. Tomēr pašai nodošanai jābūt redzamai un saistozai.

2. Bots ir nedrošs vai atkārtojas

Botam nevajadzētu izlikties, it kā katra atbilde būtu vienādi pamatota. Zema atbildēm pārliecība, neatrastas atbildes zināšanu bazē, pretrunīgi avoti vai vairākārtīgas precizēšanas bez progresa ir labi iekšējie triggeri. Praktiski noderīgs ir tāds noteikums: pēc diviem neveiksmīgiem precizēšanas mēģinājumiem bots aktīvi piedāvā nodošanu. Tas novērš begaunīgus ciklus un pasargā uztveramās atbildēm kvalitāti.

3. Pieprasījums prasa rīcību, lēmumu vai atbildību

Daudzi tīmekļa jautājumi ir informatīvi: darba laiki, cenu sākums, dokumentācija, produktu salīdzinājums. Citiem vajag cilvēku: līguma maiņa, labprātslēguma lēmumi, sūdzības, atkāpšanās no līgumiem, drošības incidenti, medicīniski vai juridiski 개별 gadījumi, individuāli piedāvājumi vai personīgi konta dati. Šādiem gadījumiem bots var vākt un sagatavot datus, taču viņam nevajadzētu pašsaistīgi solīt lēmumus, ko uzņēmums nevēlas pieņemt automatizēti.

4. Mainās valoda, tonis vai steidzamība

Atkārtoti lielie buri, teikumi kā „tas nepalīdz“, sūdzību termini, piegādes problēmas, paziņojumi par dīkstāviem vai maksājumu termiņi var būt eskalācijas signāli. Svarīgi ir nepārliekt dramatizēt. Botam vajadzētu mierīgi atzīt situāciju un piedāvāt nākamo soli: „Es nododam šo atbalsta komandai un pievienoju līdz šina sarunas gaitu.“

Kas jāpievieno nodošanas laikā

Human Handoff ir noderīgs tikai tad, ja cilvēks redz kontekstu. Microsoft Handoff protokols paredz citu starp citiem konteksta datus un transkriptu. Tīmekļa komandām no tā var izveidot kompaktu nodošanas sarakstu:

• īsu lietotāja nodoma kopsavurumu vienā teikumā,
• pēdējās relevantās ziņas vai transkriptu,
• pašlaik esošo lapu, produktu, formu vai rakstu, no kura tērzēšana tika uzsākta,
• apmeklētāja valodu un preferred kanālu,
• atzīto kategoriju, piemēram, atbalsts, pārdošana, rēķini vai tehnika,
• steidzamību un eskalācijas iemeslu,
• avotus vai zināšanu bāzes rakstus, kurus bots jau ir izmantojis,
• tikai tos personas datus, kas ir tiešām nepieciešami apstrādei.

Tieši pēdējais punkts ir izdecīvozais. Handoff nozīmē nevis pēc iespējas vairāk datu nodošanu, bet gan relevantu datu nodošanu sakārtotā veidā. Ja ir nepieciešama sensitīva informācija, tīmekļa komandām precīzi jānosaka, kādus datus bots vispār drīkst pieprasīt un kad ir nepieciešams drošs kanāls.

Praktiski pielietojama nodošanas plūsma

Stabila plūsma nesākas tikai pie kļūdas. Jau sveikenam vajadzētu noteikt ietvarus: bots palīdz ar tipiskiem tīmekļa jautājumiem un, ja nepieciešams, var nodot sarunu komandai. Dialoga laikā viņš tieši atbild uz vienkāršiem pieprasījumiem, mērķēti precizē neskaidrus promptus un sniedz saites uz relevantu saturu. Ja aktivizējas triggers, viņš īsi paskaidro pāreju.

Labi paraugs ir: vispirms atzīt, tad apkopot, pēc tam piedāvāt nākamo darbību. Piemērs: „Es nevaru to uzticami izskaidrot līdz galām. Es apkopoju līdz šina informāciju un nododu to mūsu atbalsta komandai.“ Pēc tam apmeklētājam jāredz, kas notiek: Live-Chat, atzvanis, e-pasta taloniņš, saite uz kalendāru vai kontaktforma. Ja cilvēks uzreiz nav pieejams, botam tas jāsaka godīgi un jāpiedāvā reāls alternatīvs risinājums.

Komandām ar vairākām atrašanvietām, valodām vai produktu līnijām papildus ir izdevīgi izmantot marutēšanas soli. Šim posmam jābūt īsam un jāpieprasa tikai tāda informācija, kas tiešām kalpo piešķiršanai. Garš priekšfiltrs rada šķēršļa sajūtu un strādā pret Handoff mērķi.

Labi nodošanas teksti ir īsi un saistozi

Mikrokopija izlem, vai pāreja šķiet uzticama. Izvairieties no teikumiem kā „Es esmu tikai bots” vai „To es, neatkarīgi no visa, nevaru”. Labāki ir skaidri, rīcības orientēti formulējumi:

• „Es nododu šo tērzēšanu mūsu atbalsta komandai un pievienoju līdz šina sarunas gaitu.“
• „Šajā gadījumā cilvēks ir labāks sarunpartneris. Vai vēlaties, lai izveidoju taloniņu ar jūsu kopsavurumu?“
• „Es atradu divus iespējamos cēloņus, taču nevaru droši izlemt. Es tālāk nosredirectTo šo gadījumu.“
• „Šobrīd Live-agents nav pieejams. Es varu sagatavot jūsu pieprasījumu kā taloniņu vai rādīt piemērotāko kontaktceļu.“

Šie teksti nedod pārkārtu solījumus. Tie skaidro iemeslu, samazina atkārtošanos un dod apmeklētājam kontroli pār nākamo soli.

KPI: ko komandām mērīt pēc starta

Handoff koncepcija ir uzticama tikai tad, ja tā tiek mērīta. Tikas automatizācijas kvotas nepietiek, jo tās var radīt nepareizus stimulus. Tie, kas optimizē tikai „mazāk nodošanu“, riskē ar to, ka bots pārāk ilgi patura sarežģītos gadījumos. Līdzjutīgāk ir kombinēt kvalitātes un efektivitātes metriku:

• Handoff līmenis pēc tēmas un lapas,
• Sagatavotu nodošanu veiksmīgi pieņemto īstuma īsākums,
• gaidīšanas laiks līdz cilvēka atbildei,
• atkārtošanās līmenis pēc nodošanas,
• risinājuma līmenis un atkārtoti kontakti definētā laikā,
• bota pārliecinātība pirms eskalācijas,
• atteikšanās līmenis Handoff plūsmēs,
• bota izveidota kopsavuruma kvalitāte.

Cifrām regulāri jāsalīdzina ar reālām tērzēšanas gaitām. Augsts nodošanas līmenis var būt slikts, ja vienkārši jautājumi nevajadzīgi eskalē. Taču tas var būt labi, ja bots agri atpazīst sarežģītos gadījumus un tos rūpīgi sagatavo. Konteksts ir svarīgāks par vienu mērķskaikļi.

Kontrolsaraksts tīmekļa vietņu operatoriem

• Definējiet, uz kuriem pieprasījumiem bots drīkst atbildēt patstāvīgi.
• Sarakstiet skaidrus Handoff triggerus cilvēka vēlmībai, nedrošumam, frustrācijai un nepārstāstāmiem procesiem.
• Ierobežojiet precizēšanas mēģinājumu skaitu, pirms tiek piedāvāta nodošana.
• Saglabājiet īsu, pārbaudāmu sarunas kopsavurumu agentiem.
• Nododiet kopā valodu, lapu, kategoriju un relevantos avotus.
• Izvairieties no nevajadzīgiem personas datiem bota dialogā.
• Plānojiet offline scenārijus, lai bots nenodotu sarunu tuklumā.
• Testējiet datorā un mobilajā ierīcē, jo Handoff pogas mazos ekrānos bieži vien ir grūtrāk pamanāmas.
• Kārtly pārskatīiet reālās nodošanas un pielāgojiet triggerus.

Tipiskas kļūdas

Biežākā kļūda ir „vārtu sargāšana“ (gatekeeping): apmeklētājs lūdz cilvēku, bet bots uzdod papildu obligātos jautājumus. Gandrīz tikpat kaitinošs ir Handoff bez konteksta, kur cilvēkam nākas visu izjautāt no jauna. Trešā kļūda ir nepareiza panākumu mērīšana. Ja zems Handoff līmenis tiek uzskatīts par panākumu, kamēr sūdzības un atkārtoti kontakti aug, komanda optimizē procesu pretēji lietotāja mērķim.

Labi AI tēlkūbots nav tas, kurš katru dialogu pabeidz viens. Labs ir bots, kurš uzticami risina vienkāršus uzdevumus, transparenti norāda ierobežojumus un piesaista cilvēku tieši tajā brīdī, kad tas ir labākāk apmeklētājam un komandai. Tie, kuri šo pāreju veido apzināti, apvieno automatizāciju ar servisa kvalitāti.

Lasīt tālāk un avoti

Handoff izveidei vērts apskatīt salīdzinājumu AI tēlkūbots vs. Live-Chat vs. kontaktforma, atbalsta pamatus rakstā Kā AI tēlkūbots uzlabo tīmekļa klientu atbalstu un mērīšanas loģiku AI tēlkūbota KPI. Profesionālās avoti šim rakstam ir Nielsen Norman Group raksti The 5 Qualities of Site-Specific AI Chatbots un The User Experience of Chatbots, Microsoft Learn par Bot-to-Human Handoff kā arī Google Cloud dokumentācija par Dialogflow ES Handoff.