«Менеджер все исправил, а CRM вернула обратно»: как избежать перезаписи данных при интеграции

Менеджер поговорил с клиентом, помог выбрать тариф и договорился об оплате. Сделка в amoCRM называется «Анна, курс по дизайну, тариф с поддержкой», стоит на этапе «Ждем оплату», ответственный назначен.

Через час Анна заполняет форму на сайте, чтобы получить ссылку на вебинар.

Теперь сделка называется «Заявка с сайта», стоит в начале воронки и назначена другому сотруднику. Он видит необработанное обращение и звонит: «Здравствуйте! Вы интересовались нашим курсом?»

Анна объясняет, что уже все обсудила. Первый менеджер восстанавливает карточку. При следующей регистрации все повторится.

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

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

Первая заявка и повторная: это разные задачи

При первом обращении все просто: создать сделку, дать название, поставить начальный этап, назначить ответственного.

При повторном те же действия вредят. С клиентом уже работает менеджер, распределять его заново незачем. Об оплате договорились, и регистрация на вебинар не должна возвращать сделку в начало.

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

Поэтому для каждого события решаем один вопрос: что оно вправе изменить. Регистрация на вебинар подтверждает интерес и не отменяет договоренности с менеджером. Оплата заказа, наоборот, обязана обновить суммы и этап.

Кто управляет каждым полем

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

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

Поле	Откуда берем	Что делаем при повторном событии
Название сделки	шаблон при создании, дальше правит менеджер	регистрация название не трогает
Ответственный	распределение при первом обращении	остается текущий менеджер
Этап	действия менеджера и события оплаты	регистрация не двигает сделку назад, оплата двигает вперед
Стоимость заказа	система, где оформлен заказ	обновляем, когда изменился этот заказ
Оплачено и остаток	система учета оплат	обновляем по каждой подтвержденной оплате заказа
Город и другие сведения о клиенте	форма или менеджер	пустое значение не записываем; что делать с другим заполненным, решаем отдельно
Источник обращения	форма или реклама	заранее решаем, что храним: первый источник, последний или оба в разных полях

Отдельно про суммы. Курс стоит 50 000 ₽, клиент внес 10 000 ₽. Это три значения: стоимость 50 000 ₽, оплачено 10 000 ₽, осталось 40 000 ₽. Если писать все в одно поле «Сумма», спорить начнут не только сервисы, но и сотрудники: каждый прочтет его по-своему.

Решение: у каждого события свои права

Договоренности из таблицы сводятся к трем правилам. Они нужны в любой интеграции.

1. Название и ответственный задаются при создании сделки. Повторное событие их не трогает. Если клиента нужно передать другому менеджеру (увольнение, смена отдела), это делается отдельно и осознанно, а не как побочный эффект заполненной формы.
2. Этап двигается только вперед. Для каждого события перечислите этапы, с которых его нельзя уводить. Регистрация не трогает сделку, которую менеджер уже взял в работу. Запоздавшее событие частичной оплаты не возвращает сделку из «Оплачено».
3. Пустое значение не стирает заполненное. Если в новой форме не было поля «Город», в CRM остается город, который записал менеджер. При этом ноль не пустота: нулевой остаток после полной оплаты должен записаться.

Для школы с этапами «Новая заявка», «Взята в работу», «Ждем оплату», «Частично оплачено», «Оплачено» это три отдельных правила передачи.

	Регистрация	Частичная оплата	Полная оплата
Когда срабатывает	на каждую регистрацию	оплачено больше 0 и остаток больше 0	оплачено больше 0 и остаток равен 0
Название и ответственный	только при создании сделки	не меняем	не меняем
Этап	«Новая заявка», но не с этапов «Взята в работу», «Ждем оплату», «Частично оплачено», «Оплачено»	«Частично оплачено», но не с «Оплачено»	«Оплачено» с любого этапа
Что обновляем	контакты и источник, пустые значения пропускаем	оплачено и остаток	оплачено и остаток

Отличить частичную оплату от полной получится, если система заказов передает оплаченную сумму и остаток. Если приходит только факт оплаты, хватит одного правила с этапом «Оплачено».

Что это дает:

- Первая заявка создает сделку с шаблонным названием на этапе «Новая заявка» и назначает менеджера.

- Повторная регистрация обновляет контактные данные. Название, менеджер и этап остаются как были.

- Оплата двигает сделку вперед. Запоздавшее событие частичной оплаты не вернет ее из «Оплачено».

Запрет из правила регистрации на правила оплаты не переносим. Оплата как раз то событие, после которого этап должен измениться.

Как это сделано в Vakas-tools (Вакас-тулз)

Vakas-tools (Вакас-тулз) передает заявки, регистрации и оплаты из форм, вебинаров и платежных систем в amoCRM, Битрикс24 и другие сервисы (подробнее о механике работы - на странице интеграции с amoCRM). Три правила выше в нем включаются настройками, без программиста:

1. Название и ответственный. В действии «Сделка (создать/обновить)» выключены «Всегда менять название» и «Всегда менять ответственного».
   
2. Этап. Там же «Этап воронки» и исключения «Не перемещать если сделка на этапах». Исключения действуют и на действие «Изменить этап» в том же правиле.
   
3. Пустые значения. В действии «Сделка → Доп. поля» у каждого поля флажок «Если пусто, пропустить». Он включен по умолчанию, ноль при этом записывается.
   
4. Разные события. Правила для регистраций и оплат лежат на разных вкладках, условия задаются по полям «Оплачено» и «Осталось оплатить».
5. Источник. Настройка базы «Сохранять UTM метки только при первом попадании в базу»: включена, в CRM уходит первый источник; выключена, последний.
   

Если после настройки данные все равно меняются

Причину ищем по шагам, от конкретной сделки к правилам.

1. Возьмите одну сделку

Не «интеграция портит все карточки», а один случай: ссылка на сделку, значение до, значение после, время.

В 14:10 менеджер перевел сделку на этап «Ждем оплату». После повторной регистрации в 14:25 она оказалась на этапе «Новая заявка». Найдите это событие в журнале интеграции: какое правило сработало, какие данные ушли в CRM и что она ответила. В Vakas-tools (Вакас-тулз) это раздел «История событий». Сравните с карточкой сделки.

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

2. Убедитесь, что обновляется нужная сделка

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

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

1. клиент оставил другой email и телефон: контакт не нашелся, появились новый контакт и вторая сделка;
2. сделка лежит в другой воронке или уже закрыта: интеграция ее не видит и создает новую;
3. у человека несколько открытых сделок: обновилась не та.

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

Заявки на другой продукт лучше вести в своей воронке, чтобы они не попадали в чужие сделки.

Сначала находим правильную сделку, потом решаем, что в ней обновлять.

В Vakas-tools (Вакас-тулз) поиск задается в «Общих настройках» amoCRM: воронки, закрытые сделки, дополнительное поле для поиска. Эти настройки одни на все правила базы, поэтому после изменения проверьте на тестовом контакте и регистрацию, и оплату.

3. Проверьте, не спорят ли правила между собой

Если одно событие подходит под несколько правил, последнее может перезаписать то, что сделало первое. Типичная картина: первое правило сохраняет этап и менеджера, а второе, общее для всех заявок, снова ставит «Новую заявку».

Если этап меняется вопреки запретам, ищите другое правило, которое двигает этап без них, или автоматизацию в самой amoCRM.

В Vakas-tools (Вакас-тулз) правила выполняются по порядку. Флажок «Стоп» («После выполнения не выполнять другие правила») пропускает следующие правила этого же сервиса для текущего события, правила других сервисов продолжат работать. Прежде чем его включать, посмотрите, что стоит ниже: вместе с конфликтующим обновлением можно отключить нужную задачу менеджеру.

4. Не путайте «пусто» и «удалить»

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

Но это решает одну задачу из двух. Если менеджер записал «Казань», а новая форма передала «Москва», оба значения заполнены, и замена пройдет. Здесь нужно ваше решение: верить последнему ответу клиента, сохранять правку менеджера или писать ответ из формы в отдельное поле, чтобы менеджер видел оба.

Отдельно протестируйте ноль. Нулевой остаток после полной оплаты это данные, а не пустое значение, и в поле он должен записаться.

Как проверить настройку

Перед изменениями сделайте скриншоты правил: условия, действия, порядок. Тестируйте на новых контактах и убедитесь, что тест не запустит рассылку реальным клиентам.

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

Тест	Что должно получиться
Первая заявка нового клиента	создана одна сделка: шаблонное название, этап «Новая заявка», менеджер назначен
Повторная регистрация после работы менеджера	название, менеджер и этап не изменились, контактные данные обновились
Событие без значения в дополнительном поле	заполненное раньше поле осталось
Частичная оплата заказа	«Оплачено» и «Осталось» обновились, этап «Частично оплачено»
Полная оплата заказа	остаток 0, этап «Оплачено», вторая сделка не появилась
Заявка того же человека на другой продукт	старая сделка не изменилась

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

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

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

Что делать с уже испорченными карточками

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

Частые вопросы

Можно ли обновлять контакт, не меняя этап сделки?

Да. Этап защищается отдельно: в правиле регистрации запретите менять этап у сделок на тех этапах, с которых их двигать нельзя. Контактные данные и дополнительные поля при этом продолжат обновляться.

Почему вместо обновления появилась вторая сделка?

Интеграция не нашла подходящую сделку и создала новую. Проверьте, нашелся ли контакт (не оставил ли клиент другие email и телефон), в той ли воронке сделка, не закрыта ли она и есть ли в ней номер заказа, если поиск идет по нему.

Почему данные меняются и после отключения найденного правила?

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

Менеджер исправляет стоимость, а система заказов возвращает прежнюю. Что делать?

Разберитесь, что именно он правит. Если это цена, о которой договорились до оформления, заведите для нее отдельное поле. Если это стоимость уже оформленного заказа, исправлять ее нужно в системе заказов, откуда она и приходит. Иначе два значения так и будут сменять друг друга в одном поле.

Подойдет ли это для Битрикс24 или другой CRM?

Да. Вопросы те же: какую запись ищем, что обновляем, что сохраняем после ручной работы. Отличаются только названия настроек. В Vakas-tools для Битрикс24 это, например, «Всегда менять название сделки», «Всегда менять ответственного» и «Не перемещать если сделка на стадиях».

Шпаргалка: что проверить

Что случилось	Что проверить в любой интеграции	Где это в Vakas-tools (Вакас-тулз)
Название снова «Заявка с сайта»	меняется ли название при обновлении сделки	«Всегда менять название»
Сделка ушла другому менеджеру	переназначается ли ответственный при обновлении	«Всегда менять ответственного»
Сделка вернулась в начало воронки	есть ли запрет на этапы и нет ли другого правила, которое двигает этап	«Не перемещать если сделка на этапах», «Изменить этап» в других правилах
Заполненное поле стало пустым	записывает ли интеграция пустые значения	флажок «Если пусто, пропустить»
Обновилась не та сделка	как ищется сделка: воронка, номер заказа	«Общие настройки»: «Искать только в воронках», «Доп. поле сделки для поиска»
Появилась вторая сделка	нашелся ли контакт, та ли воронка, не закрыта ли сделка	«Общие настройки»: «Поиск дублей сделок», «Учитывать закрытые сделки»
Все настроено, а данные меняются	порядок правил и другие источники изменений	порядок правил, «Стоп», «История событий»

Коротко

Вернемся к Анне. Она повторно регистрируется на вебинар. Сделка остается на этапе «Ждем оплату», у прежнего менеджера, с уточненным названием. Новое обращение учтено, работа менеджера не отменена. Потом приходит оплата заказа, и вот теперь обновляются суммы и этап.

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

Начните с одной сделки, которую менеджерам уже приходилось чинить дважды.

Если хотите собрать такую схему без программиста, в Vakas-tools (Вакас-тулз) правила для amoCRM собираются из готовых действий, а для первого запуска есть мастер настройки. 

14 дней бесплатно, без привязки карты: подключить.