Как я собрала AI-helpdesk поверх GLPI и Яндекс Мессенджера, когда в компании вообще не было системы поддержки

Когда компания небольшая, отсутствие helpdesk-системы почти не ощущается. Все писали мне напрямую, что-то решалось в мессенджере, что-то в личке, что-то на словах. Пока людей мало, это даже кажется удобным: быстро, без формальностей, “по-человечески”.

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

Нужна была нормальная система поддержки:

Последний пункт был для меня важным. Я не хотела заставлять людей идти в отдельный портал, регистрироваться, выбирать категории и “правильно” оформлять заявку. В компании уже привыкли писать в Яндекс Мессенджер — значит, логичнее было оставить этот канал входа, а helpdesk спрятать под капотом.

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

Так начался проект внутреннего AI-helpdesk.

В качестве основы я выбрала GLPI в self-hosted-варианте.

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

Плюс GLPI — это не только тикеты. В нём есть:

То есть это уже основа для построения полноценных ИТ-процессов внутри компании.

Для сотрудника всё выглядит просто: он пишет боту в Яндекс Мессенджере, как писал бы обычному человеку.

Дальше сообщение попадает во workflow, где система определяет, что с ним делать:

Снаружи это обычный бот в мессенджере. Внутри — несколько слоёв логики: часть работает по жёстким правилам, часть завязана на ИИ-компоненты.

Проект собирался на таком стеке:

Изначально план выглядел довольно компактно: n8n как оркестратор, GLPI API, Яндекс Мессенджер, несколько AI-нод — и можно быстро собрать первый рабочий вариант.

На практике всё оказалось менее аккуратно.

Для GLPI и Яндекс Мессенджера в n8n нет готовых встроенных нод, поэтому интеграцию пришлось делать через HTTP Request. Само по себе это нормально: настроить авторизацию, собрать запросы, обработать ответы, привести данные к нужному виду.

Но потом всплыла отдельная история с изображениями.

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

Но изображения из Yandex Messenger Bot API в n8n обрабатывались не так, как нужно:

Формально бот “умеет принимать картинки”, но в реальном пайплайне файл приезжал в таком виде, что использовать его дальше было неудобно.

В итоге я вынесла работу с изображениями в отдельный сервис на Node.js. Он занимается тем, что:

Это был один из первых моментов, где стало понятно: полностью no-code здесь не получится. Как только появляются нестандартные API, бинарные данные, MIME-типы, ретраи и нормализация, всё равно приходится писать код.

Со стороны внедрение ИИ-агента часто выглядит очень просто: пользователь написал сообщение, LLM поняла задачу, система что-то сделала.

Для обычного чат-бота такой подход иногда работает. Можно описать роль, тон общения, ограничения — и получить нормального собеседника.

В моём случае нужен был не собеседник, а часть helpdesk-процесса. Система должна была:

То есть это уже не “бот, который красиво отвечает текстом”, а система, влияющая на реальный внутренний процесс.

Сначала я пошла по очевидному пути: сделать одного умного агента, который будет принимать сообщение и решать, что делать дальше.

Довольно быстро начались проблемы:

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

Поэтому я разложила задачу на несколько специализированных ИИ-компонентов.

Вместо одного “главного мозга” появились отдельные роли.

Он определяет тип входящего сообщения.

Например:

Он делает краткое summary по комментариям тикета.

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

Этот агент работает, когда пользователь приходит с новой проблемой.

Он:

Отдельный агент работает с активными обращениями.

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

Этот компонент анализирует изображения:

Когда начинаешь собирать систему с ИИ, есть соблазн передать модели всё: классификацию, маршрутизацию, валидацию, работу с состояниями, выбор сценария.

Но это не всегда хорошая идея.

Со временем я начала выносить часть логики из ИИ в обычный код. Причины простые:

Например, через код лучше делать:

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

Отдельная большая тема — состояние.

В Redis я храню:

На бумаге это выглядит как техническая мелочь. В реальности без этого helpdesk-бот быстро начинает вести себя странно.

Что может пойти не так:

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

Я не хотела, чтобы бот просто отвечал “из головы”. Для внутреннего helpdesk это плохой вариант: ответы должны опираться на реальные инструкции компании.

Поэтому я собрала RAG-контур:

Это даёт несколько преимуществ:

Это не самая эффектная часть проекта, но одна из самых важных.

Пользовательские сообщения приходят в очень разном виде:

Перед тем как отдавать это ИИ, нужно привести данные к нормальному виду:

Если этого не делать, модель получает шумный ввод и начинает принимать нестабильные решения.

Отдельно пришлось долго настраивать поведение агентов.

Мне было важно, чтобы бот:

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

В проде всё иначе:

В начале это казалось простым workflow:

По факту получилось намного больше:

Главный вывод из этой части простой: AI-система в реальном процессе почти всегда сложнее, чем кажется на этапе идеи.

Для меня это был не просто проект “внедрить helpdesk”.

Здесь сошлись сразу несколько направлений:

Такие проекты хорошо показывают, что ценность не в том, чтобы “прикрутить ИИ”. Ценность в том, чтобы понять процесс, найти правильные точки автоматизации и собрать систему, которая будет работать стабильно.

Важно разделять:

После этого проекта я стала осторожнее относиться к идее “давайте внедрим ИИ во всё”.

Сначала стоит разобрать процесс:

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

ИИ хорошо подходит для:

Но если сделать LLM “мозгом всего процесса”, есть риск получить дорогую и нестабильную систему, которую сложно отлаживать.

Сейчас я продолжаю развивать этот helpdesk:

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