В первых двух статьях этой серии я рассказывал, как мы создавали собственного AI-ассистента для сайта.
В первой части мы собрали рабочую систему для MODX: посетитель может общаться с AI прямо на сайте, а когда разговор превращается в реальную заявку, информация отправляется владельцу сайта по email и в Telegram.
Во второй части мы подключили тот же самый AI-бэкенд к WordPress. В результате один Cloud Run + Groq сервис может обслуживать сайты на разных CMS.
Исходный код проекта открыт на GitHub:
Но во время реального тестирования обнаружилась ещё одна важная задача.
Что будет, если потенциальный клиент начал разговор, оставил свой email, но до финальной отправки заявки так и не дошёл?
Именно эту проблему мы решили в третьей части проекта.
Почему это вообще важно
Представим обычную ситуацию.
Посетитель заходит на сайт, открывает AI-ассистента и оставляет email. Затем начинает рассказывать о своей задаче.
Например:
Мне нужно доработать сайт на WordPress.
Ассистент задаёт дополнительный вопрос:
Что именно вы хотите изменить?
Но в этот момент человек отвлёкся, закрыл вкладку, потерял интернет или просто решил продолжить позже.
В старой версии системы для владельца сайта этот человек практически исчезал.
Email и Telegram отправлялись только тогда, когда AI понимал, что информации уже достаточно и заявку можно передать владельцу сайта.
То есть потенциальный клиент уже был у нас на сайте, уже оставил контакт — но мы могли о нём никогда не узнать.
Для lead-assistant это довольно серьёзная проблема.
Поэтому мы решили изменить сам принцип работы системы:
если человек уже оставил контакт, мы не должны его потерять.
Теперь запись начинается ещё до разговора с AI
Здесь есть важная техническая деталь.
Логирование начинается не после первого сообщения AI и не после финальной заявки.
Оно начинается в тот момент, когда посетитель вводит корректный email и нажимает кнопку Continue / Продолжить.
То есть ещё до первого вопроса к AI.
После проверки адреса система сразу записывает событие:
contact_saved
С этого момента контакт уже существует в журнале.
Если пользователь тут же закроет страницу, у нас всё равно останется его email и информация о том, с какой страницы сайта он начал разговор.
Когда посетитель отправляет первое настоящее сообщение ассистенту, появляется следующее событие:
first_request
А дальше возможны ещё два варианта:
handoff_success — заявка успешно отправлена владельцу сайта;
handoff_failed — AI попытался передать заявку, но ни email, ни Telegram отправить не удалось.
Получается довольно простая последовательность:
Email оставлен → разговор начался → заявка передана.
Причём даже если цепочка оборвалась на первом или втором этапе, информация уже не исчезнет.
Мы не стали строить полноценную CRM
Конечно, можно было сразу подключить базу данных, создавать карточки клиентов, статусы, задачи, менеджеров и превращать проект в маленькую CRM.
Но для моего AI-ассистента это пока было бы избыточно.
Задача гораздо проще:
увидеть всех людей, которые оставили контакт, и понять, что произошло дальше.
Поэтому события записываются в лёгкие JSONL-файлы.
Например:
2026-10-AILeadLogs.jsonl
Для каждого месяца создаётся отдельный файл.
У всех событий одного разговора есть общий conversation_id, поэтому просмотрщик может собрать несколько технических записей в одну понятную строку клиента.
В результате вместо набора событий мы видим обычные статусы:
- Contact only — человек оставил email, но не начал разговор;
- Conversation started — начал общаться с AI;
- Handoff failed — передача заявки не удалась;
- Sent — заявка успешно отправлена.
Для этой задачи такого подхода вполне достаточно, а сама система остаётся лёгкой.
Как это выглядит в MODX
Для MODX 2 и MODX 3 мы сделали отдельный просмотрщик обращений.
Он находится внутри защищённой части сайта и доступен только авторизованному администратору MODX с соответствующими правами.
Вместо чтения JSON-файлов вручную администратор видит нормальную таблицу.
В ней можно посмотреть:
email посетителя, дату первого контакта, страницу, с которой он пришёл, первое сообщение, данные собранной заявки и итоговый статус.
Также появились фильтры.
Можно выбрать год, месяц, статус, искать по email или тексту запроса и при необходимости выгрузить результат в CSV.
По умолчанию просмотрщик сразу показывает текущий год, поэтому после открытия не приходится каждый раз вручную выбирать нужный период.
Сам журнал хранится отдельно от обычного MODX error log. По умолчанию это:
core/cache/logs/ai-lead-assistant
То есть отладочные сообщения CMS и реальные обращения посетителей не смешиваются.
А как это работает в WordPress
В WordPress мы сделали тот же механизм уже в более привычном для этой CMS виде.
После установки плагина в админке появляется раздел:
Tools → AI Lead Log
Там находится такой же просмотрщик обращений.
Он умеет фильтровать данные по году, месяцу, статусу, контакту и содержимому запроса, а также экспортировать их в CSV.
Как и в MODX, по умолчанию открывается текущий год.
Настройки самого журналирования находятся здесь:
Settings → AI Lead Assistant
То есть владельцу WordPress-сайта вообще не нужно знать, где физически находятся файлы или как устроен JSONL.
Он просто открывает WordPress Admin и видит список обращений.
Мы специально не записываем всё подряд
При добавлении логирования легко совершить другую ошибку — начать сохранять слишком много информации.
Нашему ассистенту для восстановления потенциального клиента достаточно совсем небольшого набора данных.
Мы сохраняем контакт, страницу входа, первое обращение и основные данные заявки, если AI успел их собрать.
При этом журнал специально не сохраняет IP-адрес пользователя и User-Agent браузера.
Идея здесь простая:
хранить только то, что действительно необходимо для работы с обращением.
Ещё одно важное изменение — теперь поведением AI можно управлять отдельно
Параллельно с логированием мы изменили ещё одну часть архитектуры.
Раньше большая часть инструкций для AI находилась прямо внутри программного кода.
Это работает, но очень неудобно.
Допустим, владелец сайта решил добавить новую услугу или хочет, чтобы AI отвечал немного короче.
Не должно быть необходимости открывать PHP-файл и менять программу.
Поэтому бизнес-инструкции AI мы вынесли в отдельную редактируемую настройку.
Теперь условно система состоит из двух слоёв:
защищённые системные правила + редактируемые правила конкретного сайта.
Защищённая часть отвечает за безопасность, правильную передачу заявки и другие вещи, которые владелец сайта случайно ломать не должен.
А в редактируемой части можно объяснить AI, кто вы, чем занимаетесь и как он должен разговаривать с клиентами.
Где находятся инструкции AI в MODX
В MODX 2 и MODX 3 для этого используется отдельный Chunk:
portfolio_assistant.ai_rules
Это оказался довольно удобный вариант.
Администратор сайта может открыть обычный Chunk в MODX Manager и изменить инструкции так же, как любой другой текст сайта.
Например, можно написать:
Мы разрабатываем сайты на MODX и WordPress, занимаемся PHP и JavaScript, подключаем API и сторонние сервисы.
Или:
Отвечай дружелюбно и коротко. Обычно достаточно 2–5 предложений.
После сохранения новые правила начинают использоваться ассистентом.
При этом Chunk читается как обычный текст — MODX не пытается выполнять находящиеся внутри него теги или другой код.
В WordPress всё ещё проще
В WordPress мы добавили отдельное поле AI rules непосредственно в:
Settings → AI Lead Assistant
То есть владелец сайта открывает настройки плагина и видит большое текстовое поле с инструкциями для своего ассистента.
Там можно менять услуги, стиль общения, языки, правила вопросов клиенту и другие особенности поведения AI.
Это намного удобнее, чем редактировать PHP-код плагина.
И самое главное — пользователь меняет только бизнес-логику.
Системные правила безопасности остаются внутри программы и имеют более высокий приоритет.
Что лучше писать в AI rules
Здесь есть интересный момент.
Чем больше инструкций мы дадим AI, тем лучше он будет работать — кажется логичным.
На практике это не совсем так.
Я бы не советовал превращать AI rules в огромный документ на десятки страниц.
Лучше дать ассистенту короткую и конкретную информацию.
Например, полезно описать:
Чем вы занимаетесь
Перечислите основные услуги и технологии.
Например:
Разработка сайтов на WordPress и MODX. PHP, JavaScript, Node.js, API-интеграции, автоматизация, поддержка и доработка существующих сайтов.
Так AI будет понимать, относится ли вопрос посетителя к вашим услугам.
Как он должен общаться
Например:
Отвечай дружелюбно, профессионально и простым языком. Не пиши слишком длинные ответы. Обычно достаточно 2–5 предложений.
Это зачастую полезнее, чем просто написать «будь хорошим помощником».
На каких языках отвечать
В моём случае правило очень простое:
Всегда отвечай на языке, на котором сейчас пишет посетитель.
Если человек начал по-русски — AI отвечает по-русски.
Перешёл на английский — ассистент тоже переключается.
Что нужно узнать у потенциального клиента
Не стоит заставлять AI сразу выдавать анкету из десяти вопросов.
Лучше написать:
Постепенно выясни, что пользователь хочет сделать или исправить, адрес сайта, используемую CMS, желаемый результат, необходимые интеграции и сроки. Задавай по одному полезному вопросу за раз.
Тогда разговор получается гораздо естественнее.
Что AI не должен придумывать
Это особенно важно для коммерческого сайта.
Например:
Не придумывай цены, сроки, скидки, доступность разработчика или гарантии. Если для оценки проекта нужна дополнительная информация, собери её и предложи передать запрос разработчику.
AI очень хорошо умеет генерировать убедительно звучащие ответы.
Но потенциальному клиенту совершенно не нужна убедительно придуманная цена.
Что лучше не писать в AI rules
Не стоит пытаться самостоятельно описывать там безопасность системы.
Например, правила хранения API-ключей, структуру JSON-ответов, механизм отправки Telegram или логику подтверждения заявки.
Это уже задача программы.
Для этого в проекте существует отдельный защищённый слой SYSTEM SAFETY AND HANDOFF CONTRACT.
Он следит, например, за тем, чтобы AI не мог сказать пользователю:
Отлично, ваша заявка уже отправлена!
до тех пор, пока сервер действительно не подтвердил успешную отправку по email или Telegram.
Именно поэтому разделение на системные и пользовательские инструкции оказалось очень полезным.
Владелец сайта может свободно обучать ассистента своему бизнесу, не вмешиваясь в критическую логику приложения.
Получился уже не просто чат-бот
Когда я начинал этот проект, идея была довольно простой.
Добавить на сайт небольшое окно, в котором AI сможет отвечать на вопросы посетителей.
Но постепенно проект начал превращаться в нечто более интересное.
Теперь ассистент умеет:
понимать язык посетителя, рассказывать об услугах, задавать уточняющие вопросы, постепенно собирать информацию о проекте, передавать готовую заявку по email и Telegram, сохранять контакт ещё до завершения разговора и показывать все обращения владельцу сайта в удобной админке.
При этом его поведение теперь можно менять без изменения программного кода.
И для меня именно это уже гораздо ближе к настоящему AI Lead Assistant, а не просто очередному чату с нейросетью.
Главное правило: контакт не должен исчезать
Самое важное изменение этой версии можно сформулировать очень просто:
если посетитель доверил нам свой контакт — система должна его сохранить.
Неважно, закончил он разговор или нет.
Неважно, успел AI собрать всю информацию или человек закрыл страницу через десять секунд.
С этого момента потенциальный клиент уже не потерян.
И, как мне кажется, именно такие небольшие функции постепенно превращают AI на сайте из красивой демонстрации технологии в действительно полезный бизнес-инструмент.
В следующей части проекта можно двигаться ещё дальше: улучшать просмотр и обработку обращений, добавлять новые варианты интеграций и постепенно давать ассистенту больше возможностей для реальной работы с клиентами.
Сам проект, включая версии для MODX 2, MODX 3 и WordPress, можно посмотреть на GitHub: