Служба поддержки может блестяще укладываться в метрику SLA (service level agreement) и «закрывать» сотни чатов в день. Парадокс, но при этом обычно повышается температура: выгорают сотрудники, подгорает у клиентов и они уходят, и, как следствие, сгорает синим пламенем прибыль компании. Ещё один парадокс: это руководство компании само поставило специалистов в такие условия.
Продление договора — через три месяца, но поставщик знает уже сейчас, что вы никуда не уйдете. Это и есть vendor lock-in — зависимость от вендора. С ней сталкиваются гораздо чаще, чем принято думать.
Конечно, ITAM-специалисты могут заранее заметить надвигающуюся проблему: у них на руках данные по активам и договорам с поставщиками, статистика использования и календарь продлений. Проблема в том, что зависимость от вендора изначально чаще всего не воспринимается как риск — до того момента, когда уже поздно что-либо менять. Когда риск стал очевиден, простая процедура закупки ПО на замену текущему превращается в крупный проект, который требует отдельного бюджета, ресурсов и многоэтапного плана миграции.
Это руководство поможет выявить, разложить по полочкам и взять под контроль зависимость от вендора — до того, как она начнет управлять вашим бюджетом.
Мы все привыкли к классическому раскладу: для поддержки есть сервис деск, в проектных командах — Jira, у ИБ — свои системы. При этом одни и те же сотрудники могут решать заявки, участвовать в проектах и устранять инциденты — сами или совместно с безопасниками.
Когда эти процессы существуют по отдельности, данные разрознены, ответственность размывается, работа движется медленнее, растет риск ошибок. Гораздо лучше объединить эти три направления на одной платформе — ловкость рук и никакого соперничества между окнами систем за внимание специалистов.
Рассказываем, как такой подход работает на практике и почему единая система — это не печальный компромисс, а реальное усиление каждого процесса.
Искусственный интеллект перестал быть экспериментом, технология GenAI становится полноценным участником корпоративных бизнес-процессов. В ИТ-поддержке автоматически обрабатываются типовые обращения, HR-департаменты ускоряют онбординг новых сотрудников, бухгалтерия больше не вводит данные вручную. За этими результатами стоят инструменты для ИИ-автоматизации бизнес процессов: визуальные конструкторы, библиотеки готовых AI-инструментов, корпоративная память и автономные ИИ-агенты.
В этом материале разбираемся, как устроена ИИ-автоматизация изнутри: какие компоненты необходимы, как они взаимодействуют и почему создать интеллектуальный процесс можно без программистов — на примере GenAI-платформы SimpleOne.
В прошлом году публиковал статью «Как выбрать ITSM/ESM-систему: пошаговая инструкция, ошибки и лучшие практики внедрения на 2026 год». В этом же году продолжаю рассказывать о ITSM/ESM платформах.
В этом материале я хочу сравнить некоторые системы между собой. Сразу сделаю оговорку — несмотря на то, что я являюсь технологическим партнёром SimpleOne, обзор систем объективен. Мне не так важно, какую систему вы выберете — главное, пожалуйста, подойдите к этому серьезно: проанализируйте рынок, свои потребности, запросите референсы и внедрите систему качественно, чтобы она приносила желаемый результат.
«Сейчас выберем тот самый сервис деск и решим наши проблемы» — иногда кажется, что при внедрении нового решения или замене текущего именно так и рассуждают. Реальность готовит адептам этого подхода жесткую посадку. Мало подобрать систему под текущие потребности и учесть запас функций для роста — без аудита внутренних процессов старт затянется, а беспорядок не уйдет.
В статье расскажем, как не повторить распространенные ошибки и что нужно сделать перед запуском, чтобы не натягивать систему на неудачные паттерны.
Привет, меня зовут Дмитрий Крупенин. Последние 7 лет я занимаюсь созданием и развитием внутренних продуктов для крупных компаний. Я отвечал за распределение обращений в клиентском сервисе для одного биг.теха РФ, а сейчас помогаю строить распределение задач контента в рамках другого. Захотелось освежить все знания по этой теме, а заодно структурировать это в статью, которую вы сейчас и читаете.
В чем собственно вызов в этой области: современные алгоритмы назначения обращений операторам представляют собой критически важную технологическую основу для крупных компаний, обрабатывающих миллионы клиентских запросов ежемесячно. В условиях растущих ожиданий клиентов и необходимости обеспечения высокого качества обслуживания (при оптимальных для бизнеса операционных затратах) эффективность распределения обращений на подходящих исполнителей становится одним из ключевых факторов конкурентоспособности. Исследования (раз, два, три) показывают, что передовые AI-powered алгоритмы способны снижать время ожидания клиентов на 40-60%, повышать показатели решения с первого обращения до 85%, и одновременно оптимизировать загрузку операторов, предотвращая их выгорание. Давайте разберемся так ли это и как достичь таких результатов.
Как заставить поставщика признать ошибку и исправить её за два часа, а не за неделю, руководство для Jun-аналитиков.
Привет! Меня зовут Виктор Пантелеев, я менеджер технических проектов в Яндексе. Компьютер — основной инструмент большинства наших сотрудников. А для того, чтобы этот инструмент работал как надо, его следует настроить — быстро для конечного пользователя, в соответствии с его рабочими нуждами и требованиями безопасности.
Раньше этот процесс был исключительно локальным: настройка, или, как её ещё называют, наливка, осуществлялась только в офисах по локальной сети. Но сегодня мы можем настраивать ноутбуки и удалённо. О том, как и почему мы к этому пришли, а также об эволюции процесса я расскажу в этой статье.
Привет, я Максим Королев из Петрович-ТЕХ, занимаюсь уровнем сервиса. Моя роль — в том числе про “как хороший сервис показать пользователю, чтобы тот не отказался от нового/сложного/страшного инструмента”.
Было так: не все пользователи ходили в техническую поддержку по “правильному” маршруту, через портал. Из-за этого мы теряли случаи, составляющие общую картину проблем, и озадачились: как упростить пользователям заход в поддержку?
Решили сделать семейство Telegram-ботов, которые сократили время на создание повторяющихся задач на 50–70%, подняли заполняемость до 100%, ускорили реакцию на инциденты.
Если в новом году хотите запилить много микроавтоматизаций через боты, наш кейс к вашему столу: вот как вышло у Петрович-ТЕХа.
Год назад я обрабатывал тикеты по инструкциям. Сегодня анализирую логи, пишу SQL-запросы и разбираю баги с разработчиками. Как же я дошёл до жизни такой?..
Привет, Хабр! Меня зовут Азиз (по паспорту Жавлонбек, но с детства все зовут Азиз — спасибо старшему брату за второе имя, которое прижилось). Я младший специалист поддержки внутренних сервисов в Ozon. Начинал на L1, через год перешёл на L2.
Это история о том, как реально меняется работа при переходе с первой линии поддержки на вторую. Честный разбор, что изменилось, какие навыки понадобились и почему поддержка стала для меня фундаментом для роста в IT.
Привет, меня зовут Юля, я тимлид VIP‑поддержки в МТС Линк. Подобная работа, связанная с большим объемом коммуникаций, идеальна для выгорания. Так, например, нам может прилететь одновременно несколько обращений от разных клиентов с высокой степенью срочности, необходимостью глубокого погружения и поиска нетривиальных способов решения. В таких ситуациях замедляется первая и последующие реакции сотрудника, а выгорание и усталость приближается с космической скоростью.
В этом материале я опишу свой опыт борьбы с этой проблемой и расскажу, как мы действуем, чтобы не выгореть самой и не дать выгореть коллегам там, где все к этому располагает.
Недавно пришлось вспоминать, как считать необходимый размер ЗИП-склада. Казалось бы – чего там считать? А результат оказался не совсем интуитивным.
На совещании кто-то говорит: «Нам нужен Service Desk», другой возражает: «У нас уже есть Help Desk, зачем еще что-то?», третий вообще не понимает, в чем разница. Начинается спор, гуглят определения, цитируют ITIL, но в итоге остаются при своем мнении. Знаете что? За 10+ лет внедрений я видел эту дискуссию десятки раз. И у меня есть свое мнение на этот счет.
Сегодня разберемся раз и навсегда: Service Desk и Help Desk – это разные вещи или мы просто усложняем терминологию? Спойлер: возможно, различия не там, где вы думаете.
Привет всем, кто заглянул на Хабр в поисках чего-нибудь интересного под кофе!
Устраивайтесь поудобнее, поговорим про ту самую работу, где в тикете пишут просто «Не работает принтер», логов — ноль, деталей — ноль, а магазин уже горит и всем «очень срочно». И при этом ты сидишь в подсобке, смотришь в принт-сервер, веб-морду и RDP, и стараешься чинить всё, не вставая со стула.
В этой статье — мой взгляд на удалённую первую линию в ритейле: как по-честному закрывать запросы через логи, статус принтера и настройки на клиенте, а не марш-броском до каждой железки. Расскажу, что смотреть первым делом, как понять, что проблема ещё в софте, а когда уже пора реально встать и идти к принтеру, который жует бумагу и пахнет гарью.
Никакой занудной теории: только живой кейс из практики, рабочие шаги диагностики, немного самоиронии и мысли о том, как сделать так, чтобы уставал не ты, а только spooler.
Привет всем, кто заглянул на Хабр почитать что-нибудь интересное!
Устраивайтесь поудобнее, сейчас расскажу про работу, где принтеры постоянно зажевывают бумагу, сканеры отказываются сканировать, а пользователи твердят, что они ни при чем.
Я собрал свой набор выживания для тех, кто работает на первой линии поддержки. Расскажу, какие встроенные инструменты Windows реально выручают, когда один простой батник может спасти ситуацию, и зачем нужны свои чек-листы, чтобы не сойти с ума от общения с техникой.
Никакой скучной теории, только реальные советы, маленькие хитрости и немного самоиронии от сотрудника техподдержки.
Привет, Хабр! Я Дима, руковожу отделом информационных технологий бэк‑офиса в «Петрович‑Тех». Давно не делился историями, решил рассказать о нашем проекте по работе с восьмилетним HTML‑легаси, то есть порталом технической поддержки.
Обновление целой легаси‑системы, которая обслуживает тысячи сотрудников — та еще задачка. С одной стороны есть устаревший код и сервисы, с другой — непрерывная работа, которую нельзя тормозить: пострадают бизнес‑процессы. В этом кейсе расскажу, как мы обновили портал техподдержки, использовали ресурсы образовательных проектов для принесения реальной пользы, отбросили две ключевые, но ошибочные фичи, и поняли, что интеграция с AD стала главным приоритетом.
Классические подходы к управлению услугами трансформируются, чтобы соответствовать вызовам современных реалий. Давайте разберемся, в какую сторону идет ITSM / ESM и о каких тенденциях мы будем говорить ближайший год.
Когда в продуктовой компании растёт база клиентов, первая линия поддержки всё чаще решает не «где найти кнопку», а «почему сломалась интеграция с CRM» или «как правильно вызвать API, чтобы не уронить биллинг». В этот момент становится очевидно, что старый добрый «скрипт для колл-центра» из двух страниц в Word не работает: оператору нужно держать в голове архитектуру сервиса, бизнес-правила и десятки edge‑кейсов.
В сфере ИТ-услуг и в любом виде деятельности существует парадоксальное явление, которое называется «Эффектом арбузов» (The Watermelon Effect of SLAs). Представьте себе ситуацию: все метрики в норме, SLA выполняются, отчеты пестрят зеленым цветом, но пользователи недовольны. Именно это и есть «Эффект арбузов» – снаружи все выглядит хорошо (зеленый цвет метрик), но внутри скрывается совсем другая картина (заказчики недовольны, метрики красные).
В этой статье мы рассмотрим, почему возникает «Эффект арбузов», какие ограничения имеют традиционные SLA, и как современные подходы, такие как XLA (соглашения об уровне опыта), помогают преодолеть этот разрыв. Мы также обсудим, как внедрение клиентоцентричного подхода в ITSM и ESM может повысить качество услуг и удовлетворенность заказчиков.
