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

Самая дорогая ошибка делается в первую неделю и выглядит безобидно: структуру таблицы повторяют в CRM один в один. Колонки становятся полями, значения колонки «Статус» — этапами воронки, комментарии — примечаниями. Получается та же таблица, только медленнее и за деньги. Разница между колонкой статуса и этапом воронки не косметическая, и разобраться с ней надо до настройки, а не после.

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

Что переносить, а что оставить в архиве

Соблазн перенести всё понятен: база копилась годами и субъективно кажется активом. На практике мёртвые строки не бесплатны — они удлиняют загрузку, портят поиск, ломают отчёты по конверсии и создают ощущение, что в системе много данных, хотя работать не с чем.

Рабочее правило отбора состоит из двух условий, и выполняться должны оба: последнее касание не старше 18 месяцев и наличие хотя бы одного рабочего контакта — телефона или почты, по которым можно связаться сегодня. Строки без имени контактного лица, с корпоративным номером приёмной и без единой отметки о разговоре — это не клиенты, это список компаний, который при необходимости покупается заново.

Категория строкВ модельной базеКуда едет
Касание за 18 месяцев, есть рабочий контакт1 150В CRM как контакты и компании
Касание за 18 месяцев, контакта нет250В архив, при обращении заводится заново
Касание старше 18 месяцев1 800В архив на чтение, отдельным файлом
Из перенесённых — открытые сделки в работе54В CRM вручную, а не загрузкой
Всего строк в исходной таблице3 200
Открытые сделки заводят руками

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

Подготовка файла: пять требований

Файл готовят до того, как выбрана система: требования у всех российских CRM почти одинаковые, а времени это занимает больше, чем настройка. Общие принципы приведения данных в порядок разобраны в статье про подготовку данных перед внедрением; ниже — минимум, без которого загрузку придётся повторять.

  1. 1Одна строка — один клиент. Не «клиент плюс сделка плюс платёж» в одной строке. Если у клиента три сделки, в файле клиентов он один раз, а сделки лежат на отдельном листе.
  2. 2Отдельный лист для сделок со ссылкой на клиента. Связь делается по вашему собственному идентификатору, а не по названию компании: названия пишутся по-разному даже одним человеком, и склеить их потом нельзя.
  3. 3Единый формат телефона. Приведите всё к виду +7XXXXXXXXXX, без скобок, дефисов и пробелов. Второй и третий номер — в отдельные колонки, а не через запятую в одной: колонка с двумя номерами загрузится как один несуществующий.
  4. 4Никаких заполнителей вместо пустоты. «—», «нет данных», «уточнить», «??» — это значения, и они приедут в базу как значения. Пустая ячейка честнее и чистится сама.
  5. 5Свой идентификатор в каждой строке. Он остаётся в CRM отдельным полем и позволяет сверить загрузку, найти потерянные строки и при необходимости повторить загрузку без дублей. Без него сверка превращается в ручное сличение по названиям.

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

Почему структуру таблицы нельзя повторять в CRM

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

Колонка «Статус» в таблицеЭтап воронки в CRM
Кто задаёт значенияЛюбой менеджер, любым текстомАдминистратор, фиксированный список
Что значит «в работе»У каждого своё пониманиеЕсть определение и условие перехода на следующий этап
След от измененияНет: было одно значение, стало другоеКаждый переход записан с датой, автором и длительностью этапа
Что происходит при сменеНичегоЗадача менеджеру, письмо клиенту, уведомление руководителю
Как считается конверсияРуками, раз в месяц, по копии файлаАвтоматически, между любыми двумя этапами, в любой момент
сравнениеpereezd-s-tablits-na-crm--01
Сравнение колонки статуса в таблице и этапа воронки в CRM по пяти признакам

Сравнение в две колонки. Левая — «Колонка «Статус» в таблице»: подписи «значение вписывает человек», ««в работе» у каждого своё», «изменение не оставляет следа», «при смене ничего не происходит», «конверсия считается руками раз в месяц». Правая — «Этап воронки в CRM»: «фиксированный список», «есть условие перехода», «история с датой и автором», «смена запускает задачу и уведомление», «конверсия считается сама». Внизу общая подпись: «Пять полей таблицы можно перенести. Шестое — нельзя, его надо придумать заново». Чертёжный стиль, подписи по-русски.

Похожие внешне, они отличаются главным: у этапа есть условие перехода и история

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

План на четыре недели

Четыре недели — реальный срок для компании без обмена с учётной системой. Если в проекте есть обмен с 1С, добавляйте ещё три-четыре недели и считайте это отдельным этапом, который начинается после боевого старта, а не вместо него.

  1. 1
    Неделя 1: описание процесса и решение о полях

    Карта воронки на одном листе, список обязательных полей (не больше семи), правило «одна открытая сделка на контакт», решение по отбору строк для переноса. Результат недели — схема, под которой подписался руководитель отдела продаж, а не подрядчик.

  2. 2
    Неделя 2: настройка и подключение источников

    Воронка, поля, права доступа, шаблоны писем и счетов. Параллельно подключаются источники заявок: форма сайта, общий ящик отдела, телефония. Результат — система, в которую можно завести сделку и в которую сама приезжает заявка.

  3. 3
    Неделя 3: тестовая загрузка, сверка и обучение

    Сначала 100 строк, сверка по трём числам (количество записей, количество уникальных телефонов, сумма по сделкам), только потом боевая загрузка. Обучение — по ролям и по 40 минут: менеджеру и руководителю нужны разные экраны и разные привычки.

  4. 4
    Неделя 4: боевой старт и параллельное ведение

    Все новые обращения заводятся только в CRM. Таблица остаётся в режиме чтения и ведётся параллельно не больше 10 рабочих дней. Ежедневный пятиминутный разбор: что не влезло, чего не хватает, где пришлось выкручиваться.

этапыpereezd-s-tablits-na-crm--02
Лента четырёх недель переезда с результатом каждой недели и датой отключения таблицы

Горизонтальная лента времени из четырёх сегментов. Неделя 1 — «Описание процесса», результат «схема воронки на одном листе». Неделя 2 — «Настройка и источники заявок», результат «система принимает заявку». Неделя 3 — «Тестовая загрузка 100 строк и обучение», результат «1 150 контактов в базе, сверка по трём числам». Неделя 4 — «Боевой старт», результат «все новые сделки только в CRM». За четвёртой неделей отдельная отметка «+10 рабочих дней — отключение таблицы» и точка «30-й день: проверка критерия». Чертёжный стиль, подписи по-русски.

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

Дата отключения таблицы назначается в первый день боевого старта и объявляется вслух, а не выводится потом из ощущения «все привыкли». Привыкают ровно до тех пор, пока есть куда отступать. Практический предел — 10 рабочих дней: за две недели видно всё, что не влезло в систему, а дальше параллельный контур просто закрепляет старую привычку. Почему запреты при этом не работают и что делать вместо них — разобрано в статье про параллельный учёт в таблицах.

Сколько стоит переезд и что стоят таблицы

Модельная компания: 25 человек, отдел продаж из семи менеджеров и руководителя, база 3 200 строк, 260 обращений в месяц, конверсия обращения в сделку 20 %, прибыль со сделки 22 500 ₽. Сначала — во что обходится текущее положение дел.

Что таблицы стоят компании в месяц
Ведение и сверка таблиц: 7 менеджеров × 25 мин × 21 рабочий день = 3 675 мин = 61,25 ч × 700 ₽/час42 875 ₽
Сборка отчёта по продажам вручную: 6 ч × 1 500 ₽/час9 000 ₽
Разбор расхождений между копиями файла: 8 ч × 700 ₽/час5 600 ₽
Потерянные обращения: 3 % от 260 = 7,8 шт × 4 500 ₽ ожидаемой прибыли35 100 ₽
Итого92 575 ₽ в месяц, или 1 110 900 ₽ в год

Ожидаемая прибыль с обращения здесь считается просто: 22 500 ₽ прибыли со сделки × 20 % конверсии = 4 500 ₽. Три процента потерь — консервативная оценка для контура, где заявка попадает в таблицу вручную; своё число проверяется сверкой числа обращений в почте и телефонии с числом строк в файле за тот же месяц.

Смета переезда: 7 менеджеров, база 3 200 строк, без обмена с 1С
Описание процесса, настройка воронки, полей и прав70 000 ₽
Чистка и подготовка файла на 3 200 строк45 000 ₽
Тестовая и боевая загрузка со сверкой по трём числам30 000 ₽
Подключение источников заявок: сайт, общий ящик, телефония100 000 ₽
Обучение по ролям и две недели сопровождения после старта40 000 ₽
Лицензии на 8 пользователей и поддержка, в месяц19 200 ₽
Итого285 000 ₽ разово плюс 19 200 ₽/мес, за первый год 515 400 ₽

Реалистичная доля снимаемых потерь — около 55 %: часть ручной работы никуда не денется, она переедет в заполнение карточек, а часть обращений будет теряться и дальше. Это 50 916 ₽ в месяц, за вычетом лицензий и поддержки — 31 716 ₽. Окупаемость: 285 000 / 31 716 = 9 месяцев. Смета вырастает вдвое-втрое, если добавить обмен с учётной системой: как раскладывается более крупный бюджет, разобрано в статье про стоимость внедрения CRM.

графикpereezd-s-tablits-na-crm--03
График накопленной экономии 31 716 рублей в месяц против разового вложения 285 000 рублей

Двухосевой график за 18 месяцев. Сплошная линия — накопленная экономия по 31 716 ₽ в месяц, штриховая горизонталь — разовое вложение 285 000 ₽. Точка пересечения на девятом месяце подписана «окупаемость, 9 месяцев» и выделена. Слева врезка с базой расчёта: «таблицы стоят 92 575 ₽/мес, снимается 55 %, лицензии и поддержка 19 200 ₽/мес». Оси: месяцы и рубли. Чертёжный стиль, подписи по-русски.

Точка окупаемости — девятый месяц, и только при подключённых источниках заявок

Критерий успеха на тридцатый день

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

  • 90 % сделок с заполненными обязательными полями. Меньше — значит поля выбраны неправильно или их слишком много. Лечится не выговором, а сокращением списка: семь обязательных полей заполняются, двенадцать — нет.
  • 80 % заявок попали в систему без ручного ввода. Это проверка не дисциплины, а того, что источники подключены: форма сайта, общий ящик, телефония. Если цифра ниже, менеджеры вводят данные руками, и через месяц перестанут.
  • 70 % открытых сделок двигались за последние 7 дней. Показывает, ведут систему или заполняют её задним числом. Застывшая воронка на тридцатый день — самый ранний признак, что отдел вернулся в таблицу.
  • Ноль сделок, заведённых после даты отключения таблицы. Проверяется одним отчётом: сравнить дату создания сделки с датой первого обращения клиента. Разрыв больше суток по нескольким сделкам подряд — прямое доказательство параллельного контура.

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

Когда переезжать не надо

Переезд стоит 285 000 ₽ и девять месяцев окупаемости в модели выше. При других вводных арифметика разворачивается, и таблица оказывается честно лучшим инструментом.

  • Один-два менеджера и меньше 40 обращений в месяц. По той же формуле таблицы обходятся примерно в 20 000 ₽ в месяц, из которых снимается около 11 000 ₽ — меньше ежемесячной платы за лицензии и поддержку. Переезд здесь не окупается вовсе; работают общий файл в облаке, единый формат телефона и правило «заявка вносится в день обращения».
  • Продажа в одно касание. Розница, где клиент пришёл, купил и ушёл, воронки не имеет: этапов нет, вести нечего. Нужна касса и учёт, а не CRM.
  • Процесс меняется каждый месяц. Молодая компания, которая ещё нащупывает, кому и как продаёт, зафиксирует в воронке случайную гипотезу и будет её переделывать. Разумнее подождать три-четыре месяца стабильного процесса — и переехать один раз.
  • Нет человека, который отвечает за систему. Не администратора, а того, кто раз в неделю смотрит на воронку и принимает решения по ней. Без такого человека система через квартал превращается в архив, и все возвращаются в таблицу — только теперь ещё и с абонентской платой.

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

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