Система этикетов выглядит аккуратно на бумаге. Вы получаете цифры, очереди, дашборды. Но в реальности эта модель измеряет боль лишь тогда, когда система уже дала сбой. Самая затратная часть проблемы обычно начинается гораздо раньше. Она начинается, когда сотрудник теряет 10 минут, потом 20, а затем просто сдается. Они пытаются снова. Они спрашивают коллегу. Они пропускают встречу или делятся не тем файлом, потому что привычный путь перестал работать. И это-то, чего большинство служб поддержки до сих пор не видят. Лучшая модель внутренней поддержки сегодня — это не ускорение сортировки заявок. Это полное устранение необходимости в такой сортировке. Представьте автономного агента в Microsoft 365, который очлеживает контекст, находит проблемы на раннем этапе и действует до того, как человек подумает об открытии портала. В этом выпуске я хочу показать, почему модель службы поддержки ломается, что ее заменяет и как управлять этим процессом без хаоса. Если эти изменения важны для вашей работы, подпишитесь на M365FM, ведь на уровень глубже реальная проблема не в очереди, а в модели, стоящей за ней. Смерть тикета. Старый процесс поддержки все еще повсюду. Что-то ломается.

Пользователь замечает это. Пользователь пытается объяснить проблему. Затем ИТ переводит это объяснение в категорию «Приоритет» и, возможно, группу назначения. Заявка попадает в очередь. Кто-то сортирует ее. Кто-то другой запрашивает больше деталей. Подключается другая команда. Время идет, а реальная работа стоит на месте. Этот процесс кажется нормальным, потому что он привычен, но привычное и эффективное — не одно и то же. Тикет — это не поддержка. Тикет — это доказательство того, что поддержка опоздала. К моменту создания тикета сотрудник уже столкнулся с препятствиями и потерял контекст задачи. Они уже переключили свое внимание с работы, которую пытались выполнить. Очередь — это не сервис. Очередь — это журнал сбоев. В крупных инфраструктурах Microsoft 365 ручная сортировка становится настоящим узким местом. Это происходит не из-за лени команд поддержки. Это происходит потому, что от людей требуют делать то, что уже не соответствует масштабу среды.

У вас больше пользователей, больше устройств, больше приложений, больше политик. У вас больше сложных случаев, затрагивающих команды, SharePoint, Exchange, InTune и Intra одновременно. Объем не просто растет. Растет количество комбинаций. Вот где старая модель ломается. Большинство команд реагируют добавлением новой структуры. Они создают еще один портал, еще одного бота или еще одно правило маршрутизации. Но в реальности это лишь добавляет еще один уровень между сотрудником и решением проблемы. Система все еще ждет, когда пользователь заметит проблему, опишет ее и правильно попросит о помощи. Работа начинается не на портале поддержки, а в Teams, в Outlook, в документе, который нужен прямо сейчас, или на собрании, которая начнется через 30 секунд. Именно там возникает потребность в поддержке, а модель тикетов полностью оторвана от этого момента. Скрытые издержки гораздо выше, чем показывают ваши отчеты по очередям. Людям приходится переключаться между задачами.

Дублирующиеся инциденты накапливаются под разными метками. Статьи базы знаний устаревают. Аналитики весь день занимаются сортировкой, маршрутизацией и уточнением вместо того, чтобы реально исправлять проблемы. Время решения растягивается, так как каждая передача задачи добавляет задержку, а каждая задержка стирает первоначальный контекст. Исследования в области агентного ИИ и IT-операции указывают на одну и ту же структурную проблему. По меньшей мере, 80% усилий все еще уходят на реактивную работу в стиле ITIL. Эта цифра важна, потому что она точно показывает, куда уходят трудозатраты. Они уходят не на обеспечение устойчивости или предотвращение, а на реагирование. Как только вы это видите, тикет начинает выглядеть не как операционная модель, а как симптом. Это симптом системы, которая реагирует только тогда, когда ущерб уже стал очевиден. Поэтому следующий вопрос не в том, как быстрее обрабатывать тикеты, а в том, что система должна делать до того, как тикет вообще понадобится. Модель невидимого

не просто очередной чат-бот поверх того же хаоса, и уж точно не более красивый фасад для все той же старой очереди. Сдвиг гораздо глубже, потому что невидимый сотрудник – это операционный работник, живущий внутри вашей среды Microsoft 365. У этого агента есть своя идентичность, определенный круг обязанностей, память о том, что он делал вчера, и строгие правила того, к чему он может и не может прикасаться. Это различие важно. Чат-бот ждет, пока вы введете запрос, а невидимый сотрудник следит за изменением условий. Он начинает с контекста, а не с разговора. Поскольку он видит состояние входа, работоспособность устройств, статус лицензий и способы обмена файлами, ему не нужно ждать появления проблем. Вместо того, чтобы спрашивать, чем он может помочь после поломки, он постоянно задает в фоновом режиме другой вопрос. Что отклоняется от состояния необходимого сотруднику для выполнения работы прямо сейчас? Именно здесь все меняется.

Модель внедрена непосредственно в саму работу. Когда кто-то присоединяется к собранию, избоит маршрутизация аудио, или гость не может открыть только что отправленный ему файл, старый мир создает отчет и передачу задачи. В новой модели агент мгновенно распознает шаблон, проверяет, соответствует ли условия известной проблеме, и выполняет следующее безопасное действие для ее устранения. Может быть, он сбрасывает путь или запускает проверку политик, или перенаправляет запрос и запрашивает МФА перед тем, как задокументировать исправление. Суть проста. Первый ответ больше не требует, чтобы человек читал расплывчатое описание и гадал, что произошло. Когда все работает хорошо, это кажется незаметным, ведь нет никакого зала ожидания и формы, пожалуйста, выберите категорию для заполнения. Поддержка выглядит как восстановление рабочего процесса. Сотрудник просто возвращается к работе, и во многих случаях он даже не видит, как работает механизм за кулисами. Вы уже можете видеть, как это меняет вашу логику подбора персонала. Старая модель нанимает людей для обработки объемов, сортировки запросов и устранения разрывов в контексте между разными командами. Новой модели нужно меньше людей на сортировке и больше тех, кто создает правила, определяет желаемые состояния и контролирует поведение агентов с течением времени. Люди остаются в системе, но весь характер их повседневной работы меняется. Исследования агентного и в поддержке постоянно указывают на это направление. Рутинная поддержка может перейти к управлению на основе исключений, что создает огромный прирост эффективности, когда среда и политики четко ограничены. Последнее крайне важно, потому что это не магия. Если ваши данные слабы, а процессы хаотичны, агент не станет умным только потому, что вы решили назвать его автономным.

Для меня все встало на свои места, когда я перестал думать об агенте как о функции ПА и начал рассматривать его как нечеловеческого сотрудника с пропуском. Настоящему работнику нужны личность, должностная инструкция, права доступа и менеджер, которому он отчитывается. Агенту нужно ровно то же самое, потому что ценность заключается в надежных действиях внутри системы, а не в умных фразах в окне чата. Невидимый сотрудник – это не трюк интерфейса. Это новый уровень поддержки, который следит за трениями в экосистеме Microsoft 365, действует в рамках политик и переключает внимание людей на исключения, требующие суждения. Как только эта модель становится ясной, следующий вопрос становится очень практичным. Как именно работает превентивность? Архитектура превентивности. Итак, как именно работает превентивность внутри Microsoft 365? Сдвиг происходит от запроса и ответа к анализу событий и оркестрации. Звучит технически, но модель проста, если ее разобрать. Сначала что-то меняется в среде, затем система интерпретирует, означает ли это изменение риск или отклонение, и, наконец, предпринимает одобренное действие, используя инструменты в вашем стеке. Начнем с уровня событий. Microsoft 365 уже создает сигналы повсюду. Интро очлеживает поведение при входе, а инчун – состояние и соответствие устройств.

Defender следит за подозрительной активностью, а Teams точно показывает, когда произошел сбой встречи или упало качество связи. SharePoint и Exchange раскрывают схемы доступа и активность с контентом, а сигналы о состоянии службы сообщают, когда проблема на стороне платформы. Если добавить к этому действия пользователей, у вас появится постоянный поток контекстных данных. Большинство организаций собирают эти сигналы, но лишь немногие используют их как систему поддержки. Сами по себе сырые события бесполезны, им нужен уровень логического анализа, чтобы упорядочить этот шум. Именно здесь невидимый сотрудник перестает быть имитацией автоматизации и начинает работать как реальный оператор. Агент анализирует сигнал, сравнивает текущее состояние с целевым и решает, какие действия можно безопасно предпринять. Проблема со звуком на встрече – это не то же самое, что рискованный вход, а неработающая ссылка отличается от несовпадения лицензий. Агент должен сначала классифицировать проблему, иначе действия без классификации лишь быстрее приведут к ошибкам.

Затем следует оркестрация. Как только агент понимает проблему, он может использовать подходящий механизм для ответа. Это может быть Power Automate для рабочих процессов, Copilot Studio для логики или Microsoft Graph для действий в системе и контекста. Инструменты важны, но самое главное – то, как они связаны друг с другом. Вы создаете не один умный запрос, а цепочку, которая может обнаруживать, решать, действовать и проверять. Эту последнюю часть постоянно упускают из виду. Самокорректирующаяся система не останавливается после выполнения действия. Она работает в цикле, обнаруживает проблему, тестирует условия, применяет исправление и проверяет результат, прежде чем записать итог. Исследования самокорректирующейся логики показывают, что такие системы работают через обратную связь и паттерны исправления, а не через один ответ языковой модели. Если первое действие не помогло, система должна оценить причину, чтобы скорректировать следующий шаг в рамках заданных ограничений. Это хорошо видно на примере нескольких сценариев в Microsoft 365. Когда пользователя блокируют из-за несоответствия лицензии и политик, агент обнаруживает проблему и проверяет нужный профиль роли. Он применяет допустимое исправление, подтверждает доступ пользователя и логирует изменения без участия человека.

Если в интро фиксируется рискованный вход, агент видит событие риска и немедленно сверяется с вашими правилами условного доступа. Он запрашивает дополнительную проверку или блокирует доступ согласно политике, а затем записывает результат для последующего анализа человеком. Когда устаревшая общая ссылка в SharePoint перестает работать, агент сравнивает текущий путь доступа с ожидаемыми правилами общего доступа. Он заменяет нерабочий корневой путь на корректный и отправляет исправленную ссылку в контексте, закрывая вопрос до того, как специалист техподдержки успеет прочитать тикет с пометкой «Срочно, проблема с доступом». Поддержка собраний – еще один отличный пример. Если устройство в переговорной выходит из строя или путь подключения обрывается за секундой до начала звонка, агент может обнаружить проблему и подтвердить сбой. Он выполняет безопасное действие по восстановлению и уведомляет организаторов Teams, предоставляя отчет о статусе прямо там, где ведется работа. Этот уровень взаимодействия – важнейшая часть архитектуры. Поддержка должна находиться там, где происходит сбой. Если ваша работа проходит в Teams, Outlook и рабочем пространстве M365, то и поддержка должна отвечать вам там же. Не стоит заставлять пользователя переходить в другие системы, если можно решить проблему прямо в контексте работы.

Все это не означает полную автоматизацию всех задач без исключения, так как это было бы опромечиво. Действия с низким уровнем риска могут выполняться автоматически, но значимые изменения все равно требуют подтверждения человеком. Путь для такого подтверждения должен быть частью архитектуры с самого начала, а не добавляться позже. Агент должен знать, когда действовать, когда спрашивать и когда именно остановиться. И как только вы внедрите это в рабочий процесс, дискуссия перестанет касаться только функции автоматизации. Она перейдет к вопросам контроля, управления, доверия и идентификации агента. Когда поддержка начинает действовать самостоятельно, сразу возникает сложный вопрос. Кто на самом деле выполняет эту работу? Если ответ на него расплывчат, вся модель рушится. Агент не может существовать в вашей среде как некий абстрактный помощник с широким доступом и без четкого владельца. Ему нужна полноценная учетная запись в интро. Ему нужны назначенный владелец, определенная область действия и жизненный цикл, который начинается и заканчивается по конкретной причине. Если агент может читать данные, запускать рабочие процессы или писать пользователям, вы должны управлять им как полноправным участником арендатора. Нельзя относиться к нему как к функции, которую кто-то включил и забыл.

Именно поэтому идентификация агента так критически важна для системы. Вы должны точно знать, что это за агент, каким системам он имеет доступ и кому поступит звонок, если что-то пойдет не так. Принцип минимальных привилегий должен стать здесь основой. Нельзя довольствоваться общим доступом ради удобства или обещать себе, что вы ограничите разрешение позже. Поскольку зона поражения агента поддержки полностью зависит от его разрешений, проектирование этих разрешений является ключевой частью проектирования поддержки. Агент 365 служит необходимым уровнем контроля в этой системе, поскольку позволяет полностью контролировать весь парк агентов. Он предоставляет реестр, рабочие процессы согласования и шаблоны политик, которые обеспечивают безопасность работы. Хотя эти элементы могут показаться административной рутиной, они решают огромную структурную проблему. Большинство организаций испытывают трудности не из-за нехватки функций и, а потому, что они не видят и не контролируют то, что уже работает в их среде. Исследования по этому вопросу однозначны. Лишь небольшое число крупных предприятий могут полностью инвентаризировать каждого агента, работающего в их системе в данный момент. Прежде чем руководители начнут говорить о масштабировании автономной поддержки, им нужно ответить на гораздо более простой вопрос.

Знаем ли мы вообще, какие агенты существуют и чем они занимаются прямо сейчас? Надзор также должен соответствовать уровню связанного с ним риска. Агент личной продуктивности, работающий в узкой нише, это одно, а агент для совместной работы с общим контентом – совсем другое. Кроме того, существуют корпоративные агенты, выполняющие действия в критически важных процессах, что относится к иной категории риска. Вот почему модель зон риска – личная, совместная и корпоративная – так важна. Ваша модель контроля должна усиливаться пропорционально возможному воздействию. Если вы относитесь ко всем агентам одинаково, низкорисковая работа застревает в долгих согласованиях, а высокорисковая проходит без должного внимания. Как минимум, ваш стэк контроля в Microsoft 365 должен быть знаком вашей команде. Вы используете идентификацию в интро, границы данных через первью и мониторинг через Defender. Вы применяете условия доступа через условный доступ и обеспечиваете встроенную возможность аудита с самого начала. Вы должны иметь возможность точно восстановить произошедшее, не гадая после того, как случился инцидент. Человеческий контроль должен быть заложен в логику, а не импровизироваться во время кризиса. Действия с высоким уровнем воздействия всегда должны ожидать подтверждения человеком. Обоснования должны записываться в форме, которую люди могут реально проверить и понять. У вас должны быть пути отката еще до того, как начнет выполняться первое автономное действие. Если агент обновляет доступ или меняет политику маршрутизации, у кого-то должна быть возможность отследить это решение и корректно отменить его. Есть еще один фактор, который руководители часто упускают из виду, потому что ранние демо-версии выглядят так хорошо. Стоимость переделки. Если агент создает циклы доработки для вашей команды, прогнозируемая экономия мгновенно исчезает. Это налог на переработку. Это время, затрачиваемое на исправление ошибок, отмену неверных действий или устранение непредвиденных побочных эффектов. Если ваша команда экономит 10 минут на выполнении, но тратит 8 минут на разбор последствий, вы на самом деле не автоматизировали поддержку. Вы просто переместили трудности в другую часть процесса. Доверие не возникает из красивых презентаций с политиками или громких анонсов запуска. Оно появляется на основе доказательств в процессе работы.

Людям нужно видеть, что видел, агент, какие решения принял и что именно изменилось в системе. Именно так вы строите доверие к автономной поддержке. Доказательства должны заключаться в поведении инструмента, а не в брендинге проекта. Как только фундамент управления станет прочным, разговор наконец перейдет с жаргона безопасности на язык бизнеса. Что это на самом деле меняет для итоговой прибыли? Новый ROI невидимой поддержки. Когда руководители принимают модель контроля, финансовые вопросы начинают меняться. В старой модели ценность поддержки измеряется видимой работой, закрытыми тикетами, звонками и соблюдением SLA. Эти цифры все еще важны, но они описывают лишь реакцию на проблему. Они не показывают, сколько сбоев не попало в очередь или сколько времени сотрудников было сохранено, потому что проблему устранили сразу. Это главная проблема учета. Невидимая поддержка создает ценность через свое отсутствие. Вы видите ценность, когда нет тикета, нет эскалации и аналитику не нужно 20 минут восстанавливать проблему по неполным заметкам. Если вы измеряете только видимые усилия команды поддержки, вы упускаете тот результат, который действительно хотели. Вам нужна стабильная работа с минимумом перерывов. Объем тикетов – слабый показатель, если рассматривать его отдельно. Падение числа тикетов может означать спад спроса, но также может означать, что среда стала здоровее, а поддержка умнее. Это две совершенно разные истории.

Руководителям нужен набор KPI, способный их различить. Начните с анализа коэффициента автономного решения. Речь не о том, сколько диалогов провел бот, а о том, сколько инцидентов было решено от начала до конца без участия человека. Вам также нужно отслеживать сокращение среднего времени решения. В средах и в процессах, требующих диагностики, улучшения часто составляют от 40 до 60%. Затем можно оценить стоимость одного решения и возвращенную продуктивность пользователей. Последний показатель легко пропустить, так как он не вписывается в стандартные отчеты службы поддержки. Однако именно в нем часто скрыта реальная ценность. Человек, заблокированный на 15 минут еще до того, как открыл тикет, уже создал убыток для компании. Если умножить это на срывы встреч и проблемы с доступом в крупной компании, скрытые потери гораздо выше, чем показывает очередь. Вот почему модель стоимости бездействия так важна для бизнес-кейса. Вы почитываете часы, потраченные наручные действия еще до начала формальной поддержки. Затем добавьте к этому стоимость ошибок и передела. Внезапно аргументы в пользу превентивных мер перестают звучать как теория.

Вы не просто финансируете футуристичный уровень поддержки. Вы избавляетесь от налога, который годами был скрыт в вашей повседневной работе. Экономика узкоспециализированных кейсов делает это еще более очевидным. Исследования агентской ИТ-поддержки оценивают работу человека примерно в 8,75 доллара за запрос. Напротив, стоимость обработки узкоспециализированным агентом может упасть ниже 50 центов, как только система будет внедрена. Это не значит, что любое обращение будет стоить так дешевой, поэтому лидерам следует осторожнее относиться к общим средним показателям. Качество телеметрии и управления всегда будут влиять на итоговую стоимость, но направление тренда очевидно. Это момент, когда ИТ перестает быть просто центром затрат. Это происходит не потому, что поддержка исчезает, а потому, что она превращается в уровень надежности, который фоново защищает продуктивность сотрудников. Бизнес ощущает это как более плавный рабочий процесс, а не как череду кризисных ситуаций. У вас меньше прерываний, быстрее восстановление и меньше труда тратится на маршрутизацию и уточнение. Тем не менее, плохие показатели могут легко создать иллюзию прогресса. Если телеметрия слабая, агент может просто быстрее резюмировать сбой, вместо того, чтобы предотвратить его.

Если переделки не отображаются на дашбордах, ROI будет выглядеть гораздо лучше, чем есть на самом деле. Если высвобожденное время снова уходит на низкоценные задачи, лидеры переоценят полученный эффект. Финансовое обоснование должно опираться на твердые факты, такие как предотвращенные инциденты и сокращение ручных операций. Необходимо измерять время, которое действительно вернулось в полезную работу. Как только вы начнете измерять это правильно, поддержка перестанет выглядеть как накладные расходы, которые нужно сокращать. Она начнет выглядеть как операционный ресурс, который бизнес наконец возвращает себе. Что это дает команде поддержки? Подумайте о том, как это влияет на сотрудников на местах. Этот сдвиг не столько о сокращении штата, сколько об изменении того, чем люди занимаются в течение дня. В старой модели большая часть ресурсов поддержки съедается сбросом паролей, маршрутизацией этикетов и бесконечными циклами уточнений. Люди тратят время на отслеживание обновлений и перенос данных между системами, которые никогда не были рассчитаны на взаимодействие. Ничего из этой работы не делает среду стабильнее, это лишь не дает очереди переполниться. Когда агенты берут на себя эту предсказуемую рутину, человеческие усилия наконец выходят на новый уровень. Инженеры поддержки начинают тратить время на определение того, что такое здоровое состояние системы и настройку логики согласований. Они фокусируются на улучшении баз знаний, тестировании политик и проверке того, чтобы агент оставался в заданных рамках.

Это совершенно другая работа, нежели целыми днями смотреть на темы писем и пытаться угадать, чего на самом деле хочет пользователь. Именно на этом этапе большинство внедрений заходит в тупик. Организации пытаются сохранить старые неэффективные процессы, просто добавив сверху агента и ожидая лучших результатов. Но процесс остается реактивным, передача задач запутанной, а база знаний слабой. Агент становится лишь еще одним слоем краски на разрушающейся стене. Он может быстрее ответить на вопрос, но не исправит модель поддержки, построенную на задержках. Лучший способ – сначала пересмотреть саму работу. Нужно решить, какие задачи останутся за людьми, так как они требуют суждения или деликатного общения. Затем решить, что перейдет в автономные потоки, где результат предсказуем, а действия безопасны. Это разделение жизненно важно, ведь команды поддержки никуда не исчезнут. Они просто станут людьми, которые проектируют системы контроля и обрабатывают исключения. Это значит, что и подход к обучению сотрудников должен измениться. Командам нужно учиться контролировать систему, а не просто выполнять ручные операции. Они должны понимать логику отката, аудита и то, как тестировать агента перед запуском. Они также должны видеть, когда модель дает сбой, ведь плохой рабочий процесс в автоматизации остается плохим. Он просто быстрее все ломает. Если вы нанимаете людей для такого будущего, вам вряд ли нужен очередной специалист широкого профиля для разбора этикетов.

Вам нужен тот, кто сможет выстраивать потоки в стеке Microsoft 365 и определять правила контроля агентов. Вам нужны люди, которые улучшат среду так, чтобы спрос на поддержку падал, а не рос. Как же начать это, не превращая все в масштабный многолетний проект по трансформации? Лучший шаг – выбрать один поток, который постоянно вызывает трение в вашей среде Microsoft 365. Восстановление доступа обычно отлично подходит, но можно рассмотреть поддержку встреч или передачу задач по комплайнсу устройств. Неважно, что вы выберете, главное, чтобы ситуация повторялась часто и вы точно знали, каким должен быть успешный результат. Как только цель ясна, нужно определить основы с железной дисциплиной. Вы должны знать, как выглядит норма и какие именно события сигнализируют о том, что все идет не по плану. Определите, какие действия безопасно автоматизировать и где именно должно начинаться вмешательство человека. Перед запуском обязательно зафиксируйте базовые показатели, количество тикетов, ручных операций и время ожидания решения пользователями. Вам также нужно внедрить систему управления с самого первого дня. Присвойте агенту четкую идентичность, назначьте ответственного сотрудника и установите правила утверждения действий. Каждое действие, которое выполняет агент, должно фиксироваться в журнале.

Также у вас должен быть план на случай вывода агента из эксплуатации, чтобы он не превратился в автоматизацию призрак. Как только первый процесс начинает работать, вся ваша операционная модель начинает меняться. Служба поддержки перестает быть просто стойкой регистрации, которая лишь реагирует на проблемы. Вместо этого она начинает действовать как механизм надежности, встроенный непосредственно в систему. Поддержка переходит от заметного реагирования к встроенному предотвращению проблем. Тикет никогда не был самой услугой. Он был лишь доказательством того, что услуга запоздала. Выберите один процесс поддержки в этом квартале и переработайте его для упреждения, а не реагирования. Если вам интересно узнать больше о М365 Капайлот, Азур, безопасности и операционных моделях, подпишитесь на М365FM и оставьте отзыв. Свяжитесь со мной, Мирку Питером, в LinkedIn и предложите следующую тему для разбора.