Человек и ИИ одновременно меняют сделку: как сохранить обе работы

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

Одновременное редактирование сделки требует проверки актуального состояния перед записью. Агент сохраняет основание предложения, меняет только нужные данные и сверяет значимые зависимости. Совместимые изменения можно объединить по принятому правилу; несовместимые пересобирают или передают человеку. Перед внешней отправкой отдельно проверяют, не устарели ли условия и подтверждение сотрудника.

В карточке появился третий автор — время

Представим сделку по поставке оборудования. Утром менеджер открывает карточку: доставка на склад покупателя, расчёт ещё проверяется. Агент читает те же сведения и начинает готовить следующую задачу. Через минуту покупатель звонит человеку: склад закрывается на ремонт, груз нужен на другой адрес. Менеджер меняет адрес и добавляет пояснение. Агент заканчивает работу и отправляет обратно свою версию карточки. В ней красивое резюме, полезная задача и прежний склад. Автоматизация сработала. Работа человека исчезла.

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

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

В агентской CRM Цифра работа человека и агентов находится рядом с карточкой клиента. На примере одной вашей сделки стоит заранее обсудить, как проверяется актуальность контекста перед записью. Видимый интерфейс и перечень ролей полезны для знакомства; механизм разрешения параллельных правок проверяют отдельно при настройке конкретного процесса.

Не путать три похожие неисправности

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

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

Такое разделение экономит время на расследовании. Иначе команда ставит защиту от дублей, повторяет проверку и удивляется: всё по-прежнему ломается, хотя второй задачи действительно больше нет. Исполнитель починил дверь, через которую проблема вообще не входила.

Сначала предложение изменения, затем запись

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

Это не требование хранить копию всей CRM при каждом обращении к модели. Обычно важнее компактный набор зависимостей. Для задачи «подтвердить адрес доставки» нужны действующий адрес, связанная версия предложения и статус согласования. Поле «источник первого знакомства» может к этой операции не относиться. Чем точнее описаны зависимости, тем меньше бессмысленных остановок из-за чужой правки в соседнем разделе.

В HTTP существует стандартный механизм условных запросов: заголовок If-Match в RFC 9110 позволяет связать выполнение операции с совпадением валидатора представления. Это технический пример проверки версии, а не обещание, что любой CRM-коннектор уже её поддерживает. Возможности конкретного API проверяют отдельно.

Для бизнеса смысл проще: «сохрани, если основание ещё актуально». Если оно изменилось, агенту нужен новый контекст. Бесконечно повторять старый запрос — всё равно что приносить вчерашнее распоряжение на новый объект и сильнее стучать печатью.

Карточка конфликта: что должен увидеть сотрудник

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

В примере со складом полезный разбор выглядит так: агент прочитал адрес А; менеджер заменил его на Б после разговора с покупателем; агент предлагает задачу с адресом А. Разногласие относится к адресу, а не ко всей сделке. Новую задачу можно пересобрать по Б, если другие основания не поменялись. Самостоятельно объявлять отменённой продажу здесь незачем.

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

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

Разные поля иногда конфликтуют по смыслу

Популярное правило «если меняли разные поля, объединяем автоматически» работает не всегда. Человек меняет количество товара, агент обновляет итоговую сумму. Формально поля разные. Содержательно новая сумма рассчитана по старому количеству. После такого объединения в карточке получится аккуратная арифметическая фантазия.

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

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

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

Три стратегии вместо одного универсального слияния

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

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

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

Частичное изменение безопаснее полного снимка, но не волшебнее

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

В спецификации JSON Patch, RFC 6902 описаны отдельные операции изменения документа и операция test. Это пример того, как проверку условия можно выразить явно, а не считать молчаливой предпосылкой. Поддержка такого формата зависит от системы; копировать синтаксис в неподдерживающий API бессмысленно.

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

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

Самый дорогой конфликт случается перед внешним действием

Ошибочную заметку можно поправить. Отправленное покупателю предложение уже живёт вне CRM. Поэтому проверку актуальности разумно ставить не только перед внутренней записью, но и перед действием, которое увидит клиент: письмом, сообщением, заказом обратного звонка или отправкой документа.

Между подготовкой черновика и отправкой проходит время. За это время человек может отменить предложение, заменить контакт или получить отказ. Одобрение старого текста не всегда означает одобрение его отправки на любой будущей версии сделки. В задаче нужно определить, какие изменения делают согласование устаревшим.

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

Журнал нужен, но исправление не равно откату времени

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

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

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

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

Как проверить маршрут на коротком наборе столкновений

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

1. Независимая заметка человека появляется между чтением и записью агента. Она должна сохраниться.
2. Человек меняет поле, которое агент собирался обновить. Система должна показать конфликт либо пересобрать предложение по принятому правилу.
3. Человек меняет зависимое поле: количество перед расчётом суммы. Формальная непересекаемость полей не должна скрыть проблему.
4. Отменяется дальнейшее касание перед подготовленной отправкой. Устаревшее действие нельзя считать действующим поручением.
5. Во время разбора появляется ещё одна правка. Решение конфликта тоже должно опираться на актуальное состояние.

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

Экономика: сколько стоит лишнее согласование

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

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

Если карточку всегда меняет один человек, а агент только предлагает текст в чате, сложный механизм слияния может не окупиться. Хватит понятного подтверждения и сохранения источника. Если несколько участников пишут одновременно, а результат запускает внешние действия, цена устаревшего основания другая. Архитектура должна соответствовать этой разнице, а не моде на очередной технический термин.

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