Добивки:
- Способност да се трансформираат долгите и расфрлани барања на клиентите во структурирани, акциони резимеа
- Способност за класификација на барањата според категорија, итност и расположение на клиентите со фиксна шема
- Способност да се дефинира конзистентен излезен формат (JSON/табела) погоден за автоматизација за масовно процесирање билети
Замислете утро на тимот за поддршка: 220 нови билети (билети) се акумулирани во текот на ноќта. Некои се еднолиниско „Ја заборавив лозинката“, некои се лути поплаки од три параграфи, а некои се всушност можност за продажба. Читањето низ овој куп, доделувањето на секој во правилната категорија, одредувањето на нејзината итност и насочувањето кон вистинската личност (ова се нарекува тријажа; истата логика на сортирање на пациентите по приоритет во собата за итни случаи) ги јаде првите два часа од денот.
Вештачката интелигенција (ВИ) може да ја заврши оваа работа за неколку секунди и постојано. Но, магијата не е во тоа што велите „резимирај го ова барање“; Наметнува фиксна листа на категории, јасни нивоа на итност и непроменлив излезен формат на моделот. Во оваа единица, ќе воспоставиме систем за тријажа што оди од обработка на едно барање до означување на стотици барања на начин подготвен за автоматизација.
Забелешка: Етикетите за категорија и итност генерирани од ВИ се прелиминарна алатка за проверка. Конкретно, барањата означени како „итно“ и „жалба“ мора да бидат потврдени од човек пред да бидат обработени.
Зошто структурно резиме?
Бесплатното резиме („клиентот има проблеми со својата испорака“) не може да се пребарува, сортира или автоматизира. Сепак, потребата од менаџерот за поддршка е јасна за следниве прашања:
- Во која категорија спаѓа ова барање? (Испорака, враќање, плаќање, технички, информации за производот, жалба, можност за продажба)
- Колку е итно? (Критично / Високо / Средно / Ниско)
- Каква е емоционалната состојба на клиентот? (Лут / Разочаран / Неутрален / Задоволен)
- Која е нејзината еднореченичка суштина?
- Кој треба да биде следниот чекор?
Откако ќе ги дефинирате овие прашања однапред и ќе му ги дадете на моделот како шема (константни полиња и можни вредности), сите 220 барања стануваат споредливи и филтрирачки во истиот формат.
Чекор по чекор: Воспоставување на шема за тријажа
- Закачете го списокот со категории. Не дозволувајте моделот да одговара; Дајте затворена листа.
- Дефинирајте го критериумот на итност. Конкретно што значи „критично“: услугата целосно запрена, губење на плаќањето, безбедносен ризик.
- Идентификувајте ги етикетите за емоции. Користете ограничен и јасен сет.
- Увезете го излезниот формат. За сериска обработка, JSON (формат на податоци за машинско читање кој се состои од парови на поле-вредност) е погоден, за едно барање, табела е погодна.
- Направете правило „штиклирајте ако не сте сигурни“. Ако моделот не е сигурен во категоријата, нека каже неизвесен и човекот ќе изгледа.
- Потврди. Во првата серија, рачно проверете ја точноста на етикетите и поставете го барањето.
Потсетници за копирање
Основен промпт кој конвертира едно барање во структурирано резиме:
Улога: Вие сте искусен специјалист за тријажа за поддршка. Анализирајте го барањето на клиентите подолу. Додадете коментар; само потпирајте се на она што е во текстот. Пополнете ги следните полиња:- резиме: (максимум 1 реченица)- категорија: [Испорака | Враќање | Плаќање | Технички | Информации за производот | Жалба | Можност за продажба]- итност: [Критична | Високо | Средно | Ниска]- емоција: [Лут | Разочарување | Неутрален | Задоволен]- следен_чекор: (една реченица, конкретно дејство)- несигурно: („да“ ако категоријата/итноста е нејасна, инаку „не“) Барање:"""{{ request_text }}"""
За сериска обработка, барањето конвертира повеќе барања во низа JSON одеднаш:
Обработете ги нумерираните барања подолу. Генерирајте JSON објект за секој со следнава шема и вратете ги сите како JSON низа. Одење надвор од шемата: { "id": "", "резиме": "", "категорија": "", "ургенција": "", "емоција": "", "next_step": "", "Не сум сигурен": "" }Само категории: испорака, враќање, плаќање, технички, информации за производот, приговори, поплаки. Барања: {{ numbered_request_list }}
Промптот што го појаснува критериумот за итност и го учи моделот на дефиницијата за „Критично“:
Определете ја итноста според следново правило:- Критично: услугата е целосно недостапна, губење на плаќање, ризик од безбедност/податоци, правна закана.- Високо: важна функција е прекината, но постои решение; лут клиент.- Средно: единствено прашање, не запирање на работниот тек.- Ниско: барање за информации, предлог, општо прашање. Напишете ја причината за вашата одлука во една реченица во полето „ургенција_причина“.
Промоција што ја доловува можноста за продажба и воспоставува мост за поддршка/продажба:
Кога го обработувате барањето, доколку клиентот покаже интерес за купување нов производ/пакет/додаток (на пр. „имате ли поголем пакет“, „колку корисници се потребни“), направете ја категоријата „Можност за продажба“ и додадете совет со една реченица за продажниот тим во полето „забелешка_продажба“.
Слаба навестување / Силен навестување
Слаба навестување
Моќен потсетник
„Сумирај го и класифицирај го ова барање“
Список на затворени категории + дефиниција за итност + фиксна шема JSON
Секој пат генерира различни етикети
Секогаш ја дава истата етикета на истото барање
Зборот „итно“ го употребува по сопствена желба.
Применува конкретни критериуми за „критични“
Тој го сочинува нејасното
emin_degilim: кажи да и остави го тоа на човекот
Доследноста е златното правило овде: ако истата жалба не спаѓа во иста категорија во два различни дена, ниедно известување и автоматизација нема да бидат сигурни.
Три мини футроли
Случај 1 - Доверлив критичар. Во една компанија SaaS (интернет изнајмен софтвер), пораката „Не можам да се логирам, целиот тим чека 40 луѓе“ изгледаше обична бидејќи беше кратка. Навестувањето за тријажа го означи како „Критично“ благодарение на правилото за итност (критериуми „услугата целосно недостапна“). Барањето беше обработено за 6 минути наместо да се чека 2 часа во редот; Спречено е прекршување на SLA (договор за ниво на услуга, т.е. ветеното време за одговор).
Случај 2 - Приоритизација на гневот. Еден ден, кога беа испитани ознаките за вештачка интелигенција од 180 барања, се виде дека 14 барања со емоцијата „Лут“ се ставени во посебна редица. Овие барања беа упатени до искусни претставници, а негативниот резултат од анкетата (CSAT, т.е. резултат за задоволство на клиентите) таа недела значително се подобри во споредба со претходната недела.
Случај 3 - Премостување од поддршка до продажба. „Мојот сегашен пакет е за 5 корисници, треба да го зголемам на 20 лица, дали е можно? AI ја означи пораката како „Можност за продажба“ и додаде белешка за продажба. Барањето автоматски падна на тимот за продажба; Можноста за надпродажба која би останала незабележана доколку била изгубена во стандардниот ред за поддршка стана добивка.
Совет: Чувајте ја вашата листа на категории што е можно пократка и дискретна. 20 категории ќе го збунат моделот (и вашиот тим); 6-8 јасни категории се означени поконзистентно и се значајни во извештаите. Комбинирајте две често збунети категории.
Поврзување со автоматизација
Вистинската моќ на структурираниот JSON излез е тоа што тој тече автоматски на следниот чекор: Барањето означено со „Критично“ веднаш го известува менаџерот, „Можност за продажба“ спаѓа во CRM (софтвер за управување со односите со клиентите), „Враќање“ оди во тек на самопослужување. Но, првото правило за автоматизација: активностите со големо влијание (рефундирање, затворање сметка) никогаш не се активираат само врз основа на ознаката за вештачка интелигенција; Понекогаш има човечко одобрување.
Внимание: Анализата на чувствата е предвидување, а не точно мерење. Купувачот кого манекенката го нарекува „Неутрален“ можеби е тивко многу лут. Користете ја ознаката за емоции за да дадете приоритет; но не се потпирајте само на него за да извлечете дефинитивни заклучоци како „овој клиент е веќе задоволен“.
Вообичаени грешки
- Препуштање на листата на категории на моделот; добивајќи различни, некомпатибилни етикети секој пат.
- Оставајќи недефиниран релативен збор како „итно“; Барањето на сите е итно.
- Непоправање на излезниот формат; Понекогаш се појавува став, понекогаш список наместо JSON.
- Не обезбедувајќи излезна врата за неизвесност (не сум сигурен).
- Поврзување трансакции со големо влијание (рефундирање, затворање сметка) со ознаката за вештачка интелигенција без човечко одобрение.
- Автоматизирање на целиот проток без рачно потврдување на првата серија.
Сумирано
- Тријажата брзо се подредува низ купот дојдовни барања по категорија, итност и емоции.
- Клучот за конзистентност: листа на затворени категории, конкретна дефиниција за итност и фиксен излезен формат (JSON).
- Етикетите за итност и емоции ја забрзуваат приоритизацијата; Покренува критични и лути барања.
- Структурираниот излез може директно да се поврзе со автоматизацијата (известување, рутирање, CRM).
- Дејствата со големо влијание и двосмислените етикети секогаш треба да подлежат на човечка проверка.
Задача за апликација
Сериски обработувајте ги 5-те различни барања на клиентите што ги имате (или примероци) со горенаведеното барање за низа JSON. Потоа рачно проверете го излезот: (1) Дали секоја категорија е точна? (2) Дали оние означени како „критични“ всушност ја прекинуваат услугата? (3) Дали сигурно кажав „да“ на вистинските места? Поправете ги сите ознаки што не одговараат и ажурирајте го промптот (особено дефинициите на категориите и правилото за итност) соодветно. Оваа вежба ја гради навиката да ја калибрирате шемата според вашата реалност.
листа за проверка
- [ ] Имам дефинирано затворена и дискретна листа на категории.
- [ ] Нивоата на итност ги опишав со конкретни мерки.
- [ ] Го поправив излезниот формат (JSON/табела).
- [ ] Додадов излезна врата поради неизвесност (I'm_unsure).
- [ ] Рачно ја потврдив првата серија и го калибрирав известувањето.
- [ ] Ставив слој на човечко одобрување на акции со големо влијание.