AI-помощник на сайте: как спроектировать диалог, который доводит клиента до заявки

Коротко о главном

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

Поэтому проект AI-ассистента — это не «написать 30 реплик». Это проектирование пути: задача клиента → карта возможностей → данные и источники → уточнения → элементы интерфейса → действия и подтверждения → ошибки → передача менеджеру → повторяемое тестирование.

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

Чем AI-помощник отличается от обычного чат-бота

Представьте типичную ситуацию. Снабженец заходит на сайт поставщика промышленного крепежа и пишет: «Нужны анкерные болты М12 на 2500 штук, доставка в Новосибирск, оплата по счёту с НДС. Когда сможете отгрузить?»

Сценарный бот в этот момент начнёт своё: «Выберите категорию → выберите подкатегорию → оставьте телефон». Клиент видит, что его вопрос проигнорирован, и уходит к конкуренту, у которого на сайте просто лежит прайс.

AI-помощник в той же ситуации способен:

• вытащить из свободного текста номенклатуру, объём, город и условия оплаты;
• уточнить единственное реально недостающее — например, оцинковка или нет;
• проверить остаток на складе и срок отгрузки в учётной системе;
• посчитать цену с учётом объёма и скидочной матрицы;
• сформировать счёт или заявку в CRM и передать её менеджеру с полным контекстом.

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

Договоримся о терминах. AI-помощником (AI-ассистентом) в статье называем систему, которая общается на естественном языке и помогает решить задачу: она может работать на модели с поиском по базе знаний (RAG), обращаться к внешним системам через API или комбинировать оба подхода. AI-агент — более самостоятельная конструкция: внутри заданных границ он сам выбирает порядок шагов и инструменты.

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

Шаг 1. Начинайте не с реплик, а с результата клиента

Главная ошибка внедрения — проектировать диалог от бизнес-цели: «нам нужны лиды, значит бот просит телефон».

Разведём две вещи:

• бизнес-результат — заявка, счёт, запись, заказ;
• результат клиента — ответ на его исходный вопрос.

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

Для каждого ключевого сценария зафиксируйте четыре строки. Пример — сайт производителя окон:

Один помощник почти всегда закрывает несколько сценариев: подобрать решение, узнать цену, проверить наличие, уточнить статус заказа, получить документ, изменить запись, задать вопрос по гарантии. Каждый сценарий описывается отдельно — своим результатом, своими данными и своим «следующим шагом».

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

Шаг 2. Составьте карту возможностей и ограничений

Приветствие «Спрашивайте что угодно» — обещание, которое продукт не выполнит. Если помощник знает ассортимент и условия доставки, но не знает статус отгрузки, клиент упрётся в границу за два сообщения и потеряет доверие ко всей системе.

Поэтому до написания текстов рисуется карта: что помощник умеет и откуда берёт данные. Пример для поставщика оборудования:

Отдельно фиксируются ограничения — и это половина успеха. Например: помощник создаёт заявку, но дату отгрузки подтверждает логист. Значит фраза «Отгрузим во вторник» допустима только после того, как этот статус пришёл из рабочей системы, а не потому, что модель «посчитала логичным».

Для каждого действия определите:

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

Здесь проектирование диалога превращается в работу с данными, API и правами доступа. Если прайс говорит одно, а склад другое, помощнику нужно правило приоритета. Если правило не даёт однозначного ответа — он честно сообщает о расхождении или передаёт случай менеджеру.

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

Шаг 3. Постройте сценарий вокруг состояния задачи, а не вокруг ветвлений

Классический бот — это дерево: «услуга → подкатегория → город → телефон». Живой разговор в это дерево не укладывается. Клиент может сразу выложить половину вводных:

«Нужно остеклить балкон в новостройке, 3,2 метра, тёплое, до конца октября»

Может начать с одного условия:

«А вы вообще на Луговую, 14 приезжаете на замер?»

Может передумать посередине:

«Давайте второй вариант. Хотя стоп — а откосы в цену входят?»

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

Типичный ход процесса для нашего примера:

1. Определить задачу — рассчитать и заказать остекление.
2. Извлечь всё, что клиент уже сказал.
3. Проверить, достаточно ли данных для следующего шага.
4. Спросить только обязательное недостающее.
5. Проверить зону выезда и доступные конструкции.
6. Показать 2–3 подходящих варианта с ценой.
7. Ответить на вопросы и пересчитать при изменении условий.
8. Предложить следующий шаг — замер или счёт.
9. Перед значимым действием показать итоговые параметры.
10. Выполнить операцию и получить её фактический статус из CRM.
11. Сообщить клиенту подтверждённый результат.

Для операций вроде оплаты, оформления заказа, возврата или брони порядок проверок остаётся жёстким: модель свободно разговаривает, но сама операция идёт по заданной последовательности. Отдельная ветка под каждую человеческую формулировку не нужна — зато эти формулировки понадобятся на этапе тестирования.

Шаг 4. Уточняйте только то, что меняет результат

Клиент формулирует приблизительно:

«Нужно недорого остеклить балкон»

Без адреса нельзя проверить выезд — вопрос оправдан:

«Назовите адрес, проверю, работаем ли мы в этом районе и какие конструкции там подойдут»

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

«Балкон планируете использовать зимой как жилое пространство или только для хранения?»

От этого зависит профиль и остекление — вопрос полезен.

А вот цепочка «Сколько у вас детей?», «Какой у вас цвет мебели?», «Как часто вы бываете дома?» ничего не меняет и просто удлиняет диалог. Каждый лишний вопрос — это процент потерянных диалогов.

Уточнение оправдано в трёх случаях:

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

Простой тест: если ответ клиента ничего не изменит в рекомендации или действии — вопрос нужно убрать.

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

Шаг 5. Используйте контекст, чтобы клиент не повторялся

В диалоге почти всегда больше информации, чем в последнем сообщении:

— Покажите модели до 150 тысяч
— Вот три варианта
— Вторая подойдёт, если работать в две смены?
— Да
— А пусконаладка входит?
— Да
— Тогда оформляем

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

Благодаря контексту клиент может:

• ссылаться на вариант словами «этот», «вторая», «подешевле»;
• дополнять запрос частями;
• менять одно условие, сохраняя остальные;
• вернуться к предыдущему варианту;
• продолжить основную задачу после побочного вопроса.

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

И обязательное правило: при изменении условия состояние пересчитывается. После «теперь нужно до 120 тысяч» прежний лимит 150 тысяч не должен влиять на подбор.

Шаг 6. Соедините текст и интерфейс в один сценарий

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

Допустим, помощник подобрал три модели. Можно описать их тремя абзацами — но карточки позволяют сравнить цену, производительность, комплектацию и срок поставки одним взглядом. Тогда текст остаётся коротким:

«По вашим условиям подходят три модели. Все выдают нужную производительность, отличаются ценой, комплектацией и сроком поставки.»

Что чем закрывать:

Проектировать нужно весь ход целиком: запрос → ответ помощника → карточка/кнопка/форма → действие клиента → следующий ответ.

Текст и визуальные блоки не должны противоречить друг другу и дублировать одно и то же. Если цена уже крупно на карточке, повторять её длинным предложением незачем. Но критичное для решения условие — например, «монтаж оплачивается отдельно» — должно читаться независимо от формата.

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

Шаг 7. После ошибки должен остаться понятный следующий ход

Ни один сценарий не покрывает всё. Типовые сбои:

• запрос можно понять несколькими способами;
• нужных данных в системе нет;
• источники расходятся;
• API временно недоступен;
• выбранный вариант исчез в процессе оформления;
• действие завершилось с ошибкой;
• запрос вне возможностей системы.

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

«Сейчас не получается проверить остаток по этой позиции — склад не отвечает. Могу повторить запрос через минуту или передать позицию менеджеру для ручной проверки.»

При расхождении источников:

«Позиция есть в каталоге, но склад её сейчас не подтверждает. Могу показать аналоги с подтверждённым наличием или передать вопрос менеджеру.»

Особенно строго — со статусами. «Заявка оформлена» допустима только после подтверждения из CRM. До подтверждения помощник показывает фактическое состояние: «Отправляю заявку» или «Не удалось создать заявку». Расхождение между обещанным и реальным статусом — самый быстрый способ потерять и клиента, и доверие отдела продаж к системе.

Шаг 8. Уровень контроля соответствует последствиям действия

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

Перед значимой операцией показывайте сводку:

Проверьте заказ:
Позиция: анкерный болт М12×120, оцинкованный
Количество: 2500 шт.
Цена: 41 руб./шт. с НДС
Доставка: Новосибирск, до склада, 4 рабочих дня

>

Подтвердить и выставить счёт?

Для обычного поиска цены такой экран — лишний шаг и потеря конверсии.

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

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

Шаг 9. Передача менеджеру должна сохранять контекст

«Обратитесь в отдел продаж» обычно означает, что клиент будет объяснять всё заново. Это худший момент воронки: он уже потратил силы и у него есть готовое решение — уйти.

За несколько минут помощник уже выяснил задачу, объём, город, условия оплаты и причину сбоя. Всё это уходит менеджеру вместе с обращением.

Что видит менеджер в CRM:

Клиент: снабжение производственной компании, Новосибирск.
Запрос: анкерные болты М12×120 оцинкованные, 2500 шт., оплата по счёту с НДС.
Проверка остатка дважды завершилась ошибкой.
Нужен срок отгрузки и подтверждение цены при объёме от 2000 шт.
Требуется ручная проверка склада.

Что видит клиент:

«Передам менеджеру уже указанные позиции и условия, чтобы не пришлось вводить их заново. Ответ — в течение рабочего дня.»

Поводы для передачи человеку:

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

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

Шаг 10. Проверяйте качество на повторяемом наборе реальных сценариев

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

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

• «Нужны болты М12, много»
• «А на Луговую приезжаете?»
• «Хочу самое дешёвое»
• «Нужно 2500 штук, оцинковка, с НДС, срок?»
• «Берём вторую модель»
• «Стоп, вторую не надо, покажите первую»
• «Можно со своей доставкой?»
• «Моего города в форме нет»
• «Я передумал, счёт пока не выставляйте»
• «Дайте живого человека»

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

Для каждого теста заранее фиксируется ожидаемый результат и критерий проверки. Что имеет смысл измерять:

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

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

Коммерческий эффект: на что реально влияет AI-помощник

Проектирование окупается не «инновационностью», а конкретными местами воронки. По практике внедрений эффект стоит ждать в четырёх точках:

• Скорость первого ответа. Ночные и выходные обращения перестают ждать утра — чаще всего именно здесь теряется значимая часть заявок.
• Квалификация. Помощник собирает объём, город, сроки и условия до менеджера. В CRM попадает заполненная карточка, а не «нужен расчёт».
• Конверсия из визита в заявку. Клиент получает ответ на свой вопрос, а не форму «оставьте телефон».
• Нагрузка на отдел. Типовые вопросы про наличие, цену и статус снимаются с менеджеров, время уходит на сделки с большим чеком.

Чего ждать не стоит: замены отдела продаж. Экономика улучшается за счёт первичной обработки и квалификации, а сложные сделки по-прежнему закрывают люди. Основной риск — запуск помощника без интеграций: без доступа к остаткам, прайсу и CRM он превращается в красивую болталку, которая раздаёт неточные ответы и портит доверие.

Чек-лист перед запуском AI-помощника

• Для каждого сценария определён результат клиента, а не только цель бизнеса.
• Возможности и существенные ограничения помощника понятны с первого экрана.
• Для всех данных и действий определены источники, свежесть и приоритеты.
• Система удерживает состояние задачи и пересчитывает результат при смене условий.
• Каждый уточняющий вопрос влияет на решение, действие или уровень риска.
• Текст, кнопки, карточки и формы ведут по одному и тому же пути.
• После любой ошибки остаётся понятный следующий шаг.
• Уровень подтверждения соответствует последствиям действия.
• При передаче менеджеру сохраняется весь собранный контекст.
• Качество проверяется на повторяемом наборе реалистичных сценариев.
• Статусы операций сообщаются только после подтверждения из рабочей системы.

Частые вопросы про AI-помощников

Чем AI-помощник отличается от чат-бота? Сценарный чат-бот ведёт клиента по заранее заданному дереву кнопок. AI-помощник понимает свободную формулировку, удерживает контекст разговора, обращается к данным компании и доводит задачу до результата. Кнопки при этом не исчезают — они остаются там, где удобнее выбрать, а не печатать.

Заменит ли AI-помощник менеджера по продажам? Нет. Он снимает первичную обработку, ответы на типовые вопросы и квалификацию, а сложные сделки и переговоры остаются за людьми. Правильная метрика — не «сокращение штата», а скорость ответа, качество лида и конверсия в сделку.

Сколько нужно данных, чтобы запустить AI-помощника? Минимум для полезного сценария — актуальные услуги или каталог, прайс или правила расчёта, условия работы и доступ на создание заявки в CRM. Без интеграций помощник сможет только консультировать по базе знаний, и его ценность ограничена.

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

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

Вывод

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

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

---