Почему заявки теряются между отделами и как CRM это останавливает

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

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

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

Передача между отделами должна быть событием в карточке, а не сообщением «перешли на тебя» в мессенджере. В NXR-Engine это смена ответственного, комментарий с контекстом и обязательное поле «что нужно сделать дальше» с датой. Исполнитель не должен звонить продажнику, чтобы узнать адрес и срок — всё уже в карточке. Если поля пустые, передача считается не состоявшейся, и карточка возвращается отправителю. Жёстко на старте, но через две недели качество передач резко растёт.

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

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

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

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

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

Собрать сквозной процесс можно в конструкторе: одна группа «заявки», роли продаж, исполнения и учёта, статусы с явными переходами. Готовые варианты для сервисного бизнеса есть в магазине конфигураций. Если нужна помощь с описанием стыков между отделами — смотрите материалы на странице сопровождения.

Когда заявка живёт в одной системе от первого звонка до гарантийного обращения, между отделами не остаётся «серых зон». Клиент получает цельный опыт, сотрудники меньше тратят время на уточнения, а руководитель перестаёт быть единственным «маршрутизатором» между отделами. Это и есть практическая цель CRM в малой компании — не модная программа, а общая память о каждом клиенте.

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