Help Desk Software *

Без ITSM-системы IT-команда впадает в хаос: заявки на техподдержку теряются и путаются с запросами внутренних сотрудников, задачи на разработку продукта не отслеживаются, а руководитель не понимает, почему релиз обновления снова задерживается. Справиться с потоком задач и структурировать работу ИТ-отдела помогают ITSM-сервисы. 

В статье собрали 11 ITSM-решений, которые помогут систематизировать работу ИТ-команды. Разобрали, как команде выбрать подходящую платформу. 

Привет, Хабр! Меня зовут Светлана Долгополова. Я менеджер бизнес‑приложений в Ингосстрахе и уже несколько лет отвечаю за сопровождение систем и сервисов, используемых в нашей компании. Моя зона ответственности — стабильность работы сервисов на проде.

В 2025 году наша команда техподдержки столкнулась с ростом нагрузки в связи с увеличением количества поддерживаемых сервисов, а следовательно, и с ростом заявок.

Ниже — мой опыт участия во внедрении методов улучшения наших внутренних процессов работы с заявками и сокращения воронки обращений от пользователей.

Статья полезна для тем, кто отвечает за метрики поддержки и хотел бы их улучшить.

Всем привет! Практически любая организация — от муниципалитета до стартапа — постоянно принимает поток разнообразных обращений. Навести порядок и ускорить их обработку можно с помощью простой заявочной системы: назначить ответственных, быстро подготовить нужные документы. Для этого подойдут готовые Helpdesk- или Servicedesk-системы, но их часто нужно интегрировать с уже имеющимися инструментами. Они хорошо работают для сложных бизнес-процессов с большими объемами заявок, но стоят дорого и требуют затрат на внедрение и поддержку. В общем, это развлечение для крупных и средних компаний. Для более простых кейсов можно собрать свою небольшую систему, используя no-code-платформы.

Меня зовут Иван, я бизнес-аналитик в MWS. В этом материале расскажу о реализации заявочной системы на платформе MWS Tables, где я взял на себя не только свою работу, но и функции всей команды — от архитектора до тестировщика. Таких примеров много, и на этом видно, как no-code и разумное использование нейросетей позволяют быстро автоматизировать бизнес-процесс и адаптировать его под меняющийся ИТ-ландшафт.

Привет, дорогой читатель! На связи Саша, системный администратор из отдела хелпдеска в ЮMoney, вот уже 20 лет как «тот самый шумный сосед» — барабанщик. Сегодня я приоткрою завесу нашей деятельности, возможно, вдохновлю кого-то на первый шаг в работе с «железом» — компьютерным или барабанным.

Как ни странно, но в обеих профессиях началось всё примерно идентично: меня привели, показали, и в моей голове прозвучала фраза: «Это то, чем я хочу заниматься».

Привет! Я Алексей, мне 31 год, и почти десять лет я работаю в ЮMoney — сейчас на должности менеджера по продукту. Как правило, крупные компании берут на такую позицию внешних кандидатов с опытом и наработанными твёрдыми навыками. У меня же опыта работы в этой сфере не было, зато я хорошо знал продукт благодаря многолетней работе в службе поддержки. Это и стало ключевым фактором при выборе кандидата.

Мой рассказ будет полезен тем, кто только начинает искать работу или хочет сменить профессию. Поверьте, лифт наверх работает. Расскажу, как из оператора я вырос до человека, который создаёт и развивает продукты для миллионов пользователей.

Привет, Хабр!

База знаний в поддержке почти всегда отстаёт от реальности: знания появляются в звонках, остаются в умах операторов, а в документацию попадают выборочно и с задержкой. При этом сами звонки уже записываются и транскрибируются.

В этой статье разберём инженерный способ автоматически извлекать из этого потока проблемы и решения и вести актуальную базу знаний с помощью Python, МТС Exolve и LLM.

Привет, Хабр! Меня зовут Илья Парамошин, я ведущий инженер в МТС Web Services. В первой части мой коллега Владимир Дробот рассказал, зачем нам понадобился ИИ‑помощник для техподдержки и почему мы выбрали архитектуру на RAG. В этой статье я раскрою техническую сторону и разберу, как мы собирали данные, выбирали эмбеддинги, настраивали поиск и какие подводные камни встретили на пути. Спойлер: без костылей не обошлось, но система работает в проде и ежедневно помогает нашим инженерам.

Привет всем, кто заглянул на Хабр почитать что-нибудь интересное!

Устраивайтесь поудобнее, сейчас расскажу про работу, где принтеры постоянно зажевывают бумагу, сканеры отказываются сканировать, а пользователи твердят, что они ни при чем.

Я собрал свой набор выживания для тех, кто работает на первой линии поддержки. Расскажу, какие встроенные инструменты Windows реально выручают, когда один простой батник может спасти ситуацию, и зачем нужны свои чек-листы, чтобы не сойти с ума от общения с техникой.

Никакой скучной теории, только реальные советы, маленькие хитрости и немного самоиронии от сотрудника техподдержки.

Привет! Меня зовут Владимир Дробот, я SRE-лид и руководитель центра техподдержки кластера рекламных технологий компании МТС Web Services. Наша команда отвечает за вторую линию саппорта: мы разбираем сложные инциденты, ищем корни проблем и передаем разработчикам те баги, которые упираются в код или архитектуру. 

Поиск нужной инструкции в заросшей документации Confluence и Jira — головная боль для многих команд техподдержки.Чтобы повысить эффективность работы, мы решили сделать собственного ИИ-помощника. Под катом расскажу, как нам удалось довести проект до прода, совмещая его с ежедневной рутиной, и что мы поняли после его реализации.

Текучка специалистов ИТ-поддержки в российских компаниях составляет 30–35% в месяц. Такую статистику показывают исследования 2024 года. Одна из главных причин — стресс. С ним сталкиваются 40–60% сотрудников поддержки. Половина из них готова уволиться из-за постоянного перенапряжения. Несмотря на неутешительные цифры многие организации воспринимают эту проблему как данность и не задумываются, какой ущерб она наносит бизнесу. В статье разбираемся, из-за чего возникают выгорание, текучка и как ESM-система помогает с ними справиться.

По мере роста компании поток обращений распределяется по разным каналам — почте, мессенджерам, формам на сайте — и быстро превращается в хаос. Мы начали искать HelpDesk, который можно развернуть у себя, без внешних сервисов и ограничений по лицензии.

Подходящих проектов оказалось немного: часть давно не обновляется, часть сложна в установке, а многие используют лицензии, которые затрудняют коммерческое применение. Анализ десятков репозиториев показал, что современных permissive-лицензированных HelpDesk-платформ почти нет.

Когда в компании несколько отделов, а IT-отдел тонет в хаосе заявок из Telegram, почты и личных сообщений — пора задуматься о системе, которая поможет контролировать все в одном месте. Подобрать подходящую Service Desk систему — первый шаг к порядку.

В этой статье разберем, что такое Service Desk система, чем она отличается от таск-трекера, почему ее путают с Help Desk, и по каким критериям можно подобрать себе решение. 

Привет, Хабр! Меня зовут Денис, я руковожу технической поддержкой в одной из крупнейших компаний России. Более 16 лет я работаю в IT, а последние годы занимаюсь управлением поддержки и автоматизацией процессов.

Хочу поделиться нашим опытом перехода на новый ИТ-стек, построенный на полностью российских решениях (Astra Linux, R7 Office, TrueConf и другие), и преодоления всех сложностей. Возможно, кого-то из вас это оградит от пары седых волос и сэкономит сотни часов работы поддержки.

Это мой первый подход в написании статьи, прошу не закидывать тапками. Статья вводная, но, если вам будет интересно, я готов рассказать про каждый инструмент подробнее.

Однажды в одной компании решили: «Сделаем процессы в ITSM-системе точь-в-точь такими, как в жизни! Только ни в коем случае не продумаем все как следует…» После этого их сервис деск задушили баги, а клиенты похоронили саппорт своими заявками. Бу!

Привет, Хабр, с вами команда ITSM 365. Мы собрали для вас рекомендации, следуя которым вы гарантированно превратите вашу сервисную систему в источник ужаса для бизнеса и пользователей. Пойдемте читать и бояться вместе.

Попробую описать свой опыт автоматизации своей (и коллег) работы на 2-ой линии техподдержки внутренних сотрудников.

Было дано: домен MS AD, около 4-5 тыс компьютеров сотрудников под управлением Win7-10. Задачей нашей группы поддержки было получение заявок от сотрудников и решение их проблем в процессе подключения к их рабочему столу (MSRA или Dameware) или без подключения (если это возможно).

На одном из проектов, мне требовалось постоянно собирать рутинно данные у удаленных клиентов, касательно их интернет-подключения и доступности серверов AWS. Я задумался написать простой скрипт, который сможет запустить каждый и отправить в техническую поддержку AWS, не отвлекая меня от важного безделья в поисках постоянной работы.

Это полный Python-скрипт для диагностики вашей сети. Программа собирает ключевые системные и сетевые метрики (IP-адреса, MAC-адрес, скорость загрузки/выгрузки, ping до шлюза и Интернета, а также потери пакетов) и сохраняет отчет в текстовый файл. В скрипте я конечно убрал внутренние ip адреса AWS и сменил на наш любимый ya.

В ходе одного из недавних собеседований, я столкнулся с нестандартной задачей. Вместо привычных вопросов о метриках, процедурах эскалации и методах решения инцидентов, мне предложили составить детальный план по формированию службы ИТ-поддержки в крупной компании, на первые шесть месяцев её существования.

Несмотря на то, что я обладаю практическим опытом создания технических команд с нуля, внедрения CMDB и разработки корпоративных регламентов, ранее эти процессы не были формализованы в виде единого стратегического плана. За 6,5 лет работы в холдинге FIBA Group, я глубоко изучил все этапы развития ИТ-команд и проектов изнутри. Данное тестовое задание стало для меня отличной возможностью систематизировать накопленные знания и представить их в виде структурированного документа.

Открыв свою любимую библиотеку ITIL 4, я начал обдумывать проект. У каждого проекта должны быть цели, а значит, и мне нужно их определить. Какими они могут быть для новой службы ИТ-поддержки? В первую очередь - достижение ключевых показателей эффективности (KPI).

Ежемесячно клиентская поддержка продуктов Яндекса обрабатывает миллионы обращений. Мы регулярно проверяем диалоги вручную. Это помогает бороться, например, с опечатками и другими ошибками операторов. Но проверить все диалоги в таком режиме невозможно — их слишком много. Поэтому мы решили посмотреть в сторону LLM-решений.

Привет! Меня зовут Дарья Шатько, я руководитель ML-группы в Yandex Crowd. В этой статье я расскажу, как мы с моим коллегой Антоном Удаловым внедряли большие языковые модели в контроль качества клиентской поддержки. А именно — почему регулярки и BERT не взлетели, как мы собрали репрезентативный golden‑датасет, как победили лимит контекста, снизили ложные срабатывания через многоступенчатый LLM‑flow и в итоге покрыли проверками абсолютно все диалоги поддержки.

Записная книжка в той или иной форме есть у любого человека — от реального молескина до Saved Messages в одном популярном мессенджере или заметок в каком-нибудь Google Keep. Если записи в этих носителях содержат важную для бизнеса информацию, её можно и нужно использовать шире, чем для одного только сотрудника.

Привет, Хабр! Сегодня покажем, как буквально за пару вечеров собрать систему, которая расшифровывает звонки, анализирует речь операторов и присылает руководителю отчёт в Telegram.

Например, в кол-центре с 15 операторами такая сводка поможет руководителю быстро понять, кто перегружен, где чаще звучит негатив, а кто просто слишком много говорит. Не надо слушать записи — отчёт сам всё рассказывает.

📊 Отчёт за 19 июля
🎧 Оператор дня: Иван Иванов (emotionScore: 0.42)
🥵 Больше всего негатива: Юлия Тестова (33%)
🗣️ Средняя скорость речи: 132 слов/мин
🤯 Самый «говорящий»: Андрей Максимов (74% времени)
🚨 Перебиваний в среднем: 2,7 на звонок