Два отдела, два CRM, один владелец. Классика: опт сидит в amoCRM, розница уехала в Kommo после ребренда, а отчёт «по всей компании» собирает аналитик по пятницам в Excel. 12 часов в неделю - консервативная оценка для команды из 15 менеджеров и двух РОПов. Не потому что CRM плохие, а потому что воронка одна, а источники правды - две.
Ниже - как свели продажи на одном экране: единая модель этапов, сопоставление статусов, детализация по клику до сделки. Без «миграции всего в одну систему за квартал». Разбор опирается на кейс CRM-дашборда - те же принципы, другой контекст (два вендора).
KPI воронки и формулы конверсии - в «KPI воронки продаж». Критерии рабочего экрана - в чек-листе дашборда.
Почему «просто выгрузить обе CRM» не работает
Выгрузки дают разные названия этапов, разную семантику «успешно закрыто», разные поля источника. Сводная таблица покажет две несопоставимые воронки. Владелец увидит цифры - и не поверит ни одной.
Типичные расхождения:
| Проблема | Последствие |
|---|---|
| «Оплата получена» vs «Сделка успешна» | Завышенная конверсия в одном CRM |
| Разные валюты и НДС в карточке | Неверная сумма воронки |
| Дубли контактов между базами | Двойной учёт лидов |
| Разные часовые пояса в API | Сделки «переезжают» между днями |
Вывод: сначала единая модель воронки (5-7 этапов), потом сопоставление каждого статуса каждой CRM в эту модель.
Шаг 1. Единая модель этапов (не копия amo или Kommo)
Возьмите язык бизнеса, не язык интерфейса:
- Новый лид
- Квалификация
- КП / демо
- Согласование / счёт
- Оплата / закрыто
- Отказ (с причиной)
Для каждого этапа - определение входа и выхода: «лид считается квалифицированным, когда заполнены бюджет и ЛПР». Это документ на полстраницы, согласованный с обоими РОПами.
Как проверить: два менеджера из разных CRM называют текущий этап одной сделки - в дашборде они попадают в одну группу этапов.
Что сделать: рабочая сессия на 90 минут: таблица «статус в amo → статус в Kommo → этап модели».
Шаг 2. Слой нормализации данных
Технически - выгрузка и сверка или сводное представление в хранилище: сырые сделки из обоих API → таблица сводная таблица сделок с полями источник CRM, единый этап, сумма в рублях, id менеджера, дата создания.
Правила нормализации:
- сумма приводится к рублям по курсу на дату сделки (если были валютные);
- отказ без причины → этап «Отказ», флаг
причина не указана; - тестовые и дубли - фильтр по тегу или полю «тип клиента».
Обновление: для операционного экрана раз в час достаточно; для владельца «утренний срез» - снимок на 08:00.
Как проверить: за неделю сумма сводная таблица сделок по закрытым = сумма закрытых в amo + Kommo с допуском до 0,5% (округления, часовые пояса).
Шаг 3. Один экран: воронка + разрезы
Структура дашборда (как в кейсе):
| Блок | Содержание |
|---|---|
| KPI-полоска | Лиды, конверсия в оплату, сумма в работе, средний цикл |
| Воронка | Этапы модели, количество и сумма, конверсия между этапами |
| Разрез CRM | Доля amo vs Kommo без двойного учёта |
| Разрез менеджер / канал | Фильтры |
| Детализация по клику | Клик по этапу → список сделок с ссылкой в исходную CRM |
Владелец не выбирает «какую CRM открыть» - он видит компанию целиком. РОПы получают фильтр «моя CRM» по умолчанию.
Как проверить: владелец за 10 секунд отвечает: «Где узкое место и в каком CRM оно сильнее?»
Шаг 4. Детализация по клику и обратная ссылка
Без детализации по клику дашборд - картинка. Нужен список сделок: ID, сумма, менеджер, дней на этапе, ссылка открыть в amo/Kommo. Иначе РОП снова идёт в две системы искать «кто завис».
Дополнительно - алерт: «более N сделок > 7 дней на этапе Согласование» с топ-5 в Telegram. Это переносит 12 часов ручной сводки в 15 минут реакции.
Экономика: откуда минус 12 часов
| Было | Стало |
|---|---|
| Пятничная сводка аналитика (4 ч) | Автообновление, сверка раз в неделю (0,5 ч) |
| Два РОПа собирают слайды (3+3 ч) | Фильтр по отделу в дашборде |
| Споры «чья цифра правильная» (2 ч) | Один источник + детализация по клику |
| Поиск зависших сделок вручную (2+ ч) | Алерт по порогу дней на этапе |
Итого порядка 12-14 часов/нед на команду. При стоимости часа 800-1000 ₽ - 40-55 тыс. ₽/мес только на сбор отчётности, без учёта ошибочных решений из-за старых цифр.
Типичные ошибки при объединении двух CRM
Миграция «в голове», но не в данных. Руководство решило «считаем Kommo как amo», но статусы не пересмотрели - в отчёте половина сделок в «неизвестной» группе.
Двойной учёт лидов. Один контакт завели в обе базы после слияния отделов. На дашборде лиды удвоились, конверсия упала в два раза. Нужен удаление дублей по телефону или email с правилом «главная CRM».
Разные определения «успеха». В amo успех - оплата на счёт, в Kommo - отгрузка. В единой модели зафиксируйте один момент закрытия, иначе воронка «течёт» на последнем этапе.
Сводка только по сумме, без этапов. Владелец видит общую выручку, но не видит, что опт зависло на согласовании, а розница проваливается на квалификации. Воронка по модели обязательна, не только KPI-полоска.
Когда не стоит объединять воронку
- Планируете слияние в одну CRM в ближайшие 2 месяца - дешевле дождаться миграции.
- Процессы принципиально разные (длинный enterprise vs импульсная розница) - одна воронка из 7 этапов всем навредит; лучше два экрана и один KPI «выручка» сверху.
- Нет дисциплины статусов хотя бы в одной базе - сначала качество данных в CRM, потом дашборд.
С чего начать на этой неделе
- Опишите 6 этапов единой модели и согласуйте с двумя РОПами.
- Выгрузите по 50 сделок из каждой CRM и вручную разметьте этап модели - найдёте 80% конфликтов сопоставления.
- Соберите прототип воронки на одной неделе данных в Google Таблицы, Looker Studio или кастомном дашборде - без идеальной выгрузки и сверки.
- Покажите владельцу - если открыл второй раз за неделю, инвестируйте в рабочую цепочку данных и детализацию по клику.
Две CRM и один отчёт о прибылях и убытках? Обсудим ваш кейс - разберём сопоставление статусов и оценим, сколько часов уйдёт с ручных отчётов.