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

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

Как все начиналось

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

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

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

А дальше начинается то, о чем обычно не пишут в кейсах…

Как мы сами создали себе аварийную ситуацию

По сути к аварии нас привело несколько решений в совокупности.

Во-первых, ложное ощущение безопасности

У клиента уже был установлен внешний виджет для поиска и склейки дублей. И мы посчитали его безопасным. Потому что им пользовались до нас, у команды сформировалось ощущение, что раз он стоит, значит можно смело опираться.

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

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

Во-вторых, массовая операция на боевом контуре

Мы включили массовую склейку прямо в рабочей амоCRM. Настроили автоматическую обработку по идентификатору и применили ее ко всем существующим сделкам.

По факту, запустили неконтролируемую массовую операцию по аккаунту. Часть сделок начала склеиваться совсем не так, как мы ожидали.

В-третьих, отсутствие тестов и бэкапа

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

То есть, мы пошли сразу в большой объем без страховки и тестовых проверок..

В-четвертых, поздний стоп-кран

Аналитик довольно быстро увидел, что склейка идет неправильно. Он написал в поддержку виджета, но не начал бить тревогу и всё останавливать.

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

В результате операции склеилось больше 70 тысяч сделок.

Что мы сделали, когда стало понятно, что все плохо

В такой ситуации у подрядчика всегда есть несколько вариантов.

1. Сделать вид, что так и было задумано. 

2. Перевести фокус на «особенности платформы» и предложить клиенту новый проект уже по восстановлению данных.

Мы же пошли по другому пути. Более честному.

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

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

Клиенту мы подробно объяснили, что произошло и что именно делаем. Дополнительные разработки и восстановление на счет не выставляли, эти затраты мы взяли на себя.

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

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

Это не про одного «плохого аналитика»

Удобно было бы сказать, что виноват аналитик, он недосмотрел, но мы его наказали, работаем дальше. Но это было бы враньем.

Корень проблемы оказался системным. Не было четких границ полномочий: 

• что аналитик может запускать сам

• что требует согласования с руководителем проекта или отдела.

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

Не было культуры эскалации. Человек видел, что дело идет не так, но не был приучен включать режим “стоп, все откладываем, зовем старших, пока не разобрались”.

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

Какие правила появились после аварии

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

1. Массовые изменения только через отдельную задачу

Любые массовые изменения в CRM, такие как склейка дублей, импорты, массовые обновления, теперь идут только через отдельную согласованную задачу.

Сначала тест на ограниченном сегменте. Внутри команды, это обязательное второе одобрение. Клиент заранее получает понятное описание рисков.

2. Опасные операции только через эскалацию

Операции, которые могут влиять на большие объемы данных и деньги, требуют обязательного согласования с руководителем проекта или отдела.

С заранее прописанным планом как запускаем, как отслеживаем, как останавливаем, если что-то идет не так.

3. Пересмотр подхода к выбору инструментов

Цена перестала быть главным фильтром. Теперь мы смотрим на наличие логов, возможность отката, ограничения на массовые операции.

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

4. Этот кейс стал учебником для команды

Мы подробно разобрали все события. Отметили, где прозевали первые сигналы. Сформировали правила, после которых никто больше не играет с кнопкой «применить ко всем» на боевом аккаунте.

Что с этого взять владельцу бизнеса

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

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

Или берет ответственность на себя, вытаскивает ситуацию за свой счет и на базе этого строит более сильную систему на будущее?

Если у вас есть amoCRM и подрядчик, который её сопровождает, достаточно задать внутри один простой вопрос:

Какие у нас правила для массовых изменений в амоCRM и кто имеет право нажимать на такие кнопки?

Ответ на него очень хорошо показывает, насколько рисково вы работаете прямо сейчас.