ИИ записал обещание клиенту. Кто проверит, что оно исполнено?

Чат закончился, обязательство осталось

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

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

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

Для начала стоит договориться о словах. «Обычно расчёт занимает два дня» — описание процесса. «Можем подготовить расчёт» — предложение. «Пришлём вам расчёт в среду до 18:00» — обещание конкретному человеку. «Уточню у технолога и вернусь со сроком» — другое обещание: не выдать расчёт, а вернуться с ответом. Если смешать эти фразы, реестр быстро заполнится ложными задачами, а настоящие обязательства утонут в шуме.

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

Превратите фразу в проверяемую запись

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

В карточке должны быть:

1. Источник: ссылка на сообщение или отметка времени звонка и точная исходная фраза. Без этого спор о формулировке превращается в спор о памяти.
2. Результат: что клиент должен получить — файл расчёта, обратный звонок, решение по жалобе. Пишите наблюдаемый результат, а не «проработать вопрос».
3. Адресат и канал: кому и куда обещали ответить. Контактные данные можно хранить в клиентской карточке, оставив в реестре ссылку на неё.
4. Срок: дата и время с понятным часовым поясом; если срок зависит от события, укажите само событие и контрольную дату проверки.
5. Владелец: один человек, который отвечает за движение карточки. Он может поручить работу другому, но не исчезает из процесса.
6. Статус и следующий шаг: что происходит сейчас, кому нужно действие и когда система проверит его вновь.
7. Подтверждение: ссылка на отправленный результат или запись о разговоре, а после — реакция клиента либо причина, по которой подтвердить её пока не удалось.

У этой записи два слоя. Исходная цитата показывает, что действительно услышал клиент. Рабочая формулировка позволяет управлять исполнением: «подготовить и отправить расчёт заказа №... до среды 18:00». Если ИИ ошибся при извлечении, человек поправит рабочую часть, не переписывая источник задним числом.

Дайте карточке жизненный цикл

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

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

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

Здесь полезно разделять два срока. Первый — внешний, о котором знает клиент. Второй — внутренний контрольный: к какому моменту сотрудник должен иметь черновик или решение, чтобы успеть проверить и отправить результат. Если расчёт обещан к 18:00, задача «начать расчёт в 17:50» формально ещё не просрочена, но практически уже сорвана.

Работа с такими обязательствами созвучна рекомендациям NIST AI Risk Management Framework: для ИИ-систем нужны определённые роли человека, мониторинг после внедрения и возможность вмешательства. Это рамка управления рисками, а не готовый регламент для клиентских обещаний. Конкретные роли и пороги компания должна назначить сама.

Проверьте маршрут на одном заказе

Вернёмся к условной мебельной мастерской. В понедельник в 12:20 ассистент написал клиенту: «Пришлём предварительный расчёт в среду до 18:00». Система выделила фразу и предложила карточку. Менеджер увидел её вместе с сообщением, назначил дизайнеру подготовку размеров, технологу — проверку материалов, а за финальный ответ оставил себя.

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

Допустим, расчёт готов в среду в 15:30. Менеджер сверяет условия с исходным запросом и отправляет файл по согласованному каналу. Приложенная ссылка доказывает отправку, но сама по себе не доказывает, что клиент смог открыть файл и получил ответ на вопрос. Поэтому статус меняется на «результат отправлен». При отсутствии ответа менеджер проверит статус доставки, попытается связаться по установленному правилу и сохранит отметку о том, что получение клиентом не подтверждено.

В этом примере ИИ не «делает всё». Он замечает фразу, заполняет черновик, напоминает о контрольной точке и показывает владельцу историю. Решение о цене, пересмотре срока и содержании ответа принимает тот, у кого есть полномочия и доступ к фактам заказа.

Где автоматизация ошибается

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

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

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

Четвёртый — мнимое исполнение. Исполнитель отметил «готово», потому что файл лежит у него на компьютере. Клиенту файл не отправлен. Для каждого типа обещания заранее определите доказательство: исходящее письмо, сообщение в чате, принятый звонок, подписанный документ, изменение статуса услуги. Доказательство должно относиться к обещанному результату, а не просто к активности сотрудника.

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

Эскалация должна помогать, а не шуметь

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

Не выдавайте перенос срока за обычное редактирование поля. История должна показывать старое обещание, причину изменения, контакт с клиентом и новый согласованный срок. Особенно это важно при смене сотрудника: новый владелец должен видеть не только последнюю дату в интерфейсе, но и то, что уже сказано человеку.

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

Запустите процесс за неделю без большого проекта

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

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

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

Дни 4–5. Проведите выбранные диалоги через процесс вручную или с ИИ-подсказками. Отмечайте ложные срабатывания, пропуски, непонятные сроки и задачи, по которым нельзя определить исполнение. Исправьте словарь и поля по этим находкам.

Дни 6–7. Включите напоминания и один маршрут эскалации. Пройдите три проверки: что происходит без назначенного владельца, при срыве внутреннего срока и при отправленном, но не полученном результате. Лишь после этого расширяйте сценарий на другие типы обещаний.

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

Последнее слово — за клиентом

Стандарт ISO 10002:2018 описывает работу с обращениями и жалобами как процесс, который включает реакцию на запросы людей и улучшение обслуживания; в его аннотации отдельно указана применимость к небольшим организациям. Реестр обещаний — не требование этого стандарта. Но та же логика полезна здесь: внутреннее действие не равно решённой проблеме клиента.

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

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