Ад пытання кліента — да рашэння або перадачы спецыялісту

Пытанне ўзнікае пасля пачатку працы з сэрвісам

Уявім карыстальніка працоўнага анлайн-сэрвісу, у якога не з’явілася чаканая выгрузка. Ён звяртаецца ў падтрымку і апісвае праблему сваімі словамі. У паведамленні можа не быць назвы аперацыі, часу запуску або звестак пра тое, што ўжо было праверана. Асістэнту ў мадэльным сцэнарыі даручаецца ўдакладніць сітуацыю і знайсці прыдатны адказ, а пры неабходнасці перадаць зварот спецыялісту.

Вынікам можа стаць як рашэнне паводле інструкцыі, так і якасна падрыхтаваная перадача. Лічыць любую размову без аператара поспехам было б няправільна: кліент мог проста перастаць адказваць. Да ўкаранення вызначаюць, што служыць пацвярджэннем выніку, якія тэмы застаюцца па-за першай лініяй і ў які момант дыялог трэба працягнуць чалавеку. Карыстальнік таксама павінен разумець, што цяпер адказвае ШІ-асістэнт.

Удакладненні дапамагаюць выбраць адпаведны матэрыял

Пытанні будуюць вакол назіранай праблемы. Напрыклад, што карыстальнік чакаў убачыць, якая аперацыя была запушчаная і якое паведамленне з’явілася замест выніку. Не трэба паўторна пытаць тое, што ўжо ясна з размовы. Калі чалавек піша, што праверыў дзеянне паводле інструкцыі, карысней удакладніць вынік гэтай спробы, чым зноў паказаць той жа спіс крокаў.

Не ўсе звесткі дапушчальна атрымліваць у свабодным чаце. Паролі і іншыя сакрэты не патрэбныя для тлумачэння тыповай інструкцыі. Доступ да стану канкрэтнага ўліковага запісу разглядаецца асобна: перад выдачай такіх звестак павінны працаваць узгодненая праверка карыстальніка і правы. Калі неабходнага пацвярджэння няма, асістэнт тлумачыць даступны спосаб працягу без раскрыцця чужых даных.

Адказ павінен адпавядаць версіі і ўмовам

Для падтрымкі патрэбныя матэрыялы, за актуальнасць якіх адказвае ўладальнік прадукту або працэсу. У інструкцыі важна разумець прызначэнне: адзін парадак дзеянняў можа адносіцца да старой версіі, іншы — да асобнага рэжыму працы. Падобная фармулёўка пытання яшчэ не азначае, што знойдзенае рашэнне падыходзіць. Перш чым прапаноўваць крок, трэба суаднесці яго ўмовы з вядомымі звесткамі пра сітуацыю.

Калі матэрыял не пацвярджае адказ, асістэнт не дапісвае адсутную частку паводле агульных ведаў пра падобныя сэрвісы. Напрыклад, нельга абяцаць аднаўленне выгрузкі за пэўны час, калі такой умовы няма ў дзейнай інструкцыі. Пытанне можна ўдакладніць або перадаць спецыялісту. Гэта захоўвае межы паміж вызначаным парадкам падтрымкі і меркаваннем пра прычыну няспраўнасці.

Няўдалая спроба не павінна замыкаць размову

Пасля прапанаванага кроку важна даведацца, ці змяніўся вынік. Адказ «не дапамагло» становіцца новым кантэкстам, а не нагодай пачаць дыялог з першага пункта. Калі прадугледжаная іншая праверка, яе прапануюць з тлумачэннем мэты. Калі прыдатныя крокі вычарпаныя або сітуацыя не адпавядае інструкцыі, пераходзяць да ўзгодненага маршруту перадачы.

Прамую просьбу пра спецыяліста таксама ўлічваюць без прымусу да паўтарэння ўсёй анкеты. У рэзюмэ фіксуюць зыходную праблему, вядомыя параметры, выкананыя дзеянні і пытанне, якое засталося. Прычыну перадачы фармулююць прадметна: інструкцыя не падышла, патрабуецца даступная толькі супрацоўніку праверка або карыстальнік папрасіў чалавека. Гэта карысней за няпэўную пазнаку «складаны кліент».

Як выглядае перадача і яе статус

Спецыялісту, які прымае зварот, патрэбны кантэкст, што дазваляе працягнуць працу. У мадэльным сцэнарыі зварот можа паступаць у чаргу падтрымкі або сістэму ўліку заявак. Канкрэтны спосаб залежыць ад магчымасцей інструментаў і наладжанага падключэння. Да запуску правяраюць, якія даныя сапраўды прыходзяць супрацоўніку і ці можа ён адкрыць неабходную частку гісторыі размовы.

Асобна ўзгадняюць сітуацыю, калі свабоднага спецыяліста няма. Асістэнт павінен паказаць фактычны статус і прадугледжаны спосаб працягу: напрыклад, рэгістрацыю звароту для наступнага разбору. Ён не абяцае імгненнае падключэнне або тэрмін адказу без пацверджанай падставы. Калі сам запіс не ўдаўся, гэта таксама застаецца бачным; намер перадаць паведамленне нельга выдаваць за выкананую перадачу.

Паўторны зварот патрабуе захавання сэнсу

Кліент можа вярнуцца з тым жа пытаннем пазней або звярнуцца праз іншы канал. Тады карысна зразумець, ці працягваецца ранейшая праблема, ці з’явілася новая. Правілы супастаўлення абмяркоўваюцца адносна даступных даных і правоў. Нельга аб’ядноўваць гісторыі толькі праз падобнае імя або падобную скаргу: такое рашэнне можа звязаць звесткі розных карыстальнікаў.

Калі зварот распазнаны як працяг, у ім павінны захавацца папярэднія крокі і іх вынікі. Спецыялісту важна бачыць новыя абставіны, а кліенту — не праходзіць аднолькавыя праверкі без прычыны. Пры гэтым пацвярджэнне рашэння ў старым дыялогу не азначае, што новае паведамленне можна аўтаматычна закрыць. Стан пытання ацэньваюць паводле бягучага звароту.

Як праверыць, што падтрымка стала зразумелейшай

Для пілотнага запуску збіраюць звычайнае пытанне, зварот з няпоўным апісаннем, выпадак з састарэлай інструкцыяй і дыялог пасля няўдалай спробы. Асобна правяраюць запыт на аператара, недаступнасць чаргі і памылку стварэння запісу. Для кожнага прыкладу загадзя вызначаюць прыдатны адказ або маршрут. Праверка павінна выяўляць як няправільныя звесткі, так і прапушчаныя ўмовы перадачы.

Супрацоўнік падтрымкі ацэньвае атрыманае рэзюмэ: ці зразумелая праблема, якія крокі ўжо выкананыя і што трэба зрабіць далей. Разам з гэтым разглядаюць зваротную сувязь карыстальніка і выпадкі незавершанага дыялогу. Доля аўтаматычных адказаў сама па сабе не паказвае якасць дапамогі. У гэтым мадэльным прыкладзе не заяўленыя дасягнутыя паказчыкі; крытэрыі прыёмкі выбіраюцца для канкрэтнага працэсу.

Што падрыхтаваць для абмеркавання

Для размовы з ASK ARMONIVO падыдуць абязлічаныя звароты па адной групе тэм, дзейныя інструкцыі і апісанне таго, як кліент цяпер трапляе да спецыяліста. Адзначце, дзе паўтараюцца пытанні і ў якіх выпадках аўтаматычны адказ недапушчальны. Пасля ўдакладнення матэрыялаў, маршрутаў, правоў і даступных падключэнняў можна вызначыць склад укаранення ШІ-асістэнта для падтрымкі і разлічыць кошт.