Наблюдението на сервизни тикети за предстоящо забавяне е задача, която AI по своята същина може напълно да поеме. Тук не става дума за сива зона с придружаващ човешки надзор: самото сигнализиране е задача, която още днес може да бъде автоматизирана със съществуваща технология (rpa), стига няколко предварителни условия да са изпълнени.
Три оси са тук решаващи: структурираност, обем и пространство за преценка. И трите сочат в една и съща посока.
Структурираност (5 от 5). Задачата се състои в сравняване на дата с правило: колко дълго вече стои даден тикет отворен и кога изтича договореният срок за обработка? Това не е тълкуване, а изчисление. Системата за тикети регистрира момента на откриване, срокът по SLA е предварително определен, и единственото необходимо е сравнение между две числа. Веднага щом тези SLA срокове са еднозначно дефинирани, няма място за съмнение какво означава "предстоящо".
Обем (5 от 5). Екип за обслужване на клиенти обикновено обработва десетки до стотици тикети на ден, всеки със собствен часовник, който изтича. Ръководител на екип, който следи това ръчно, трябва постоянно да преглежда списък и да сумира. Това е точно видът повтаряща се, обемна работа, от която софтуерът не се уморява и не пропуска тикети.
Пространство за преценка (4 от 5). Самото сигнализиране изисква едва ли не никаква преценка: срокът си е срок. Има малка граница, защото някои организации имат нюанси (например: брои ли се времето на изчакване при клиента в SLA часовника или не), но веднага щом тези правила са фиксирани, няма повече място за тълкуване в самото сигнализиране.
Останалите оси тук са почти без значение за основния въпрос. Контактът с клиенти и физическите действия не играят роля при тази задача: става дума за фонов процес, не за разговор с клиент. Креативността не е на дневен ред: няма ново решение за измисляне, само срок за наблюдаване. Разходите от грешки и съответствието (compliance) получават средна оценка (3), не защото самото сигнализиране е рисково, а защото пропуснато или грешно известие може да се отрази на удовлетвореността на клиента или на договорните споразумения. Това не говори против автоматизацията, а по-скоро за правилно настройване предварително.
Подходящата технология тук е относително скромна: robotic process automation (rpa). Не е необходим езиков модел или сложен AI, за да се сравни дата с правило. Скрипт, който периодично изчита системата за тикети, изчислява оставащото време до крайния срок по SLA и при предварително зададен праг изпраща известие до ръководителя на екипа, върши работата. Това може да стане чрез имейл, дашборд уиджет или нотификация в самата система за тикети.
Предварителните условия са прости, но съществени: SLA сроковете трябва да са ясно и еднозначно определени, а сигнализирането трябва да е технически настроено въз основа на тези срокове. Ако липсва едно от двете, автоматизацията не работи добре — не защото задачата е неподходяща, а защото основата не е наред.
Този резултат важи за сигнализирането. Той не важи автоматично за това, което се случва след известието. При организация, където ескалирането на предстоящо забавяне веднага задейства фиксирано, предвидимо действие (например: тикетът автоматично се препраща към специалист), и тази следваща стъпка може до голяма степен да бъде автоматизирана. При организация, където ескалацията зависи от отношенията с клиента, вида договор или политическа чувствителност, тази следваща стъпка остава ръчна работа — там човешкият надзор над AI, конкретно е подходяща отправна точка.
Също и определението за "SLA срок" се различава според организацията. Компания с един прост, еднакъв срок за обработка има по-опростен въпрос за автоматизация в сравнение с компания с десетки договорни варианти, нива на приоритет и правила за изключения. Колкото по-сложен е този набор от правила, толкова повече подготвителна работа е нужна, преди сигнализирането да може да протича надеждно автоматично. Точно затова е нужен анализ по задача, а не по функция: една и съща длъжност "ръководител екип обслужване на клиенти" може при едната компания да включва до голяма степен автоматизируема задача за сигнализиране, а при другата — задача, която все още изисква голяма част ръчна работа.
Тази страница описва задача, не решение за персонал. Дали и как освободеният капацитет в даден екип се преразпределя, е избор, който принадлежи на самата организация и за който важат собствени законови изисквания, особено ако това има последствия за длъжности или щатно разписание. Внимателното отношение по този въпрос, включително информирането на представителните органи на служителите, е отделен процес — вижте например информиране на works council относно AI и внимателност при съкращаване на длъжности. Тази страница не предоставя обосновка за това, само факти за самата задача.
Сигнализирането на предстоящо забавяне на SLA не съществува изолирано. Подобни задачи за наблюдение и сигнализиране се срещат също при финансови процеси, като периодично фактуриране на абонаменти или обмен на цифрови фактури чрез е-фактуриране. И там важи: колкото по-структурирани са правилата и колкото по-голям е обемът, толкова по-подходяща е задачата за автоматизация.
Искате ли да разберете как стои въпросът за вашия собствен екип, включително точната структура на SLA и обема на тикетите, с които работите? Безплатният quickscan на ftetoai се състои от дванадесет въпроса, може да се направи без акаунт и дава индикация коя част от часовете във вашия профил днес може да бъде поета от AI. Пълният workscan, който навлиза до ниво задача във вашите собствени процеси, все още е в разработка — това обещание съзнателно не преувеличаваме тук.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.