Агент предлагает изменить CRM: как проверить diff до записи
Почему кнопка «сохранить» — отдельный риск
Агент, который читает карточку сделки и предлагает черновик, не равен агенту с правом изменить её. Ошибка в пересказе заметна в тексте; неверное поле может уйти в отчёт, запустить уведомление или изменить работу менеджера. Поэтому опасная граница — не генерация ответа, а запись во внешнюю систему. Второй слот модели в сегодняшнем батче заменён этим разбором: за последние два дня не нашлось второй подтверждённой модели, которую можно было бы добавить без выдумки.
Сделайте действие явным
Не просите систему «привести CRM в порядок». Разбейте запрос на предложенные изменения: какое поле затронуть, какое текущее значение найдено, что предлагается записать, из какого сообщения это следует и насколько точен источник. Для нескольких полей агент возвращает список операций, а не выполняет их сразу. Человек должен увидеть, что останется без изменений, особенно если часть данных не подтверждена.
До теста договоритесь о разрешённых полях. Например, агент может предложить черновик заметки, но не менять стадию сделки, ответственного, сумму или дату обещания. Слова клиента «постараемся на следующей неделе» не превращаются в точную дату закрытия. Если поле требует интерпретации, система помечает его как вопрос.
Покажите отличие до и после
Перед подтверждением интерфейс выводит таблицу: запись и поле, текущее значение, новое значение, ссылка на основание, уверенность и последствие. Вместо одной кнопки «Применить всё» нужны отдельные флажки на каждую операцию. Если источник отсутствует или данные конфликтуют, строка блокируется и требует ручного решения. Не скрывайте пропуски за пустой ячейкой: подпишите «нет надёжного основания».
Для первой версии не выдавайте агенту общий API-ключ с правом чтения и записи всех объектов. Создайте сервисную роль с доступом только к тестовой группе и нужным полям. В идеале сначала включите режим предложения без записи: сохраняйте подготовленный diff, а сотрудник переносит его вручную. Такой shadow-режим позволяет увидеть ошибки в реальном потоке, не меняя рабочие карточки.
Проведите пилот на сохранённых примерах
Возьмите обезличенные кейсы: корректное уточнение суммы, изменение ответственного, перенос срока, противоречивые сообщения и отсутствие основания. Для каждого заранее составьте эталон: что можно предложить, что оставить как есть и в каком месте нужно задать вопрос. Проверьте не только обычный проход, но и повторную доставку одного события. Сбой сети может отправить запрос дважды; повтор не должен создать две заметки или дважды переключить стадию.
Измеряйте долю предложений, которые сотрудник принял без исправлений, число критичных ошибок, количество заблокированных неоднозначных действий и время проверки. Средняя точность скрывает редкие тяжёлые сбои, поэтому отдельно перечислите, какие поля были изменены неправильно и что предотвратило бы их. Записывайте версии инструкции, модели, схемы CRM и дату корпуса сообщений: после обновления тест повторяется.
Запись должна быть обратимой
Для каждого изменения храните журнал: кто инициировал запрос, какие данные использовались, что предложил агент, кто подтвердил и что система сохранила. Перед записью проверьте, можно ли вернуть прежнее значение и не запускает ли это внешнюю автоматизацию. Исправление поля не отменяет отправленное письмо или уведомление, поэтому внешние действия требуют отдельного подтверждения. При ошибке кнопка «откатить» должна быть доступна быстро, а не только администратору после расследования.
Если CRM обновилась вручную между чтением и сохранением, сравните текущую версию с той, на которой строилось предложение. При несовпадении отмените операцию и запросите повторную проверку. Это защита от ситуации, когда агент перезаписывает более свежие данные старым состоянием.
Где оставить человека
Назначьте владельца процесса и ежедневный канал для сообщений об ошибках. Не расширяйте разрешения после пары удачных демонстраций. Сначала подтвердите стабильность на нескольких типах записей, затем добавляйте по одному полю и повторяйте набор проверок. Стадия сделки, финансовая сумма, юридическое обязательство и обещанный клиенту срок должны оставаться под явным подтверждением.
Внутренний контекст и действие стоит проверять раздельно. Начните с практического маршрута безопасной песочницы для агента и посмотрите, как трассировка показывает путь каждого вызова. Для основ ответа важнее сначала найти источник: об этом материал проверка ответа нейросети.
FAQ
Можно ли разрешить автоматическую запись после успешного пилота?
Только для узких, обратимых полей с ясным основанием, журналом и протестированным откатом. Рискованные изменения следует оставить на подтверждение.
Как избежать повторного применения одного действия?
Использовать идентификатор операции, проверку версии записи и идемпотентную обработку события; при изменении карточки после чтения запрашивать новый diff.
Что считать готовностью?
Не только высокую долю принятых предложений, но и отсутствие критичных ошибок на пограничных данных, доступный откат и понятный владелец инцидента.
Вывод
Для CRM безопасная роль агента начинается с подготовки проверяемого списка изменений. Запись вводят постепенно: узкие права, тестовая группа, отдельное подтверждение и журнал с основанием для каждой строки. Если действие нельзя объяснить или отменить, его не нужно автоматизировать только ради скорости.