Как собрать MVP для аналитики тикетов с помощью ИИ и n8n

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

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

Это не продакшен-рецепт, а быстрый способ проверить идею без длинного цикла согласований и без вовлечения половины компании на старте.

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

Исходные условия: немного времени и неуемное желания

Есть понимание задачи, но нет желания превращать все это в полноценную разработку. Хотелось сделать максимум самостоятельно и по возможности в no-code или low-code логике.

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

Собственно, схема

Логика такая:

• CRM при закрытии тикета отправляет событие во внешний workflow;
• workflow принимает JSON с данными по тикету и переписке;
• из всего объема данных остается только то, что действительно нужно для анализа;
• очищенный текст передается в LLM;
• модель возвращает структурированное ревью;
• результат либо уходит в уведомления, либо сохраняется для дальнейшей аналитики.

Шаг 1. Понять, что нужен промежуточный слой

Поскольку задача завязана на событие, JSON из CRM, обработку данных и вызов модели, в качестве опорной точки был выбран n8n.

Шаг 2. Поднять self-hosted n8n

В чем плюс self-hosted n8n? Если идея зайдет, потом почти наверняка захочется хранить результаты, подключать базу, ставить аналитические инструменты и расширять сценарий.

Для этого использовали n8n VPS — сервер с автоустановкой Alpine Linux 3 + n8n.

Шаг 3. Научить CRM отправлять данные по закрытому тикету

В n8n был создан Webhook Trigger. CRM начала отправлять на него POST-запрос с JSON, в котором лежали данные тикета и переписка.

Со стороны бэкенда потребовалось минимальное вмешательство: по событию «тикет закрыт» отправлять данные на нужный URL. Где-то хватило no-code, где-то понадобилось минимальное вмешательство в код.

Шаг 4. Вытащить из JSON только важное

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

Чтобы не разбирать структуру вручную, JSON из webhook отправили в Claude и попросили помочь вытащить только нужное. Он предложил вставить в n8n узел Code (JavaScript) и дал готовый фрагмент кода для преобразования.

После этого вместо сырого объекта CRM появился нормальный вход для анализа.

Шаг 5. Подключить ChatGPT и заставить его играть в head of support

В workflow добавили ChatGPT через API. Для этого понадобился API-ключ и промпт с несколькими задачами. Для MVP хватило базовых критериев оценки коммуникации: tone of voice, ясность ответа, предполагаемая удовлетворенность клиента, качество закрытия обращения, комментарии по улучшению.

После этого n8n передавал в модель текст переписки, а модель возвращала нормальное структурированное ревью.

Шаг 6. Понять, что просто отправлять это в Slack не ок

Изначально результат хотели просто сбрасывать в Slack. Но довольно быстро поняли, что это не очень, если хочется не только читать отдельные кейсы, но и анализировать поток.

Решение: хранить результаты в базе, поверх подключить Metabase для визуализации и аналитики.

Шаг 7. Поднять базу и начать сохранять результаты

Рядом с n8n была поднята база данных. Для этого MVP выбрали MongoDB — как удобное документное хранилище для результатов анализа.

Дальше нужно было подключить MongoDB к n8n и решить, что именно писать в базу.

Здесь снова пригодился Claude: по скриншотам и описанию текущего flow он предложил добавить еще один преобразователь перед записью. Ответ модели нужно не просто сохранить текстом, а разложить по полям, чтобы потом с этим можно было работать.

Шаг 8. Подключить Metabase и посмотреть, что теперь с этим делать

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

Для этого рядом поставили Metabase.

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

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

Шаг 9. Прогнать финальный сценарий целиком

На финальном тесте вся цепочка уже работала end-to-end:

1. Тикет закрывается в CRM;
2. CRM отправляет webhook;
3. n8n принимает JSON;
4. Сообщения вытаскиваются и очищаются;
5. ChatGPT делает анализ;
6. Ответ преобразуется в структурированный результат;
7. Данные записываются в MongoDB;
8. Metabase получает материал для последующей аналитики.

Что оказалось самым важным на практике

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

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

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

Итог

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

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