AWS supporto agentas: kai pagalba turi mokėti ne tik atsakyti
·
AWS supporto agentas skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?
AWS parodė, kaip su Amazon Bedrock AgentCore sukurti supporto agentą, kuris jungia dokumentaciją, supporto API, bendruomenės žinias, autentifikaciją, ribojimus ir audito logus. Skamba kaip techninis receptas. Bet verslui čia labai aiški žinutė: pagalbos agentas turi ne tik gražiai atsakyti, jis turi mokėti saugiai veikti.
Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?
KAS NUTIKO
Sprendimas naudoja Bedrock AgentCore, Gateway, Lambda, CloudWatch ir kitus AWS įrankius. Agentas gali remtis realaus laiko dokumentacija, naudoti supporto duomenis ir dirbti su taisyklėmis, kurios riboja jo veiksmus.
Man čia primena pirmą rimtą klientų aptarnavimo dieną. Viskas atrodo paprasta, kol klientas klausia ne pagal scenarijų, sistema meta klaidą, o senas dokumentacijos puslapis sako vieną, naujas – kitą.
KODĖL TAI SVARBU
Supporto agentai svarbūs todėl, kad pagalbos komandos dažnai skęsta pasikartojančiuose klausimuose. Bet blogas atsakymas supporte kainuoja daugiau nei blogas tekstas socialiniuose tinkluose. Jis gali sustabdyti klientą, sugadinti pasitikėjimą arba atidaryti saugumo skylę.
DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia, kad DI klientų aptarnavime reikia pradėti nuo aiškių ribų: ką agentas gali tik paaiškinti, ką gali patikrinti sistemoje, kada turi perduoti žmogui ir kaip viskas bus užregistruota.
- pradėti nuo dažniausių pasikartojančių klausimų
- duoti agentui tik reikiamas prieigas
- loguoti šaltinius ir veiksmus
- nustatyti aiškią žmogaus eskalaciją
Pavyzdys: agentas gali rasti kliento planą, patikrinti incidento statusą ir paruošti atsakymą, bet pinigų grąžinimą arba sutarties keitimą palikti žmogui.
KUR PASISLĖPUSI RIZIKA
Rizika – pastatyti gražų chatbotą, kuris neturi ryšio su tikrais duomenimis. Tada jis tampa mandagiu spėjiku, o ne pagalbos sistema.
Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Paimkite 20 paskutinių supporto klausimų ir pažymėkite, kuriems reikia tik žinių bazės, o kuriems reikia prieigos prie sistemos. Čia ir prasideda agento dizainas.
Šaltinis: Amazon Web Services.
DUK
Kas yra AWS supporto agentas?
Tai pavyzdinis Bedrock AgentCore sprendimas, jungiantis DI samprotavimą, dokumentaciją ir supporto įrankius.
Kodėl reikalingas auditas?
Kad būtų aišku, kokiais šaltiniais agentas rėmėsi ir kokius veiksmus atliko.
Ar tokį agentą galima paleisti iš karto klientams?
Pirmiausia verta testuoti su vidine komanda ir ribotomis teisėmis.
Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
