К содержимому
Инвойсбокс

Интерфейс для разговора с агентом

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

Четыре момента, в которые человек смотрит на экран

МоментЧто показатьПочему
До подтвержденияСумма, плательщик, состав и итог — до того, как человек нажмёт «да».Человек соглашается с формулировкой, а число часто не перечитывает. Экран сводки стоит дешевле спора о лишнем нуле.
В момент подтвержденияПоле для суммы заполняет человек, а не модель и не автозаполнение.Значение, пришедшее от той же стороны, которая собрала операцию, ничего не подтверждает.
После отказаПричина человеческими словами и следующий шаг.Коды вида «wrong_phone_number» понимает модель, а решение принимает человек. Показывайте оба слоя: фразу и, по запросу, исходные поля.
После обрываТретий исход «неизвестно» отдельно от «не получилось».Обрыв связи посреди операции — не отказ. Подскажите проверяемое действие: посмотреть заказ по номеру, повторить с тем же ключом, открыть кабинет.

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

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

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

  • Клиент объявляет умение спрашивать. Если он этого не умеет, сервер не пытается задать вопрос и возвращается к двухфазной схеме: сводка операции и отдельный вызов с токеном подтверждения. Отсутствие удобной функции у клиента не должно превращаться в тихое исполнение денежной операции.
  • Молчание не равно согласию. Закрытый диалог, тайм-аут, отмена — всё это отказ. Принимать стоит только явное «да».
  • Чувствительные данные через форму не спрашивают. Пароли, ключи, платёжные реквизиты в диалоге подтверждения запрещены спецификацией; для таких случаев предусмотрен режим со ссылкой на внешнюю страницу.

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

Отказ — это тоже интерфейс

Покажите работу проверки

Когда сервер остановил операцию — не сошлась арифметика, не хватило прав, — худшее, что можно вывести человеку, это «не удалось». Так предохранитель читается как неисправность, хотя он только что спас деньги. Формулировка «счёт не ушёл: проверка нашла расхождение в сумме на 49 копеек» превращает страх в довод.

Переводите коды в слова

Статусы вроде created, коды ставок НДС и единиц измерения понятны модели и непонятны человеку. Показывайте два слоя: короткую фразу и, по запросу, исходные поля для того, кто разбирается.

Не обещайте лишнего

Кнопка «вернуть деньги» при выключенном наборе возвратов — это отказ, который придётся объяснять. Собирайте интерфейс по каталогу, который отдал сервер: инструмент, которого нет в каталоге, модель всё равно не вызовет.

Чужой текст остаётся данными

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

Разговор, сессии и первое сообщение

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

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

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

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

Держите результат в том же диалоге. Ссылка на оплату и QR-код должны появиться там, где шёл разговор. Каждый шаг между решением и оплатой — письмо, переход, поиск счёта в почте — стоит конверсии.

Чек-лист приёмки интерфейса

Десять проверок, которые ловят почти всё, что ломалось у нас на живых прогонах.

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

Как выглядит собранный диалог целиком — на странице демонстрации: там записанный сценарий и живой режим с настоящей моделью. Что сервер проверяет со своей стороны — в безопасности.