Инцидент е докладван, системата за тикети е в червено, а потребителите искат да знаят: какво се случва, колко още ще отнеме, и кога ще получат следващо съобщение. Това е работа, която служителите от сервизния деск и комуникациите извършват ежедневно. Въпросът тук не е дали AI може да пише текст, а дали AI може самостоятелно да поеме тази конкретна комуникационна задача. Отговорът: частично, и зависи силно от вида на инцидента.
Задачата получава висока оценка за структурираност (4): докладването на инцидент често следва фиксиран модел — какво не работи, откога, кои системи са засегнати, какво е очакваното време за отстраняване. Този модел е точно това, което езиков модел може да попълни добре, стига основната информация да е коректна. Също и физическият аспект (5) не е препятствие: не е необходимо действие в реалния свят, само текст, който трябва да бъде изпратен.
От друга страна, контактът с клиенти получава ниска оценка (1). По дефиниция това е комуникация с хора, които често вече са фрустрирани, защото работата им е спряла. Тонът, момента и точността на съобщението определят дали потребителите се чувстват изслушани или пренебрегнати. Генерирано съобщение, което е фактически коректно, но неправилно преценява спешността, причинява повече вреда от липсата на съобщение.
Разходите от грешки (3) са умерени, но не за подценяване: неточно време за отстраняване или статус, който не се актуализира, руши доверието и води до поток от последващи въпроси — точно работата, която сте искали да спестите. Съответствието с изискванията (compliance) (4) влиза в игра, когато инцидентът попада под споразумения за нива на обслужване (SLA) или, в някои сектори, задължение за докладване: тогава комуникацията трябва доказуемо да бъде изпратена навреме и по фиксирани стандарти. Пространството за преценка (2) и креативността (2) са ниски: има малко свобода сам да определяте какво съобщавате, това е основно следване на шаблон с актуални данни. Обемът (4) е висок: при голям инцидент става въпрос за стотици или хиляди потребители, които се нуждаят от едно и същото съобщение, и точно там автоматизацията освобождава време.
Три оси определят картината. Структурираността прави задачата технически изпълнима: ако статусът на инцидента е еднозначно фиксиран в системата, езиков модел може да изгради съобщение от него по фиксиран шаблон. Но ниският контакт с клиенти поставя ограничение върху това — не защото AI не може да напише коректно изречение, а защото рискът от неправилно време или неправилен тон на съобщението е по-висок, отколкото при вътрешен или административен текст. А разходите от грешки правят надзора необходим: актуализация на статус, изпратена преди потвърждаване на решение, или която подценява времето за отстраняване твърде оптимистично, води до нови оплаквания, вместо до по-малко.
Един пример прояснява ситуацията. При инцидент във вътрешна имейл система, където въздействието е известно и времето за отстраняване е разумно предвидимо, AI може да съставя първоначалното съобщение и междинните актуализации на статус на база тикета, като служител кратко одобрява преди изпращане. При инцидент, който засяга функционалността за плащане на клиентите, с финансови последствия и неясно време за отстраняване, ситуацията е различна: там е необходима човешка преценка за какво да се каже и какво не, и кога.
При компания със зряла статус страница и система за тикети, която автоматично попълва правилните полета, делът, който AI може да поеме, е по-голям: текстът може да идва директно от структурирани данни. При компания, където инцидентите се предават устно, в отделни Slack съобщения или чрез IT мениджър, който сам преценява ситуацията, липсва структурирана основа и има малко, което AI може да съставя самостоятелно. Също и естеството на потребителите има значение: вътрешни служители приемат кратка, фактическа актуализация; външни клиенти с договор и SLA очакват тон и пълнота, които по-скоро изискват човешки контрол.
Тази задача не е изолирана от останалата част на инцидентната верига. Доколко ефективно се комуникира инцидент, зависи от това колко добре се следят системните показатели — без надеждно наблюдение няма актуален статус, който да се комуникира. Зависи също от начина, по който инцидентът се регистрира и приоритизира, тъй като това определя какви данни са налични, върху които да се основе съобщение. И в някои случаи комуникацията се извършва паралелно с реалното решаване на IT инцидент от първа линия, при което актуализацията е толкова добра, колкото е реалният напредък.
Конкретно: съставянето на текст на база фиксирани шаблони, с актуалния статус на инцидента като входни данни, е изпълнимо, щом тези две предпоставки са налице. Решението кога се изпраща съобщение, с какъв тон, и дали времето за отстраняване е формулирано реалистично, остава при служителя. Това не е междинна фаза по пътя към пълно поемане — това е структурата, която подхожда на този тип комуникация, докато разходите от неправилно поставено съобщение остават по-високи от времето, необходимо за проверка.
Ако този анализ ви подтикне да обмислите наемането на служители от сервизния деск или комуникациите, важно е да се знае, че за това се прилагат собствени законови изисквания относно труда и участието на работниците; тази страница не дава съвети за персонал и не е обосновка за решение за уволнение. За по-широката внимателност около промените в длъжностите, вижте внимателност при съкращаване на длъжности.
Искате ли да разберете какъв дял от комуникацията при инциденти във вашата собствена компания вече днес попада в тези рамки? Безплатният бърз анализ на FTE TO AI се състои от дванадесет въпроса, не изисква акаунт, и дава индикация за какъв дял от часовете в този профил може да бъде поет от AI днес. Пълният работен анализ, с разширен анализ на задачите по екип, все още е в разработка — него съзнателно все още не предлагаме тук.
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.