Клиент и контекст
Сеть фитнес-центров в Москве (7 клубов). Использовали amoCRM для управления продажами и клиентскими процессами. Применяли виджет стороннего разработчика для объединения дублей сделок, который работал в нескольких воронках одновременно: цикл продаж, прогрев, апсейл.
Проблема / задача
Клиент ошибся и применил объединение дублей на неверную группу сделок. Ошибку заметили не сразу, в итоге склеилось около 76 тысяч событий объединения, которые были не нужны. Это привело к серьёзным последствиям: клиентам пришла неверная рассылка (так как сделки смешались), нарушилась аналитика, поломались бизнес-процессы.
Стандартными средствами amoCRM это нельзя было реализовать, потому что массовая отмена через интерфейс невозможна — можно только просматривать список событий и смотреть события по определённой сделке. Ручная отмена заняла бы сотни часов работы (если менеджер тратит на открепление сделки 30 секунд, на 76 тысяч сделок ушло бы более 600 часов). Откат из бэкапа возможен, но это не быстрая операция.
Решение
Мы разработали сервис для массовой отмены объединений, который автоматически обрабатывает тысячи событий склейки, имитируя действия пользователя в интерфейсе amoCRM.
Решение делает следующее: собирает все события объединения, определяет, какие можно отменить (по наличию специального кода), отправляет запросы на отмену и отслеживает статус выполнения каждой операции. Все результаты сохраняются в базу данных для формирования детального отчёта, чтобы клиент видел полную картину: что можно отменить автоматически, а что требует других решений.
Использовали PHP (Laravel 12) и недокументированное API через реверс-инжиниринг фронтенда, так как официального API для работы с дублями нет.
Сроки выполнения: разработка скрипта заняла 1 рабочий день, затем скрипт отрабатывал 1 ночь, после чего amoCRM ещё около 12 часов постепенно подтягивало события.
Как это работает
Простыми словами: мы автоматизировали то, что пользователь делает вручную — нажимает кнопку "Отменить" для каждого объединения. Но сделали это для 76 тысяч событий одновременно.
По шагам:
- Клиент предоставил ссылку на фильтр событий. Мы автоматически собрали все события в базу данных.
- Выяснили механизм отмены: для каждого события склейки, которое можно отменить, система генерирует специальный код. По этому коду запускается отмена через внутренний механизм amoCRM.
- Алгоритм:
- Собрали события, которые можно отменить (те, у которых есть нужный код)
Отправили запросы на отмену, получили номера задач для отслеживания
Проверили статус выполнения каждой задачи
- Обрабатывали события порциями, чтобы не перегрузить систему.
- Все результаты сохранялись в базу для формирования отчёта.
Сложности и как мы их обошли
При изучении вопроса обнаружили важные ограничения системы amoCRM:
- Отменить объединение можно только в течение месяца с момента объединения
- Если после объединения в сделке произошло более 5 событий (например, менеджер провёл работу), отмена становится недоступна
Ошибка была пару дней назад, поэтому первое ограничение нас не касалось. Но в некоторых сделках уже провели работу, появились изменения, и кнопка отмены стала недоступна для них.
Технические сложности:
- Официального API для работы с дублями нет
- Обработка 76 тысяч событий с учётом ограничений системы
- Таймауты при запросах статуса задач получения событий
Как решили:
- Использовали недокументированное API через реверс-инжиниринг фронтенда, так как официального API нет
- Разбили обработку на порции через Laravel очереди (10 воркеров, до 10 запросов в секунду). Это превышает лимиты API, но так как мы имитируем фронтенд, нас эти ограничения не касаются
- Добавили автоматический повтор для запросов, которые упали по таймауту
- Сохраняли все результаты в базу для формирования отчёта
Обсудив ситуацию с заказчиком, приняли решение отменить объединение для тех событий, где это возможно, а по остальным передать информацию.
Результаты
Было:
- 76 тысяч ошибочных объединений
- Ручная отмена невозможна (сотни часов работы)
- Откат из бэкапа — медленная операция
- Нарушены бизнес-процессы, неверные рассылки, поломанная аналитика
Стало:
- Разработка заняла 1 рабочий день, обработка 69,4 тысячи событий из 76 тысяч (91% от общего объёма) — это сильно облегчило работу, так как сразу были понятны рамки ответственности: что можно отменить автоматически, а что требует других решений
- Остальные 6,6 тысяч событий были без возможности отмены (в них уже произошли изменения после объединения) — передали информацию заказчику
- Несколько задач свалилось с таймаутом, но при автоматическом повторе они успешно обработались
В итоге клиент получил:
- Быстрое решение: вместо 600+ часов ручной работы — разработка за 1 рабочий день, выполнение заняло около 1,5 суток (ночь работы скрипта + 12 часов на подтягивание событий в amoCRM)
- Управляемый откат 91% объединений
- Детальный отчёт по всем событиям с пониманием, что делать с остальными 9% (возможно, воссоздание сделок по событиям)
Цитата / обратная связь клиента
Клиент остался доволен результатом.
Вывод / чему научил кейс
Этот кейс показывает, что даже критичные массовые ошибки в amoCRM можно решить быстро и эффективно, если есть понимание внутренних механизмов системы. Мы провели реверс-инжиниринг процесса объединения и расклейки сделок, изучили ограничения системы и получили готовые наработки по управляемому откату массовых операций.
Польза для других клиентов: если произошла массовая ошибка в amoCRM (неправильное объединение, массовое изменение данных, ошибочные действия), мы можем быстро разработать решение для отката, даже если стандартными средствами это невозможно. Важно, что мы понимаем ограничения системы и можем сразу сказать, что можно откатить, а что потребует других подходов.
Что отработали как команда: работу с недокументированным API amoCRM, обработку больших объёмов данных с учётом лимитов, создание прозрачных отчётов. Это усилило нашу экспертизу в решении срочных критических задач и работе с ограничениями платформы.