Ошибки в CRM редко выглядят как большая управленческая катастрофа. Чаще это один спокойный статус в карточке: «написали», «ждем ответа», «не отвечает». В отчетах процесс идет, сотрудник формально выполнил действие, руководитель видит движение. Но на деле контакт может быть потерян, а вместе с ним — кандидат, клиент, срок проекта и деньги.

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

На примере подбора в IT это особенно хорошо видно. Один рекрутер отправил сообщение сильному кандидату и стал ждать ответа. Формально контакт был установлен. Фактически кандидат сообщение не увидел, вакансия продолжила висеть, команда простаивала, а проект сдвинулся по срокам.

Та же логика работает не только в найме. Клиент не ответил на коммерческое предложение. Журналист не увидел комментарий. Партнер пропустил письмо. Если задача закрывается после одного касания, компания может потерять не «сообщение», а сделку, публикацию, кандидата или важный этап проекта.

Кейс: идеальный кандидат был в базе, но компания его упустила

Татьяна Кутепова, HR-эксперт, специалист по подбору руководителей и IT-специалистов, рассказала о кейсе из сферы IT-разработки. В компании два месяца была открыта критически важная вакансия Solution Architect. Для проекта нужен был архитектор решений с редким технологическим стеком. По сложности поиск был близок к executive search.

Рекрутер нашел почти идеального кандидата во внутренней базе, отправил ему сообщение в Telegram и стал ждать. Но не проверил важную деталь: в аккаунте стояла метка «был в сети давно». Дополнительного письма на почту не было, альтернативные мессенджеры и профессиональные площадки тоже не проверили.

Через два месяца кандидат случайно зашел в старый Telegram-аккаунт, увидел сообщение и ответил, что буквально несколько дней назад принял оффер другой компании. Отказываться от принятого предложения он не стал. Для компании контакт выглядел сделанным, но по сути не состоялся.

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

Итого прямые и косвенные потери превысили 2 млн рублей. При этом внешне процесс не выглядел брошенным: вакансия двигалась, кандидатов показывали нанимающему менеджеру каждые три дня, руководитель подбора раз в две недели пересматривал воронку и искал новые гипотезы.

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

Почему статус «написали» опасен

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

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

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

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

О похожей проблеме мы писали в материале «Метод 5 почему: как найти причину повторяющейся ошибки в бизнес-процессе». На поверхности кажется, что сотрудник «забыл» или «не дожал». Но корневая причина часто в том, что сам процесс разрешает такую ошибку.

Один канал связи — это не контакт

В кейсе Кутеповой проблема была не только в статусе, но и в слепой вере в один канал. Сообщение ушло в Telegram, но аккаунт оказался старым. Для рекрутера действие выполнено, для кандидата контакта не было.

После кейса компания внедрила правило валидированных многократных касаний. Суть не в том, чтобы заваливать человека одинаковыми сообщениями. Работает другая формула: проверить, жив ли канал, и сделать 2-3 содержательных касания, каждое из которых дает новый повод ответить.

Для IT-рынка компания выбрала последовательный подход. Сначала письменные каналы: Telegram или WhatsApp с проверкой даты активности, затем Email, затем профильные сервисы и соцсети, например LinkedIn, «Хабр Карьера», GitHub. Телефонный звонок допустим только как крайняя мера, если вакансия критически важна, а кандидат не ответил ни в одном письменном канале.

Это важная оговорка. В разных сферах набор каналов будет отличаться. В продажах звонок может быть нормой. В IT-рекрутинге внезапный звонок иногда воспринимается как нарушение границ и может подставить кандидата перед текущим работодателем. Поэтому правило должно учитывать контекст, а не просто требовать «позвонить всем».

Анастасия Курникова, HR в коммуникационном агентстве PR Partner, говорит, что похожая ошибка встречается и в других коммуникациях. Например, в PR специалист может опустить руки после одного непрочитанного сообщения журналисту. В результате задача формально закрыта, но контакт не состоялся.

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

Что нужно изменить в CRM или ATS

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

На бумаге это выглядело разумно. Но система не различала две разные ситуации: «человек не ответил в одном канале» и «человек действительно не вышел на связь». После ошибки эту логику изменили.

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

Алексей Авдеев, CEO сервиса ИИ-аналитики и автоматизации продаж «Аихаб», предлагает похожую логику для CRM в продажах. Если сотрудник меняет статус на «отказ» или «не отвечает», система должна требовать причину, следующий шаг и проверку альтернативных каналов. Иначе CRM быстро превращается в записную книжку, где статус отражает удобство менеджера, а не реальное состояние сделки.

Авдеев также советует настраивать триггеры эскалации. Если менеджер не сделал повторное касание в установленный SLA и возникает риск потери заявки, система должна показать это руководителю. ИИ может помогать: автоматически фиксировать звонки и переписки, делать саммари, ставить задачи на повторные касания и предлагать текст следующего сообщения. Но ответственность за процесс все равно остается у команды и руководителя.

Кто должен контролировать критические контакты

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

Критические контакты нужно контролировать на нескольких уровнях:

• исполнитель фиксирует все попытки связи, канал, дату, содержание сообщения и следующий шаг;
• руководитель смотрит не только количество карточек в работе, но и возраст статуса, просроченные касания и зависшие контакты;
• HRD, РОП или операционный руководитель подключается к критическим вакансиям, сделкам и клиентам, где задержка влияет на деньги, сроки или репутацию;
• система не дает закрыть задачу одним кликом, если обязательные действия не выполнены.

Здесь помогает не тотальный микроменеджмент, а правильно настроенная видимость. Руководителю не нужно читать каждое сообщение. Ему нужно видеть, какие контакты зависли, сколько дней карточка живет в статусе ожидания, какой канал уже проверен и где нарушен SLA.

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

Где еще бизнес теряет деньги из-за формального статуса

История с кандидатом — только один пример. Формальный статус опасен в любой зоне, где есть важный внешний контакт.

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

Алексей Авдеев приводит пример из автосалона премиум-класса. После внедрения автоматизации и аналитики продаж потеря лидов снизилась на 20%, а конверсия в визит выросла на 18%. Сильные практики менеджеров зашили в чек-листы и использовали для обучения новых сотрудников, а слабые места стали видны не по ощущениям, а по конкретным звонкам, перепискам и статусам.

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

О том, как один формальный пункт может стоить бизнесу денег и сроков, мы уже рассказывали в материале «Проверка ТЗ и договора: как один пункт может стоить бизнесу проекта на 50 млн рублей». Здесь принцип похожий: опасность часто прячется не в большой стратегии, а в маленьком условии, которое никто не проверил.

Что проверить в своей CRM уже сейчас

Чтобы найти риск, не нужно ждать крупной потери. Достаточно открыть CRM или ATS и посмотреть на карточки, которые считаются «в работе».

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

Вывод

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

Кейс Кутеповой хорошо показывает цену маленькой формальности. Одно сообщение в заброшенный Telegram-аккаунт превратилось в полгода задержки и потери больше 2 млн рублей. Но проблема была не в одном рекрутере. Ее допустила система, где «написали» считалось почти тем же самым, что «установили контакт».

Исправление начинается с простого правила: статус должен отражать не внутреннее действие сотрудника, а внешний результат. Не «мы написали», а «человек ответил», «назначен следующий шаг», «проверены все каналы», «контакт действительно не состоялся». Тогда CRM становится не архивом действий, а инструментом управления.