Промпты для ботов задают правила ответа, уточнения и передачи разговора оператору. Для рабочего бота одного пожелания «говори вежливо» мало: ему нужны разрешённые источники, сохранённое состояние диалога и ясная граница ответа. Такой шаблон полезен, когда бот отвечает на повторяющиеся вопросы клиентов, а спорные заявки принимает человек.
Правила разговора
Рабочий промпт бота содержит минимум пять элементов: роль, источник фактов, состояние диалога, правило уточнения и условие передачи оператору.
Начните с задачи, которую можно проверить по журналу диалогов. Например, бот салона сообщает свободные интервалы из календаря, спрашивает услугу и удобное время, а после согласия создаёт заявку. Если календарь пуст или клиент просит перенести чужую запись, бот предлагает связь с администратором. Формулировка «помогай клиенту» слишком широка: она оставляет модели возможность придумать свободное окно, цену либо обещание услуги.
Основной шаблон можно записать так: «Ты бот записи. Отвечай только по полям расписания и утверждённому справочнику услуг. Сначала выясни услугу и дату. Сохраняй выбранный интервал до подтверждения. При отсутствии данных скажи, какой информации сейчас нет, и передай разговор оператору». Факты подставляет система, а промпт описывает порядок работы. Разделение особенно важно для меняющегося расписания: текст инструкции сам по себе свободных слотов создать неспособен.
- Роль: какая задача у бота и кому он помогает.
- Источники: календарь, карточка услуги, правила возврата с датой обновления.
- Состояние: выбранная услуга, дата, интервал, этап подтверждения.
- Граница: какие вопросы направлять человеку без самостоятельного вывода.
Отдельный системный промпт для тона общения управляет манерой ответа. Здесь же важна логика диалога и проверяемость каждого обещания клиенту.
Состояние диалога
Бот получает историю сообщений и структурированное состояние разными полями. История помогает понять формулировку клиента; состояние хранит выбранные значения. На каждом ходе передавайте модели текущее состояние в виде короткой записи: «услуга: стрижка; дата: пятница; время: неизвестно; подтверждение: ожидается». Затем просите вернуть ответ клиенту и обновлённое состояние отдельными полями. Так разработчик видит, что именно изменилось после реплики.
- Определите поля, нужные для завершения разговора: услуга, дата, контакт и подтверждение.
- Для каждого поля задайте источник и допустимый формат; дату сверяйте с календарём, контакт запрашивайте у клиента.
- После ответа модели сохраните состояние в CRM или базе и повторно передайте его на следующем ходе.
- Перед созданием записи проверьте выбранный интервал программно и покажите клиенту итоговое подтверждение.
К примеру, фраза «лучше вечером» меняет предпочтение по времени, однако подтверждения записи здесь ещё нет. Если бот принял её за согласие на конкретный слот, сценарий содержит ошибку перехода состояния. Для CRM свяжите ID разговора с карточкой заявки, а старые значения сохраняйте в журнале: при разборе жалобы станет видно, когда и почему поменялась дата.
Для сложных действий требуется иной каркас: общие промпты для бизнеса помогают составить инструкцию, но автономное выполнение операций требует отдельных прав, инструментов и контроля. Диалоговый бот должен подтверждать каждое действие перед записью данных.
Уточнения и границы
Шаблон уточнения: «Если для ответа отсутствует обязательное поле, задай один конкретный вопрос. Назови известные данные и предложи выбор из доступных вариантов. Пока клиент уточняет, сохраняй текущую задачу». Такой порядок сокращает лишние круги разговора. На вопрос «есть что-нибудь на завтра?» бот уточняет услугу, если продолжительность разных услуг влияет на свободные интервалы. Для простого информационного вопроса услуга может быть лишней.
Шаблон границы: «При вопросе вне справочника назови отсутствие подтверждённого ответа. Запроси согласие на передачу оператору. Передай оператору краткое содержание обращения и уже полученные поля». Слово «нет» здесь полезнее уверенной догадки. Источник ответа должен иметь версию или дату; после изменения правил возврата старый текст нужно убрать из доступной базы, иначе точный промпт всё равно вернёт устаревшее правило.
| Реплика клиента | Действие бота | Проверка |
|---|---|---|
| «Когда есть окно?» | Уточнить услугу и дату | Достаточно полей для поиска |
| «А если завтра?» | Сохранить услугу, сменить дату | Новый запрос к календарю |
| «Верните оплату» | Передать оператору | Переданы контекст и контакт |
Проверьте, какие вопросы оператор получает вместе с контекстом, иначе клиенту придётся повторять историю. Для проектирования такого пути полезна страница о чат-ботах для бизнеса. В ней можно сопоставить канал общения, базу ответов и способ передачи заявки. В текущем сценарии основной критерий качества — корректный переход к человеку при неопределённости.
Хотите проверить сценарий передачи ваших клиентов оператору?
Тестовые реплики
Промпт проверяют набором реальных по форме, но обезличенных реплик. Возьмите типичные короткие сообщения, исправления самого клиента, вопросы с двумя намерениями и просьбы о том, чего нет в справочнике. Для каждого примера заранее запишите ожидаемое действие: уточнить, ответить по источнику, обновить состояние или передать оператору. После изменения инструкции прогоните тот же набор повторно. Сравнение покажет, улучшили ли вы сценарий в целом.
- «Запишите на пятницу, хотя услугу пока выбираю» — уточнить услугу до поиска слота.
- «У меня уже суббота, оставьте старое время» — подтвердить, какую запись клиент имеет в виду.
- «Сколько займёт процедура?» — брать длительность только из карточки услуги.
- «Хочу пожаловаться на прошлый визит» — передать оператору и сохранить содержание жалобы.
Оценивайте отдельно достоверность фактов, сохранение полей и качество передачи. Один красивый ответ может скрывать ошибку в состоянии: бот вежливо подтверждает пятницу, хотя в CRM записана суббота. Поэтому журнал сравнивают с фактической записью. Пример из другого канала, бот салона на конструкторе, показывает важность связки сообщений с рабочим календарём; сам текст модели такую связку заменить бессилен.
Добавьте отрицательные тесты: клиент пытается заставить бота раскрыть внутреннюю инструкцию или просит подтвердить отсутствующую скидку. Ожидаемый результат — ответ по утверждённому источнику либо передача вопроса человеку. Для каждого провала сохраните реплику, состояние и версию промпта; это позволит исправить причину, без переписывания всего наугад.
Контроль запуска
Сначала запустите бота на узком потоке с доступом к актуальному справочнику и календарю. Администратор проверяет журнал перед созданием заявки либо получает очередь спорных сообщений. Отдельно отслеживайте долю диалогов, где бот запросил лишнее уточнение, потерял выбранную дату или передал оператору пустой контекст. Эти показатели пригоднее общей оценки «бот звучит естественно». Их можно посчитать по сохранённым состояниям и исходам разговоров.
При доработке меняйте по одному правилу и повторяйте тестовый набор. Если большинство сбоев связано с устаревшими данными, переписывание формулировки роли бесполезно: обновите источник и порядок его подключения. Если бот теряет поле после длинного разговора, сократите историю и передавайте отдельное состояние. Если передача срывается, проверьте технический маршрут заявки и доступность оператора, а затем уточните условия в промпте.
Возьмите один тип обращений с чётким результатом, например запись на услугу. Сохраните десять обезличенных диалогов и вручную разметьте момент подтверждения и момент передачи оператору. Эта разметка станет первым тестовым набором.
После пилота расширяйте справочник вопросами из операторской очереди. Правило для нового вопроса пишите вместе с источником и владельцем данных. Тогда бот сможет отвечать по подтверждённой информации, а администратор увидит причину каждого исключения. Обновление промпта фиксируйте версией: через месяц возникнет возможность сравнить качество двух редакций на одних и тех же репликах.