Какие вопросы нужны боту для заявки

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

Определите, какое обращение сотрудник сможет взять в работу

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

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

Сформулируйте результат приёма одним предложением. Например: «Сотрудник получает запрос на ремонт стула, район, описание проблемы и выбранный клиентом канал ответа». Это учебная постановка, не описание действующего бота Nazara. Не включайте в неё обещание ремонта, подтверждённого времени или окончательной цены, если бот только передаёт обращение.

Для каждого будущего вопроса запишите, кто использует ответ и какое действие он меняет. Если ответ не нужен ни для маршрутизации, ни для следующего шага, отложите вопрос. Такой подход к обоснованию вопросов описан в GOV.UK Service Manual. В чате он помогает отделить необходимое уточнение от длинной анкеты, разбитой на сообщения.

Поставьте вопросы в порядке принятия решения

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

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

Различайте обязательность и желательность. Без района нельзя определить возможность выезда, а фотография иногда лишь ускоряет оценку. У необязательного шага нужна видимая кнопка «Пропустить». Если без снимка работа невозможна, объясните это до загрузки, а не после заполнения всей заявки. Не обещайте, что любое фото автоматически распознается и заменит осмотр.

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

Согласуйте кнопки, свободный ответ и контакт

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

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

Не считайте имя профиля или наличие чата достаточным контактом для любого канала. Спросите, где человеку удобно получить ответ. Если выбран телефон, покажите способ его передачи и вариант исправления. В Bot API для KeyboardButton запрос собственного номера через request_contact описан для личных чатов и срабатывает при нажатии пользователем. Это не скрытое получение телефона при открытии бота и не функция всех мессенджеров.

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

Опишите возврат, паузу и изменение предыдущего ответа

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

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

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

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

Покажите итог заявки до окончательной отправки

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

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

Ниже учебный фрагмент для мастерской. Он не содержит настоящего телефона и не демонстрирует работу какого-либо публичного бота:

Заявка: ремонт стула
Проблема: расшаталась ножка
Район: выбран клиентом
Фото: не приложено
Ответ: в этом чате
Время выезда ещё не согласовано
Действия: исправить, отправить обращение, отменить

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

Назовите подтверждением только фактически выполненный шаг

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

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

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

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

Соберите рабочую карту и проверьте её с получателем

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

Каталог ботов Nazara показывает отдельные проекты и демонстрации. Это примеры задач, а не обещание готового универсального приёмщика заявок с CRM, бронированием и оплатой. Для обсуждения своего сценария через Умную форму можно передать одну обезличенную ситуацию и описать, что должен получить сотрудник.

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

Частые вопросы

Сколько вопросов оставить в первом варианте

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

Можно ли принять несколько услуг в одной заявке

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

Обязательно ли требовать имя

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

Что делать с фотографией чужого документа

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

Нужно ли сразу подключать ИИ

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

Как понять, что проблема в вопросе, а не в клиенте

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