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

25.10.2026

Начните с конкретного обращения, а не с выбора новой CRM

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

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

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

Что именно вы называете потерянной заявкой

До проверки стоит договориться о значении слова «потеря». Если клиент не купил, это ещё не означает, что его обращение потеряла CRM. Возможно, не подошли условия, потребность исчезла или решение перенесено на следующий период.

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

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

Проверьте, куда на самом деле приходят обращения

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

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

Для расследования нужен след и на стороне сайта. В Tilda есть раздел с поступившими заявками, но срок их хранения зависит от настройки. Отсутствие старой записи в таком журнале нельзя без дополнительных оснований трактовать как доказательство, что человек никогда не отправлял форму. Источник

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

Ответственный должен не только появиться в карточке

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

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

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

Этап сделки должен объяснять состояние клиента

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

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

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

Не добавляйте обязательные поля вместо понятных правил

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

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

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

Как отличить проблему программы от проблемы процесса

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

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

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

Разные продажи могут требовать разных маршрутов

Одна общая воронка удобна только тогда, когда она действительно описывает сопоставимый процесс. Если частный клиент быстро покупает услугу, а организация проходит согласование и подписывает договор на другой объём, одинаковые этапы могут скрывать существенные различия.

В нашем проекте для сети общежитий «Уютный Дом» мы настроили отдельные воронки B2B- и B2C-продаж в amoCRM, автоматизации, Roistat и отслеживание обращений. Это пример того, как CRM связывается с моделью продаж и источниками данных, а не просто заменяет таблицу контактами. Он не доказывает, что каждому бизнесу нужны две воронки или что внедрение CRM само по себе гарантирует рост выручки.

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

Когда достаточно доработки, а когда нужна замена

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

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

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

Как провести первый разбор без большой перестройки

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

Восстановите вход. Когда и где возникло обращение, какой след остался у отправителя и получателя.
Проверьте принятие. Кто получил запрос и чем подтверждается содержательная реакция, а не только назначение в карточке.
Найдите последний согласованный шаг. Что обещали клиенту, что выполнили и какое действие требуется дальше.
Разделите причины. Ошибка передачи, настройка, организация работы, коммерческий отказ или недостаток данных требуют разных решений.
Выберите одно исправление и повторите проверку. Заранее определите, что должно измениться и кто подтвердит результат.

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

Как понять, что CRM стала полезнее

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

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

Договоры и выручку тоже важно наблюдать, но они зависят не только от CRM. Исправленная передача данных подтверждает технический результат; увеличение продаж после нескольких одновременных изменений ещё не устанавливает вклад именно этой доработки.

Частые вопросы

Нужно ли сначала обучить менеджеров или переделать CRM?

Зависит от причины. Если сотрудники не знают работающего порядка, полезны объяснение и практика на реальных ситуациях. Если система требует лишних действий или не отражает процесс, обучение не устранит это неудобство. Сначала разберите конкретную операцию вместе с человеком, который её выполняет.

Можно ли автоматизировать все следующие действия?

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

Как понять, что CRM вообще нужна именно сейчас?

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

Система работает, когда обращение можно довести до следующего шага

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

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

CRM, интеграции и ИИ для бизнеса

Обсудить доработку CRM