Привет, я Максим Королёв из Петрович‑ТЕХ, занимаюсь уровнем сервиса и тем, как ITIL/ITSM живут не только в регламентах, но и в интерфейсах для людей «с полей». В прошлых материалах показывал, как семейство ботов помогает автоматизировать ITSM и как «Дежурный» склеивает Telegram и MAX и встраивается в процессы ITIL 4. А про наш портал можно почитать тут.
В этой статье — кейс из строительно‑торговых центров: как бот «Рубик» стал интерфейсом service desk для сотрудников в зале и на складе и зачем ему вообще ITIL 4. Спойлер: SL решения сидел в районе 70%, и именно его получилось поднять выше 80% за счёт узкого набора сценариев из сервис‑каталога.
Где болит у «СТЦ»
В строительно‑торговых центрах (СТЦ) основная боль service desk не в том, что «люди не умеют писать в поддержку», а в том, что правильное обращение требует контекста, типа услуги и правильного заполнения полей, а у человека на точке под рукой чаще телефон, чем ноутбук с порталом технической поддержки. В зале и на складе полноценный веб‑клиент учетной системы не всегда доступен — зато мобильный мессенджер открыт почти всегда. До того, как мы запустили бота «Рубик», это выглядело так:
сотрудник формулирует что‑то уровня «не печатает», «очередь зависла», через портал ТП, который часто не под рукой
дальше начинается длинный цикл уточнений у пользователя, пока заявка не обретет нужный тип и поля
и только после этого инцидент можно честно закрывать «в срок»
Почему это ITIL 4, а не «просто бот»
ITIL 4 предлагает смотреть на услуги и потоки создания ценности, а не на набор разрозненных действий. Для сотрудника СТЦ ценность простая: увидел проблему → быстро и понятно передал → получил работающий сервис. Для service desk ценность другая: корректно зарегистрированное, классифицированное и измеримое обращение, доведенное до результата. «Рубик» закрывает типичный разрыв:
мессенджер остается удобным UX и точкой входа
Jira остаётся системой записи, маршрутизации и контроля исполнения
бот проводит пользователя по ветке сервис‑каталога, а на выходе рождается та же заявка, что и через портал, только без кучи уточнений
Практики ITIL 4, на которые опирается «Рубик»:
Service desk: единая точка контакта с точек СТЦ и стандартизированный прием обращение ake‑ Incident / service request management: правильный тип обращения и набор полей задаются сценарием, а не зависят от формулировки пользователем
Measurement & reporting: SLA считаются там же, где ведется учет — в Jira, без «теневой статистики» по чатам
Continual improvement: вместо попытки «оцифровать всё» выбран узкий хвост частых сценариев, дающих максимум эффекта при минимуме разработки
Как это устроено: сервис‑каталог, а не фантазия
«Рубик» не придумывает новые услуги и проблемы, он просто проводит пользователя по веткам, соответствующим строкам единого сервис‑каталога СТЦ: услуга → категория → тип запроса → ожидаемые сроки реакции/решения и целевой SLA.
Ключевой принцип:
каждый сценарий бота — это не отдельный мир, а тот же запрос в ITSM
пользователь мог бы создать его через портал, просто дольше и с большей вероятностью ошибки ввода
мы не добавляем еще один параллельный канал учета «в стороне», а облегчаем доступ к уже существующему сервис‑каталогу
В меню «Создать заявку в Техподдержку» для СТЦ есть крупные разделы: «Программы и сайт», «Оборудование», «Услуги», отдельно вынесены «Смена пароля» и возврат в главное меню. Основной измеримый эффект по SLA решения дали ветки «Оборудование» и «Услуги» — там сосредоточены частые и чувствительные по времени обращения «с полей».
Два типовых запроса «с полей» СТЦ
Торговый зал: электронная очередь
Для пользователя формулировка звучит примерно так: «Очередь/киоск ведёт себя неправильно, клиенты стоят». В боте это превращается в цепочку «Услуги → Электронная очередь → Проблема с услугой», дальше — короткое описание симптомов
Раньше такое обращение могло прийти в чат поддержки в любом виде: от «что‑то с очередью» до скриншота экрана. Инженер тратил время на уточнение места, типа и статуса — а заявка висела в неопределенном статусе. Теперь обращения сразу ложатся в правильный тип запроса в Jira, и решение занимает минуты, а не часы/дни через переписку.
Склад: принтер «перестал печатать»
Базовый запрос: «Не печатает, этикетки/документы встают, работа склада тормозит». В боте — сценарий «Оборудование → Оргтехника → Принтер» с обязательным указанием местоположения (№ Склада), описания (опционально) и, по возможности, фото/текста ошибки. Такой сценарий резко снижает количество уточняющих вопросов: инженер сразу понимает, где и какой принтер «упал», и может планировать выход или удаленную диагностику без длинной переписки.
Как устроен «Рубик» с точки зрения продукта и кода
«Рубик» — это клиент к уже существующему Jira Service Management. Telegram и MAX — два транспортных слоя, а общая логика живёт в core/. Обработчики Telegram (handlers/) и MAX‑адаптер (adapters/max/) занимаются кнопками, FSM и форматом сообщений, но создание заявок, проверки профиля и работа с Jira идут через единый слой core/support/api.py — чтобы поведение в мессенджерах не расходилось «по веткам». Интересным инженерным решением стало создание каталога форм в YAML + универсальный движок создания заявки. Типовые сценарии («ПК», «оргтехника», «сеть», «электронная очередь», почта и так далее) описаны в config/forms_catalog.yaml: там же лежат подписи для пользователя, привязка к portal/request type в Jira и правила маппинга полей. На основе этого core/jira_form_engine.py собирает запрос к API Jira так, как если бы пользователь заполнил нужную форму на портале — только данные он вводит по шагам в чате или бот сам подставляет их. В результате новый тип заявки для ТП чаще добавляется конфигурацией, а не отдельным «форком» логики под Telegram и отдельным под MAX. Отдельно стоит слой доставки уведомлений: core/support/delivery.py задаёт контракт «отправить сообщение пользователю», не зная, это Telegram или MAX. Так уведомления о статусах и комментариях не протекают в разрозненные реализации и проще сопровождать при добавлении каналов.
Один процесс, два поллинга: профиль пользователя и привязка номера телефона позволяют держать один человеческий контур даже если человек перепрыгивает между мессенджерами.
Без своего корпоративного мессенджера
Почему не делали через корпоративный мессенджер:
пользователь остается в привычном мобильном канале (меньше приложений, богу приложений!);
при этом не выпадает из ITSM‑процесса: заявка в Jira, нужные поля, отчетность и аудит — как принято в компании. Мессенджер не заменяет service desk, он делает создание обращения удобнее за счёт заранее заданной структуры. Канал общения становится частью потока создания ценности, а не обходным путём
SLA: что именно поменялось в цифрах
По ключевой для сервиса метрике SL решения (процент обращений, закрытых в согласованное время решения) до «Рубика» показатель держался ниже 80%. После внедрения он стабильно выше 80%: среднее за три месяца «до» — около 73%, «после» — около 83%, с пиком 85% в феврале. Если посмотреть на помесячные данные:
Месяц | SL реакция | SL решение | Решено в месяц поступления |
Октябрь 2025 | 96% | 66% | 86% |
Ноябрь 2025 | 98% | 75% | 90% |
Декабрь 2025 | 96% | 77% | 87% |
Январь 2026 | 97% | 83% | 96% |
Февраль 2026 | 98% | 85% | 92% |
Март 2026 | 99% | 81% | 94% |
SL реакции и до «Рубика» был сильной стороной (96–99%), так что узкое место было не в первом ответе, а в качестве и полноте данных, triage и доведении до результата. В таблице видна ступень: SL решения уходит в устойчивую зону выше 80%, при том что процесс регистрации и учёта остаётся тем же — меняется именно интерфейс для пользователя.
Итог
Мы не спорим с ITIL 4, а делаем его операционным на точках: сервис‑каталог задает язык услуг, Jira — язык учета, а «Рубик» убирает трение между ними. В цифрах это выразилось в том, что SL решения после внедрения стабильно перешагнул 80% при уже высоком SL реакции.
Если у вас в компании заявки приходят в виде «что‑то сломалось» — приглашаю обсудить в комментариях вашу боль. Возможно, структурированный прием обращения через мессенджер закроет узкие места и у вас. Готов ответить на вопросы по архитектуре и интеграции с Jira.