Правило выбора в одну строку
С базой работает один человек, сделка короткая, следующий шаг помнится сам — таблица. Сделки ведут несколько людей одновременно, между касаниями проходит время и нужна история — CRM. Число строк в этом правиле не участвует: таблица на десять тысяч записей работает нормально, а таблица на сорок записей, в которую пишут четверо, ломается за неделю.
Граница проходит не по объёму, а по двум вещам: сколько людей меняют данные одновременно и нужно ли помнить, что произошло раньше.
Что именно различается
| Признак | Таблица | CRM |
|---|---|---|
| Порог входа | Открыл и работаешь, обучение не требуется | Настройка этапов, полей и прав, обучение сотрудников |
| Поведение при нескольких одновременных пользователях | Правки затирают друг друга, версии расходятся | Разграничение доступа, изменения не конфликтуют |
| История изменений | Не ведётся или ведётся вручную и выборочно | Записывается автоматически по каждой карточке |
| Следующий шаг по сделке | Держится в голове или во внешнем календаре | Привязан к сделке и не теряется при передаче другому |
| Что ломается чаще всего | Ручной ввод: дубли, разные форматы, сортировка одного столбца без остальных | Поля и этапы, настроенные под старый процесс и не пересмотренные |
| Связь с источниками обращений | Копирование руками из почты, форм и мессенджеров | Приём заявок автоматически, метка источника сохраняется |
| Что можно посчитать | Итоги по столбцам на текущий момент | Переходы между этапами, длительность цикла, срез по человеку и источнику |
| Стоимость выхода | Файл всегда у вас, формат читается чем угодно | Выгрузка возможна, но связи между объектами при переносе часто теряются |
Строка про историю изменений — самая недооценённая. Таблица хранит состояние, а не путь: в столбце «этап» стоит текущее значение, и вчерашнее уже нельзя восстановить. Из-за этого в таблице невозможно посчитать конверсию по этапам — не потому, что не хватает формул, а потому, что данных о переходах физически нет.
Строка про сортировку выглядит мелочью, но это самый частый способ потерять базу: столбец отсортирован без остальных, строки разъехались, и связь между именем и телефоном разорвана без единого сообщения об ошибке.
Что на самом деле выбирается
Выбирается не программа, а способ хранения памяти о клиенте.
Таблица предполагает, что память находится в голове того, кто её ведёт. Строка напоминает о клиенте, но не говорит, о чём с ним договорились, кто последний писал и что обещали. Пока человек один и держит контекст, это работает — и работает быстро, потому что ничего не надо заполнять.
CRM переносит память в систему. Каждое касание записывается, каждая сделка имеет владельца и срок следующего действия. Плата за это — обязанность вносить данные. Система не знает того, что не введено, и первое время это ощущается как лишняя работа: раньше договорённость просто помнилась, теперь её надо записать.
Отсюда неочевидное следствие, объясняющее большинство неудачных внедрений. Переход даёт эффект не тогда, когда программа установлена, а тогда, когда команда согласилась вносить данные одинаково. Расхождение в определениях — что считать лидом, в какой момент сделка переходит на следующий этап — превращает историю в набор несопоставимых записей. Разграничение между обращением и квалифицированным контактом разбирает материал про MQL и SQL.
Когда ответ меняется
Людей стало больше одного. Это самый жёсткий порог. Два человека, одновременно редактирующие одну таблицу, рано или поздно затрут правки друг друга, и заметят это не сразу. Никакой дисциплиной проблема не решается: она структурная, потому что в таблице нет владельца строки.
Между касаниями проходит время. Короткая сделка помещается в память. Сделка, где после первого разговора надо вернуться через несколько дней, требует напоминания, привязанного к записи. Внешний календарь эту роль выполняет плохо: при передаче клиента другому человеку напоминание остаётся у прежнего.
Обращения приходят из нескольких мест. Форма на сайте, почта, мессенджеры, звонки. Пока источник один, ручной перенос терпим. При нескольких он становится основной работой и главным источником потерь: часть обращений просто не доезжает до базы. Здесь помогает автоматический приём заявок вместе с разметкой ссылок и коллтрекингом, иначе источник теряется на первом же шаге.
Нужно понять, где останавливаются сделки. Вопрос «на каком этапе мы теряем» без истории переходов не имеет ответа. Здесь таблица упирается не в удобство, а в отсутствие данных: чтобы построить воронку продаж с длительностью этапов, нужны записи о том, когда сделка меняла состояние.
Продажи повторные, а не разовые. Если один клиент покупает много раз, ценность базы растёт, и появляются задачи, которых у разовых продаж нет: сегментация, работа с оттоком, повторные продажи. Таблица здесь ломается не на ведении сделок, а на том, что историю покупок по клиенту неудобно связать со сделками.
Ложная развилка
Противопоставление «CRM или таблица» скрывает три вопроса, которые решаются независимо от выбора инструмента.
Первый — учёт источников. Откуда пришёл клиент, определяется разметкой ссылок и настройкой приёма заявок, а не тем, где эти заявки лежат. Компания с CRM и без разметки знает о происхождении обращений не больше, чем компания с таблицей и аккуратной моделью атрибуции.
Второй — договорённость об этапах. Список стадий сделки и правила перехода между ними — это описание процесса, а не настройка программы. Его можно составить и вести в таблице, и тогда переход в систему становится техническим шагом. Без него настройка воспроизводит беспорядок и делает его обязательным к заполнению.
Третий — отчётность. Дашборд собирается из данных, а не из системы. Если данные полные, отчёт получится и по выгрузке; если неполные, встроенные отчёты покажут аккуратные графики по неверным цифрам, и это опаснее отсутствия отчёта.
Настоящая развилка звучит так: готовы ли вы фиксировать процесс. Если да, инструмент выбирается по числу участников и длине сделки. Если нет, переход на CRM даст интерфейс поверх прежней неразберихи, а таблица хотя бы не создаёт иллюзии порядка.
Клиенты теряются между касаниями. Следующий шаг не привязан к записи и живёт в памяти или в чужом календаре. Заведите обязательное поле со сроком и содержанием следующего действия — сделка без него считается непринятой в работу, независимо от того, где вы её ведёте.
Два человека называют одно и то же разными словами. Нет общих определений этапов и статусов, каждый вносит по-своему. Согласуйте список стадий и правила перехода на бумаге до настройки системы, иначе выгрузка не сложится ни в какой отчёт.
Отчёт по конверсии не получается собрать. Хранится только текущее состояние сделки, история переходов не пишется. Это признак, что таблица уже мешает: без записей о смене этапов конверсия по шагам не считается никаким способом.
Система внедрена, а менеджеры работают в переписке. Заполнение карточек ощущается как работа без отдачи: данные вносятся, но никто их не использует. Свяжите обязательные поля с реальным отчётом, который смотрят на планёрке, и уберите те, которые не участвуют ни в одном решении.
Как проверить, что граница пройдена
Три проверки на имеющихся данных, без обсуждения того, кому что удобнее.
Проверка на одновременность. Посчитайте, сколько человек за неделю вносили изменения в базу. Больше одного — таблица уже работает на честном слове, и вопрос только в том, когда первая потеря станет заметной.
Проверка на память. Возьмите пять сделок, по которым не было касаний последнюю неделю, и попробуйте по записи восстановить, о чём договорились и что должно произойти дальше. Если для ответа нужно поднять переписку, память хранится не в базе.
Проверка на вопрос руководителя. Спросите, сколько сделок сейчас находится на этапе согласования и сколько времени они там в среднем. Если ответ требует ручного пересчёта или его нет вообще, данных для управления процессом не существует — и это независимо от того, сколько строк в файле.
Отдельно стоит проверить экономику: стоимость привлечения и пожизненную ценность считать по таблице можно, но только если в ней сохраняются источник и история покупок. Как только эти два поля начинают заполняться от случая к случаю, любые расчёты по базе становятся оценочными.
Спорное место
Совет «сначала опишите процесс, потом внедряйте» я считаю правильным и одновременно почти невыполнимым в том виде, в каком его обычно дают.
Проблема в том, что процесс до внедрения известен приблизительно. Люди описывают, как они работают, а не как работают на самом деле: этапы, о которых договорились на встрече, не совпадают с последовательностью действий, которая сложилась стихийно. Расхождение обнаруживается только после того, как записи начинают накапливаться, — то есть уже внутри системы. Получается, что требование описать процесс заранее выполняется наполовину, и вторая половина всё равно достраивается по ходу.
Второе сомнение касается противоположного лагеря. Аргумент «таблицы достаточно» опирается на текущую нагрузку и плохо предсказывает момент отказа. Переход обычно происходит не планово, а после потери — когда обнаруживается, что заявка не обработана или база разъехалась после сортировки. К этому моменту накопленная история уже неполная, и перенести в новую систему нечего, кроме списка контактов.
Практический вывод, в котором я уверен наполовину: заводить дисциплину записи имеет смысл раньше, чем инструмент. Единое определение этапов, обязательный следующий шаг и сохранение источника обращения работают в любом файле и переносятся куда угодно. Инструмент без этих трёх вещей меняет только интерфейс — что подтверждается тем, как часто автоматизация настраивается поверх процесса, которого никто не формулировал.
Частые вопросы
Со скольких клиентов нужна CRM?
Можно ли построить воронку в таблице?
Что чаще всего ломается при переходе на CRM?
Обязательно ли отказываться от таблиц после внедрения?
Помогает ли CRM увеличить продажи сама по себе?