Запрос как форма в диалоге: подтверждение важнее заполненных полей

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

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

Проектируйте форму до диалога

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

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

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

Ведите диалог по развилкам

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

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

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

Покажите итог понятным языком

Перед отправкой сформируйте краткую карточку: что заказывается, где, когда предпочтительно, как связаться, какие условия неизвестны. Рядом доступны действия «подтвердить», «изменить» и «передать сотруднику». Молчание или переход к другой теме не считаются согласием.

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

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

Моделируемый сценарий

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

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

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

Защитите запись от дублей

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

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

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

Приёмка разговорной формы

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

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

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

Минимальная схема подтверждения

Форма в разговоре должна показывать человеку не только заполненные поля, но и последствия отправки. Отделите черновик от команды: первое можно дополнять и исправлять, второе создаёт запись, письмо или платёж. На экране подтверждения оставьте понятные названия, единицы измерения, адресата и итог. Внутренние коды допустимы рядом для поддержки, но не вместо человеческого смысла.

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

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

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

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