Help Desk Software *

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

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

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

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

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

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

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

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

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

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

Было дано: домен 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 на звонок

Привет, Хабр! Я — Настя Антоненко, менеджер продукта ITSM 365 HR. Мы с командой создаем решения для управления талантами.

Общаясь с HR- и IT-командами из разных компаний, я заметила, что айтишники и эйчары живут как будто в разных вселенных. Первые думают про ПО и техподдержку, вторые — про найм и вовлеченность. И часто это вызывает общие трудности.

Чтобы такого не было, нужно объединить процессы подразделений через автоматизацию. В чем здесь польза для руководителя IT, как это сделать с наименьшими усилиями, что поможет убедить HR-отдел — расскажу в статье.

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

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

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

Если внедрять и поддерживать ITSM-систему, обязательно столкнешься с заявками по ошибочно выбранным услугам и прочими неприятностями.

Привет, Хабр! Я — Ксения Попова, младший бизнес-аналитик в ITSM 365. Сейчас расскажу, как мы минимизируем проблемы в предоставлении сервисов.

Спрогнозировать ход масштабирования — задача, достойная оракула, но зачастую проблемная для ИТ-команд. Даже когда процессы обновлены и настроены, команда укомплектована нужными спецами, а все причастные люди работают слажено — всё равно что-то может сломаться: не в «человеческом» плане, так в техническом. 

Ранее мы рассказали, как в течение нескольких месяцев пошагово масштабировали техподдержку Сравни — меняли tone of voice, учили бота общаться по-человечески, специальным образом онбордили людей. Но всё это вряд ли бы нам пригодилось без технической возможности помогать клиентам — успешно закрывать обращения, которых в компании поступает полмиллиона в год. 

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

Сегодня мы запускаем Yandex Neurosupport — сервис, который генерирует умные подсказки для операторов контакт‑центра. Он выполняет функции второго пилота: нейросеть анализирует текстовые вопросы клиентов и предлагает оператору вариант ответа. В основе лежат облегчённые модели семейства YandexGPT, дообученные на инструкциях для операторов более чем 50 сервисов Яндекса. Cервис можно внедрить в свой интерфейс через Yandex Cloud по API или же развернуть в on‑premise‑окружении.

Технологическим ядром выступает RAG — звучит просто, но здесь не обошлось без добавления особой яндексовой магии. В этой статье вместе с ребятами из нашей команды ML B2B‑проектов, а также коллегами из команды базовой технологии, Yandex Cloud, «Маркета» и «Еды» расскажем подробнее, как вместе делали этот сервис и каких результатов достигли.

Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.

«А как настроить интеграцию?», «Где скачать последнюю версию?», «Скиньте инструкцию, пожалуйста»

Я возглавляю Customer Success и мы работаем бок-о-бок с Pre-Sale инженерами, поэтому эти и еще десятки подобных вопросов я видел в чатах сопровождения клиентов с момента их создания. Как только я пришел на эту позицию, в 2022 году, я сразу понял, что вопросы циклично повторяются от клиента к клиенту, при чем, связано это не только со сложностью продукта, но и с тем, что мы все привыкли получать готовую информацию.

В какой-то момент я подумал: «Почему мы не можем просто один раз четко описать решение и забыть про эти повторяющиеся вопросы навсегда?» Но было несколько нюансов:

История о том, как я перестал делать “PrintScreen → PowerPoint → Ctrl + V” и начал жить.

В своей прошлой статье я рассказал о том, как работал в стройке, перешёл в IT и через 3 года создал свой продукт, статья тут

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

И да, я написал его в одиночку с нуля и до текущего релиза 30.04.2025

Привет! Меня зовут Роза, я старший инженер инфраструктурной безопасности в Ozon Tech. В этой статье я расскажу о ключевых подходах к управлению учётными записями и настройке корпоративных устройств в нашей компании при onboarding (от англ. адаптация, далее по тексту — онбординг). Это может быть полезно вам, если вы занимаетесь аналогичной историей в своей организации. Вы узнаете про опыт Ozon, что мы имеем сейчас и как планируем адаптировать процессы онбординга к условиям удалённой работы и отсутствия централизованных инструментов управления ноутбуками, сохраняя при этом прозрачность.

В эпоху «удалёнки» контроль за учётными записями и настройка корпоративных устройств стали настоящим вызовом. Столкнувшись с ограничениями на использование специализированного ПО, многие компании оказались перед задачей: как организовать онбординг новых сотрудников, когда возможности централизованного управления через системы MDM (Mobile Device Management, далее по тексту — MDM) недоступны. Как подготовить ноутбуки и обеспечить безопасность, когда процессы, давно отлаженные для офисных условий, рушатся в реалиях дистанционной работы? В связи с этим компании вынуждены искать креативные и эффективные решения, чтобы обеспечить бесперебойную работу сотрудников, не снижая при этом уровень безопасности данных и защищённости инфраструктуры. Давайте начнём разбираться.

Автоматизация клиентской поддержки с помощью больших языковых моделей — перспективное направление, но без доработки они не всегда способны дать точные и релевантные ответы. Меня зовут Михаил Крюков, технический директор платформы Robovoice (SL Soft), и в этой статье я расскажу, как усиливать LLM с помощью RAG.

Используя реальный кейс, я расскажу о выборе LLM (сравнивали GigaChat MAX, GPT-4o, LLaMA 3.1 70B, YandexGPT 4 и Gemma 2 9b) и RAG (RagFlow, Dify и LangChain Custom + Vector database). Разберу ключевые сложности при интеграции — подготовку датасетов, настройку RAG, борьбу с «галлюцинациями» моделей, затрону вопросы экономики проекта и способов удешевления стоимости диалога. Статья будет полезна разработчикам и бизнесу, планирующим автоматизировать первую линию поддержки с помощью ИИ. Инфраструктура и железо в материале не освещены.