Новости и разборы
Дизайн диалога AI-поддержки: тон, уточнения и передача человеку
Как проектировать диалог AI-поддержки: уточнения без допроса, короткие ответы, смена темы и передача сотруднику с сохранением контекста.
Клиент пишет: «Снова сняли деньги. У вас вообще кто-то работает?» AI-поддержка находит правильную статью о платежах и присылает длинное описание расчётного периода. Фактическая точность здесь ещё не означает полезный ответ. Человеку нужно разобраться с конкретным списанием, а система отвечает на соседний вопрос.
Дизайн диалога определяет, как агент узнаёт задачу клиента, сколько объясняет, когда уточняет и как передаёт обращение сотруднику. Это самостоятельная работа над общением. Она особенно заметна в ситуациях, где знания уже есть, но клиенту приходится бороться с формой ответа.
Что предлагают источники и чего они не доказывают
В статье Intercom от 18 июня 2026 года перечислены пять областей conversation design: тон, структура ответа, передача человеку, ход взаимодействия и воспринимаемое качество ответа. Компания также приводит собственный A/B-тест приветствия с изменением CSAT с 72,8% до 78,4%. Это результат описанного Intercom эксперимента; он не позволяет прогнозировать такой же эффект для другого продукта или канала.
В материале о выборе AI-агента от 22 мая провайдер предлагает проверять реальные многошаговые обращения, неполные сообщения, разные формулировки, чувствительные ситуации и несколько языков. Общий вывод полезен для проектирования: приёмка должна учитывать весь разговор, включая затраты усилий клиента, а не один удачный ответ на демонстрационный вопрос.
Начинать с задачи и состояния человека
Для условного SaaS-продукта можно выделить три типа общения. При восстановлении доступа важны короткая последовательность шагов и возможность быстро обратиться к человеку. При знакомстве с функцией полезны объяснение и пример. При спорном платеже нужны точное разграничение известных фактов и предположений, а также понятный путь рассмотрения обращения.
Тон остаётся последовательным, но степень подробности меняется. Фраза «понимаю ваше разочарование» не помогает, если вслед за ней идёт неподходящая инструкция. Сначала следует назвать задачу, которую система может решить сейчас: проверить применимое правило, уточнить обстоятельство или передать спор сотруднику. Нельзя обещать отмену списания, если такого полномочия у агента нет.
Этот подход согласуется с проектированием чат-ботов для рабочих процессов: заранее определяются доступные сведения и действия. Дизайн разговора опирается на эти границы. Красивое объяснение не расширяет разрешения и не подтверждает завершение операции.
Уточнение должно менять следующий шаг
Вопрос полезен, если ответ на него позволит выбрать действие или нужную инструкцию. «Расскажите подробнее» часто перекладывает работу на клиента. В условном споре о платеже лучше различить повторное списание и ожидаемое продление, если это действительно определяет маршрут поддержки. Уже сообщённые сведения не нужно просить заново.
Стоит заранее описать, какие уточнения допустимы в канале и какие данные не следует собирать. Для входящего обращения обычно не нужен полный набор платёжных реквизитов. Если клиент не может ответить на вопрос, разговор должен иметь продолжение: альтернативное объяснение или передача сотруднику, а не бесконечный цикл переформулировок.
Проверочная ситуация может выглядеть так: человек назвал проблему, отказался повторять сведения и затем спросил о сроке ответа. Агент должен реагировать на текущий вопрос. Принудительное возвращение к первой ветке сценария создаёт ощущение, что собеседник не слушает.
Короткий ответ и предложение продолжить
Для простого вопроса полезен один понятный шаг. Сложная интеграция может потребовать нескольких условий, но их стоит расположить по порядку выполнения. Дополнительное объяснение лучше предложить после основного ответа, чтобы клиент мог выбрать нужную глубину.
В Intercom рекомендуют держать инструкции поведения короткими, а сведения о продукте переносить в базу знаний. Это снижает риск того, что правила общения превратятся в набор противоречивых исключений. Подготовка базы знаний к релизу раскрывает другую половину этой работы: актуальные условия продукта должны обновляться отдельно от тона и структуры диалога.
При редактировании полезно сравнить две версии одного ответа на одинаковом вопросе. Оценивать нужно, заметил ли человек следующий шаг, понял ли ограничение и пришлось ли ему повторно объяснять проблему. Предпочтение редактора к более «дружелюбному» стилю само по себе не является измерением пользы.
Передача человеку — часть разговора
Сотруднику нужны первоначальная задача, уже собранные сведения, предпринятые шаги и причина передачи. Краткое резюме удобно, но оно не должно скрывать исходный разговор или превращать предположение агента в факт. Если система не проверяла списание, запись «обнаружен двойной платёж» некорректна; допустимо «клиент сообщает о возможном повторном списании».
В схеме AmoCRM и чат-бота сложные обращения предусмотрено передавать человеку вместе с контекстом и ответственным. Это описание проектного объёма, без подтверждённых результатов запуска. Оно показывает архитектурный вопрос: как связать диалог и задачу в CRM, чтобы сотрудник мог продолжить работу.
Клиент также должен узнать, что произошло после передачи: куда отправлено обращение и какой следующий шаг доступен. Срок ответа указывают только при наличии действующего правила, а статус очереди — только при доступных данных. Если сотрудник сейчас недоступен, запасной маршрут нужно определить заранее.
Как принять первый вариант диалога
Для начала можно выбрать один проблемный тип обращений и прогнать несколько целых разговоров на русском и английском. Включить короткий запрос, смену темы, раздражённое сообщение, отказ от уточнения и ошибочную исходную гипотезу клиента. Проверить не только последний текст, но и сколько действий пришлось совершить человеку.
Отдельно отмечают ненужные вопросы, потерю контекста и обещания, которые система не может выполнить. После исправления повторяют те же ситуации, чтобы новая формулировка не ухудшила другую ветку. Если рассматривается голосовой канал, ограничения и выбор платформы разобраны в сравнении разработки и покупки голосового AI: общая политика общения требует адаптации к каналу.
Первый результат такой работы — компактные правила для выбранного диалога, примеры хороших ответов и ясный маршрут к сотруднику. Цель состоит в том, чтобы клиент продвинулся к решению с меньшим числом повторов и неопределённых обещаний. Конкретный эффект проверяют на своём потоке обращений.