Программное обеспечение для служб поддержки
Remedy у вас работает, но вендор ушёл: ни патчей, ни поддержки, ни людей, кто в этом разберётся. Разбираем, как переезжать — тащить старый кастом с собой или начинать заново.
Привет, Хабр! Меня зовут Илья Парамошин, я ведущий инженер в МТС Web Services. В прошлый раз я рассказывал об архитектуре RAG-помощника для технической поддержки: индексации Confluence и Jira, гибридном поиске, генерации ответов с цитатами и оценке качества поиска. А недавно мы опубликовали продолжение — о том, как построили ИИ-агента для анализа тикетов.
После внедрения RAG инженеры стали быстрее находить инструкции и регламенты, однако расследование инцидентов требовало также работы с логами, базами данных и Jira. Мы не стали переписывать RAG, а начали развивать его как платформу вокруг трех задач: единый интерфейс, доступ к эксплуатационным данным и автоматизация анализа тикетов. Поиск остался ядром, но вокруг появились сервисы для интерактивного и фонового использования. Теперь подробнее разберем архитектуру, причины, по которым вынесли компоненты, и путь тикета от создания до комментария.
Полгода-год использования — и уже пора жалеть, что купили не тот хелп деск. Такое может произойти, если пасть жертвой маркетинга не проанализировать свои процессы и не подобрать систему именно под них.
В этом обзоре поможем разобраться, на что обратить внимание в первую очередь при выборе решения, а в какие детали стоит углубиться после первичного отсева. И да, скажем сразу: мы — команда ITSM 365. Свой продукт тоже включили в топ help desk систем, при этом для сравнения использовали единые критерии и открытые данные.
Привет! Меня зовут Владимир Дробот, я SRE-лид и руководитель центра техподдержки кластера рекламных технологий компании МТС Web Services. Наша команда отвечает за вторую линию саппорта: мы разбираем сложные инциденты, ищем корни проблем и передаем разработчикам те баги, которые упираются в код или архитектуру.
Для решения задач инженерам приходится работать одновременно с Jira, Confluence, логами и базами данных. Несмотря на существующую документацию, много времени уходило на поиск информации и анализ уже решенных инцидентов. Недавно мы внедрили систему поиска на базе RAG: общее описание и технические детали. Наше решение объединило данные из Jira и Confluence в единую поисковую систему, инженеры получают ответы на вопросы на естественном языке.
Подход дал заметный эффект, однако со временем стало понятно, что основное ограничение заключается не в качестве поиска. Чтобы получить пользу от RAG, инженер должен сначала понять, что именно искать. Это особенно актуально при разборе инцидентов: причина проблемы неизвестна и непонятно, какие данные понадобятся для анализа и какие запросы следует сформулировать. В результате инструмент использовали не во всех типах задач.
Кроме того, было сложно объективно оценивать влияние решения на качество поддержки. Мы получали положительную обратную связь, но не могли точно измерить, насколько быстрее или качественнее стали решаться тикеты. Тогда мы решили: если система уже умеет искать информацию и анализировать найденные материалы, почему бы не поручить ей первый этап расследования инцидента целиком?
Стоимость поддержки кажется простой: есть зарплаты, есть число обращений — поделили и готово. На практике эта цифра занижена в разы, потому что половина затрат на тикет не попадает ни в один отчёт. Разбираем, из чего складывается реальная стоимость обращения и как посчитать её для своей команды.
ServiceNow ушёл в 2022-м, но у многих он до сих пор работает - просто обновлять и продлевать его уже некому. При этом большинство компаний использовали платформу как обычный сервис-деск, переплачивая за десятки неоткрытых модулей. Разбираем, как выбрать замену под то, как вы реально пользовались системой, и не воспроизвести старый бардак на новом месте.
Портал есть, каталог на 200 услуг есть, база знаний есть. А сотрудник всё равно звонит на первую линию. Разбираем, почему так — и что реально меняет ИИ, честно, со слабыми местами.
Разбираем, как методология KCS и живая база знаний меняют техподдержку: онбординг с 12 до 3 месяцев и CSAT 97% на реальном кейсе.
Без 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, и по каким критериям можно подобрать себе решение.