Как я собрала AI-консультанта для Instagram и Telegram: от первого сообщения до готовой заявки

Мне пришёл запрос на автоматизацию общения с клиентами beauty-бизнеса. На первый взгляд задача звучала довольно просто: нужен бот, который сможет отвечать на входящие сообщения в Instagram. Но когда я начала разбирать сам процесс, быстро выяснилось, что обычного сценария «человек написал → бот ответил» здесь недостаточно.
Клиент может написать:

«У меня появилась пигментация после родов. Что можно сделать?»

И дальше возникает сразу несколько вопросов.
Сколько лет клиенту? Какая зона беспокоит? Как давно появилась проблема? Что уже пробовали? Хочет ли человек просто получить информацию или уже готов записаться? Кроме этого, в beauty-бизнесе часто важно не просто рассказать об услуге, а показать релевантный пример результата. То есть не отправить человеку случайную красивую фотографию из папки «до/после», а подобрать работу, которая действительно похожа на его ситуацию.
А если клиент готов двигаться дальше — собрать контакт, удобное время и передать администратору уже не длинную переписку, а понятную заявку.
В результате задача «подключить бота к Instagram» превратилась у меня в такую цепочку:

Instagram / Telegram → анализ запроса → квалификация → подбор кейса → сбор данных → передача человеку.

Один из первых вопросов был техническим: как вообще подключить Instagram к системе. Основная логика у меня строилась в n8n. Для Instagram я использовала ManyChat как слой между Direct и workflow.
При этом я не хотела строить отдельного «Instagram-бота», а потом дублировать ту же систему для Telegram.
Поэтому архитектурно разделила две вещи:
канал, откуда приходит сообщение, и бизнес-логику, которая это сообщение обрабатывает.

В итоге вход мог прийти как из Instagram, так и из Telegram, а дальше система приводила сообщение к общей структуре и запускала один процесс. В workflow это действительно отдельный слой нормализации: сохраняются канал, идентификатор пользователя, текст сообщения, username и ID входящего сообщения. После этого диалог уже обрабатывается независимо от того, откуда пришёл клиент. Для меня это было важно ещё по одной причине.
Если завтра понадобится подключить третий канал, не хочется заново собирать всю логику квалификации. Должен меняться вход, а не вся система.

Следующая задача оказалась интереснее.
Клиенты не заполняют идеальные анкеты.
Они пишут так, как говорят:

«Мне 38, после родов появилась пигментация на щеках. Пробовала кремы, но особо не помогло».

Для человека здесь всё понятно.
Для автоматизации это пока просто строка текста.
Поэтому AI в этой системе не должен был сразу начинать «консультировать». Сначала его задача — разобрать сообщение и выделить из него структуру.

Система умеет извлекать:

Эти поля заложены непосредственно в workflow и дальше используются как состояние лида, а не остаются только внутри ответа модели.

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

Представим:
бот уже спросил возраст.
Клиент ответил:

«38».

Следующее сообщение само по себе почти ничего не означает.Но система должна понимать, что она ждала возраст, сохранить 38 именно в поле возраста и перейти к следующему недостающему вопросу. То же самое с зоной, длительностью проблемы, тем, что клиент уже пробовал, контактом и удобным временем.
Поэтому отдельно хранится conversation state: текущий этап разговора, уже собранные данные, отсутствующие поля и следующее действие.
И ещё важнее — новая реплика не должна случайно затереть то, что было собрано раньше.
В workflow для этого есть отдельная merge-логика: старые значения сохраняются, а новые добавляются только тогда, когда поле пустое или система действительно ждёт ответ именно на этот вопрос.

Получается уже не:

message → AI → reply

а:

message → existing state → AI analysis → merge → next action → reply.

И это совсем другой уровень задачи.

Я специально не отдавала модели полный контроль над сценарием. AI хорошо подходит для того, чтобы понять свободный человеческий текст:

«после родов», «примерно год», «под глазами», «ничего не пробовала», «можно завтра после трёх».

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

Например:
если не определена проблема → уточнить проблему;
если нет возраста → спросить возраст;
если нет зоны → спросить зону;
если не собран контакт → получить контакт;
если клиент готов записаться → двигаться к передаче человеку.

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

Для подобных систем мне это кажется намного надёжнее, чем пытаться решить всё одним большим prompt.

В beauty-тематике это особенно важно. Есть вопросы, на которые автоматический консультант не должен пытаться уверенно отвечать самостоятельно.

В моей логике needs_human включается, например, если человек:

Такие сообщения система должна не «докручивать до продажи», а передавать человеку.
Поэтому human handoff для меня здесь не запасной сценарий на случай ошибки.
Это нормальная часть архитектуры.

Когда первая часть заработала, возник следующий вопрос:

что именно показывать клиенту в качестве примера работы?

Можно было сделать просто: определить категорию «пигментация» и отправить первую фотографию из соответствующей папки. Но тогда никакого интеллектуального подбора по сути нет.
Я сделала отдельный case matching.
У каждого кейса есть параметры. У запроса клиента — тоже.
Дальше система рассчитывает соответствие.
В моей реализации больше всего веса получает совпадение категории. Дополнительно учитываются возрастной диапазон, зона, теги, подкатегория и наличие фотографий «до/после».Если совпадение недостаточно сильное, система не обязана показывать кейс вообще.

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

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

Само наличие хорошего case matching ещё не решало вопрос Instagram. Нужно было не только выбрать кейс внутри n8n, но и вернуть человеку:

Поэтому для Instagram появился отдельный media payload.
Система получает URL выбранного кейса, готовит изображения в формате, который дальше может обработать ManyChat, и связывает эти фотографии именно с текущим лидом и выбранным case_id.
Для Telegram отправка изображений идёт своим каналом.

То есть снова сработал тот же принцип:

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

Вот здесь AI уже не должен продолжать разговор бесконечно. Его задача закончена.

К этому моменту у системы может быть:

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

И дальше всё это собирается в handoff.

Не:

«В Instagram написал клиент, посмотрите переписку».

А примерно так:

Новый лид.
Категория: пигментация.
Возраст: 38.
Зона: щёки.
Что пробовал(а): кремы.
Цель: убрать пигментацию.
Удобное время: после 15:00.
Подобран кейс: …
Статус: готов(а) к консультации.

В моей реализации admin handoff собирается отдельно, а затем может уйти в Telegram. Параллельно для CRM формируется структурированная строка лида: канал, контакты, категория, цель, возраст, зона, история проблемы, удобное время, температура, причина handoff и выбранный кейс. На текущем этапе в качестве одного из слоёв CRM/storage я использовала Google Sheets.

Важно: это именно сменный слой хранения, а не центр всей архитектуры. Основной процесс от этого не зависит.

Если посмотреть только на интерфейс, всё выглядит довольно просто.
Клиент написал.
Получил ответ.
Ответил на несколько вопросов.
Получил подходящий пример работы.
Оставил данные.

Но внутри путь гораздо длиннее:

канал → нормализация сообщения → состояние диалога → AI-анализ → объединение данных → выбор следующего шага → case matching → ответ → фотографии → квалификация → handoff → CRM.

И вот здесь для меня этот проект стал особенно показательным. Сам AI оказался далеко не самой сложной частью.

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

Последний пункт особенно важен.

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

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

Потому что после этого техническая архитектура становится намного понятнее.
Не нужно спрашивать:

«Куда здесь добавить AI?»

Нужно спрашивать:

«Какое решение система должна принять на этом шаге и какие данные ей для этого нужны?»

Изначально запрос был про бота.
Но результатом стал не бот.
Получилась система, в которой:

Instagram и Telegram — каналы; AI — слой понимания; state — память текущего процесса; case matching — механизм подбора релевантного примера; правила — управление сценарием; human handoff — граница автономности; CRM — место, куда приходит уже структурированный результат.

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

что он сказал → что уже известно → чего не хватает → что показать → что сделать дальше → и когда передать работу человеку.