Дизайнерское бюро с полным циклом: продали дизайн-проект, сделали проект, дальше ведём ремонт. Три этапа, каждый по несколько месяцев, и клиент один и тот же на всём пути.
В amoCRM всё это лежало в одной воронке. Формально работало. Фактически стадии давно не отражали процесс: между «замер» и «сдача объекта» помещалась половина года и три разных отдела.
Переезд затевали не ради переезда. Уперлись в ограничения по автоматизации и отчётности, а заодно поняли, что переносить текущую схему один в один смысла нет.
Как это было устроено
Одна воронка на всё. Стадии писались когда-то под продажу дизайн-проекта, потом к ним дописывали этапы ремонта. Получился список из полутора десятков стадий, где первая треть про продажу, вторая про проектирование, третья про стройку.
Менеджер по продажам видел стадии, которые его не касались. Прораб — стадии, которые давно прошли. Отчёт по конверсии продаж считал вместе с ним и объекты в стройке, поэтому цифра ничего не значила.
История клиента при этом была ценной: переписка, договорённости, файлы проектов за несколько лет. Терять её при переезде было нельзя категорически.
Из чего складывалась проблема
Один процесс вместо трёх. Продажа, проектирование и ремонт — разные работы с разными участниками, сроками и рисками. В одной воронке они мешали друг другу: невозможно посмотреть конверсию продаж отдельно от загрузки стройки.
Стадии не отражали реальность. Часть стадий пропускалась всегда. Часть означала разное для разных отделов. Классический признак: сделки массово висят на одной стадии, потому что следующая не описывает то, что происходит.
Передача между этапами была устной. Продали — сказали проектировщику. Спроектировали — сказали прорабу. Работало, пока людей мало.
Отчётность не собиралась. Ни по одному этапу нормальных цифр не было, потому что всё смешано.
Страх переезда. Отдельная, вполне реальная проблема: команда боялась, что вместе с системой сломается порядок работы. Этот страх обоснован — так часто и бывает.
Во что это обходилось
Прямых потерь тут меньше, чем в проектах про деньги, но они есть.
Объекты «зависали» на переходах. Дизайн-проект готов, но прораб узнал об этом через неделю — неделя простоя, которую клиент воспринимает как затягивание.
Руководитель не мог планировать. Сколько объектов сейчас в проектировании, сколько выйдет в стройку в следующем месяце, хватит ли бригад — ответы собирались обзвоном.
И конверсия продаж была неизвестна. Компания вкладывалась в рекламу, не понимая, какая доля обращений доходит до договора.
Что мы сделали
Сначала договорились о принципе: переносим данные, но не переносим схему. Схему пересобираем под то, как работа устроена на самом деле.
Разобрали процесс на три. Три воронки: продажа дизайн-проекта, дизайн-проект, ремонт и стройка. У каждой свои стадии — короткие, по 5-7, и каждая описывает реальное состояние, а не намерение.
Настроили переходы. Сделка закрывается успешно в первой воронке — автоматически создаётся сделка во второй, с переносом клиента, объекта и договорённостей. Устная передача превратилась в механику. Прораб получает объект вместе с задачей, а не вместе со звонком.
Перенесли данные с историей. Контакты, компании, сделки, переписка, файлы. Стадии старой воронки сопоставили со стадиями новых — это была отдельная таблица соответствий, которую согласовывали с командой. Закрытые сделки перенесли в архивном виде, активные — на соответствующие стадии новых воронок.
Настроили отчётность по этапам. Конверсия продаж отдельно. Сроки проектирования отдельно. Загрузка стройки отдельно. Плюс сквозной взгляд: путь клиента от заявки до сдачи объекта.
Провели обучение до переключения. Команда работала в новой системе на тестовых данных за неделю до переезда.
Чего это стоило
Около 70 часов и пять недель.
Основная работа была не в переносе, а в сопоставлении. Чтобы разложить полтора десятка старых стадий на три воронки, нужно понять, что каждая из них означала в реальности. Мы собрали руководителя, менеджера, дизайнера и прораба в одной комнате и прошли по списку. Выяснилось предсказуемое: одна и та же стадия означала для отдела продаж и для стройки разные вещи.
Второе — активные сделки. Закрытые переносятся просто, они уже неизменны. А сделку, которая прямо сейчас в работе, нужно поставить на правильную стадию правильной воронки, и решить это может только человек, который её ведёт. Разбирали вручную, вместе с менеджерами.
Третье — дата переключения. Мы настояли на жёсткой дате и на том, что параллельной работы в двух системах не будет дольше нескольких дней. Это создаёт напряжение, но альтернатива хуже: при долгой параллельной работе часть команды остаётся в старой системе, данные расходятся, и переезд не заканчивается никогда.
Что из этого вынести
Миграция — это не про перенос данных. Технически перенос решается скриптами и занимает малую часть проекта. Настоящая работа — разобраться, как компания работает сейчас, и не тащить в новую систему то, что уже не описывает реальность.
Соблазн «перенести один в один, а потом разберёмся» очень силён. Он понятен: так быстрее и не страшно. Но «потом» не наступает — люди привыкают к перенесённой схеме, и она живёт ещё несколько лет.