Ранее я разбирал, как выбрать ITSM-систему и не наступить на грабли, а также анализировал ключевых игроков рынка ITSM.
Сейчас зайдём с другой стороны — а зачем этот ITSM нужен руководителю ИТ? Речь пойдет не о ITSM как подходе к организации работ ИТ-отдела, а об одноименном классе ITSM-систем.
Выбираете ли вы сервис деск для автоматизации с нуля или ищете замену текущему, это задача не из простых. Как не ошибиться и не потратить бюджет на продукт, который не оправдает ожиданий?
Познакомьтесь с нашим обзором: это не очередной рейтинг лучших от производителя сервиса, в котором ему гарантировано первое место. Перед вами — подборка популярных систем с четкими критериями сравнения, чтобы было проще выбрать ту, которая подойдет именно в вашем случае.
Привет, я Максим Королёв из Петрович‑ТЕХ, занимаюсь уровнем сервиса и тем, как ITIL/ITSM живут не только в регламентах, но и в интерфейсах для людей «с полей». В прошлых материалах показывал, как семейство ботов помогает автоматизировать ITSM и как «Дежурный» склеивает Telegram и MAX и встраивается в процессы ITIL 4. А про наш портал можно почитать тут.
В этой статье — кейс из строительно‑торговых центров: как бот «Рубик» стал интерфейсом service desk для сотрудников в зале и на складе и зачем ему вообще ITIL 4. Спойлер: SL решения сидел в районе 70%, и именно его получилось поднять выше 80% за счёт узкого набора сценариев из сервис‑каталога.
ИИ на службе... на службе технической поддержки. История про то, как использование больших языковых моделей помогло оптимизировать работу службы технической поддержки крупного Холдинга. А также размышления про то, к чему это может привести в итоге.
За типичной заявкой «не работает, посмотрите» может скрываться необходимость пересмотра архитектуры системы. В то же время, «добавьте мне новый процесс» нередко решается простой настройкой фильтров или прав доступа.
Где здесь проходит грань, за которую лучше не заходить без допаналитики? Почему ИИ-помощь в одних задачах повышает риск провала, а в других становится настоящим спасением? Покажем, как распаковывать запросы в поддержку, чтобы добраться до сути проблемы и не потратить лишние ресурсы — свои и клиента.
Официальный релиз ITIL Foundation (version 5) состоялся 12 февраля 2026 года, до этого была фаза раннего доступа для партнёров.
ITIL 5 позиционируется как «следующий шаг» после ITIL 4, а не как полное обнуление подхода: сохраняется преемственность моделей и терминологии.
ITIL 4 ещё некоторое время будет поддерживаться: предусмотрен переходный период и переходные экзамены, с планируемым выводом части модулей до конца 2027 года.
Всем привет, я Роман Басалыко. Последние двадцать лет работаю с командами продуктовой технической поддержки. Эта статья — попытка честно описать, почему одни команды масштабируются без потери качества, а другие нанимают людей и всё равно не справляются.
По данным индустриальных исследований, одна заявка, решенная без участия инженера техподдержки — экономит в среднем $15–20. При потоке в тысячи заявок в месяц это уже существенные цифры.
Есть три признака того, что в техподдержке что‑то системно сломано:
Первый — лучшие инженеры заняты самыми простыми вопросами: клиент привык связываться с конкретным человеком.
Второй — каждый новый сотрудник учится полгода‑год, прежде чем его можно отпустить в самостоятельную работу со сложными заявками.
Третий — SLA формально соблюдается, но нагрузка все равно растет, CSAT падает, команда выгорает в режиме аврала, уровень стресса зашкаливает, спешка влечет за собой ошибки и ситуация ухудшается.
Если хотя бы два пункта про вас — у вас есть проблема, и это проблема со знаниями.
Техподдержка работает, как пожарная команда. Работа хорошая, но как пожар, так хоть увольняйся.
Во многих компаниях привыкли: запрос на справки в бухгалтерию отправляют по электронной почте, заявки на ремонт оборудования — во внутреннем чате. Это работает, когда команда небольшая, но стоит ей вырасти до 200-300 человек, как всё рушится. Трудностей не будет, если вместо разрозненных чатов и реестра обращений в Excel внедрить комплексную систему управления услугами (ESM).
Без ITSM-системы IT-команда впадает в хаос: заявки на техподдержку теряются и путаются с запросами внутренних сотрудников, задачи на разработку продукта не отслеживаются, а руководитель не понимает, почему релиз обновления снова задерживается. Справиться с потоком задач и структурировать работу ИТ-отдела помогают ITSM-сервисы.
В статье собрали 11 ITSM-решений, которые помогут систематизировать работу ИТ-команды. Разобрали, как команде выбрать подходящую платформу.
Привет, Хабр! Меня зовут Светлана Долгополова. Я менеджер бизнес‑приложений в Ингосстрахе и уже несколько лет отвечаю за сопровождение систем и сервисов, используемых в нашей компании. Моя зона ответственности — стабильность работы сервисов на проде.
В 2025 году наша команда техподдержки столкнулась с ростом нагрузки в связи с увеличением количества поддерживаемых сервисов, а следовательно, и с ростом заявок.
Ниже — мой опыт участия во внедрении методов улучшения наших внутренних процессов работы с заявками и сокращения воронки обращений от пользователей.
Статья полезна для тем, кто отвечает за метрики поддержки и хотел бы их улучшить.
В поддержке запрос бизнеса очень прикладной: быстрее отвечать, делать меньше ошибок, выполнять SLA, выдерживать рост обращений при расширении каналов — почта, порталы, телефония. Компаниям нужно масштабировать сервис, сохраняя при этом стабильное качество. В статье о том, как они это делают.
Управленцы часто действуют интуитивно, пытаясь угадать, где «узкое горлышко», а ресурсы бросают на тушение самых сильных «пожаров», в то время как системные точки сбоев остаются не устранёнными. Результат — хаос, который съедает бюджет и демотивирует опытных сотрудников и снижает уровень удовлетворенности клиентов. Почему же так происходит?
В погоне за «идеальной» системой управления можно утонуть в море теорий, фреймворков и «суперпрактик». Новые подходы появляются каждый день, и в этой гонке легко забыть главное: даже самая продвинутая управленческая методика, в конце концов, основывается на трёх китах: планирование, координация, контроль. Это базовый минимум, который является фундаментом успеха руководителя.
Следовательно, решая управленческие и организационные задачи, в первую очередь, необходимо продумать реализацию и функционирование всех этапов управления. Данный принцип является фундаментальным, особенно при выборе управленческого инструмента, и в случае руководителя ИТ-подразделения таким выступает ITSM-система. Инструмент профессионального ИТ-директора должен поддерживать применяемую управленческую методологию и реализацию функций менеджмента, следовательно, информационная система управления обязана обеспечивать:
Сообщения на сайте, в VK или Telegram — управлять запросами из чат-ботов можно, интегрировав service desk с каждым каналом напрямую или через единую бот-платформу. У каждого подхода свои плюсы, и иногда заказчик не хочет «или-или» — ему нужны два способа одновременно.
Рассказываем на примере клиента, как он использует и прямую интеграцию с ботами и бот-платформу, а также чем отличаются популярные конструкторы ботов и какой из них выбрать.
Привет всем, кто заглянул на Хабр за чем-нибудь полезным под кофе
Устраивайтесь поудобнее — сегодня поговорим про ту самую работу, где в тикете пишут «Не работает принтер», без логов и деталей, а со стороны бизнеса уже «горит» и нужно «ещё вчера». Но вместо забегов по магазину — открываешь Kyocera NetViewer, подключаешься к устройствам и начинаешь разбираться, не вставая со стула.
В этой статье — мой взгляд на удалённую первую линию в ритейле через призму Kyocera NetViewer: как честно закрывать заявки, опираясь на статус устройства, сетевую доступность, события и базовые проверки, а не на марш-броски к каждому принтеру.
Разберём:
• что проверять в NetViewer в первую очередь (онлайн/оффлайн, ошибки, счётчики, состояние расходников);
• как по статусам понять, проблема на стороне устройства, сети или клиента;
• в каких случаях достаточно удалённых действий (перезапуск очереди, проверка подключения, базовая диагностика);
• и где проходит та самая граница, когда уже пора идти к принтеру, который жуёт бумагу и подозрительно пахнет гарью. Без занудной теории — только живой кейс, практические шаги диагностики через Kyocera NetViewer, немного самоиронии и мысли о том, как сделать так, чтобы уставал не ты, а только spooler
Привет, Хабр! Эту статью написал вендор ITSM-решений. Поэтому вы вправе ожидать толстого самопиара в духе «мы лучше всех, выбирайте нас». Но мы пойдем другим путем.
За годы работы накопились сотни разговоров с клиентами — кто уходил и кто возвращался. Мы научились видеть в этих историях закономерности, о которых в отрасли не принято говорить вслух.
В статье — откровенный разбор причин, по которым компании отказываются от привычного продукта в нашу пользу. А еще расскажем, по каким причинам уходят от нас, почему мы с этим не боремся и порой сами отговариваем клиентов от покупки нашего решения. Читайте, если уже задумывались о смене вендора.
Когда город засыпает, просыпается мафия ночная смена дежурки в технической поддержке «Золотого Яблока». Ночью интернет‑магазин продолжает жить своей жизнью: кто‑то оформляет заказ, кто‑то добавляет духи в избранное, кто‑то читает отзывы в приложении. А мы следим, чтобы всё это происходило без сбоев.
Customer Experience, или клиентский опыт, — это реальные деньги. Но многие западные B2B-компании и большинство российских до сих пор их упускают. Причина простая: CX все еще остается историей про улыбки, эмпатию и красивые слова в миссии компании.
Читайте статью, если хотите узнать, как разлочить потенциал клиентского опыта с помощью сервис деск системы и превратить его в измеримую пользу.
Российский рынок CRM заметно «расслоился» на два мира. Первый — массовые «коробочные» решения для малого и среднего бизнеса с быстрым стартом и относительно жёсткими сценариями. Второй — корпоративные CRM‑платформы, которые выбирают крупные компании: с длительным циклом сделки, сложной организационной структурой, кросс‑функциональными процессами, требованиями по интеграциям, безопасности и высокой нагрузке.
В этом материале я решил сделать обзор корпоративных CRM-платформ, способных оказать комплексный эффект на весь бизнес — не только на воронку продаж. Разобраться в особенностях каждой из них бывает непросто, и я надеюсь вам в этом помочь!
Мы отказались от формального деления команды на L1, L2 и L3. Разрешили инженерам брать задачи независимо от грейда. Не паникуем, если SLA горит красным. И знаете что? Это работает.
У нас в К2Тех есть собственный Центр экспертизы по комплексному сервису, который объединяет все направления техподдержки. От инженерных систем до инфраструктуры и ПО. Ну и конечно же, поддержку ИБ. Меня зовут Олег Лунгу, я руководитель группы инженеров технической поддержки К2 Кибербезопасность (входит в К2Тех). Сегодня расскажу, как вырастил команду с нуля до 30+ спецов, эффективно решающих задачи, которые мучают клиентов месяцами.
Система управления сервисами — универсальная таблетка для оптимизации сервисных процессов и способ вывести обслуживание бизнеса на новый уровень. Так говорят многочисленные маркетинговые материалы. А как на самом деле? Забегая вперед, скажу: во многих случаях — да, ESM / ITSM действительно полезны. Однако за красивыми цифрами часто скрывается сложный, а порой и болезненный путь. Многие проекты внедрения сталкиваются с неожиданными препятствиями, не достигают заявленных целей или, что еще хуже, создают новые проблемы и заставляют сотрудников искать обходные пути.
Я Сергей Вараксин — методолог-аналитик Directum, сертифицированный эксперт по ITIL4. В этой статье на примере реальных кейсов разберу наиболее распространенные причины, по которым система не оправдала ожиданий.
Я расскажу, почему даже технически грамотное внедрение может не принести пользы бизнесу, как методологические просчеты сводят на нет усилия команды и чего точно не стоит делать, если ваша цель — не просто запустить систему, а выстроить эффективную сервисную модель.
