CRM уже есть, а заявки всё равно теряются: что проверить первым

• CRM

К вопросам по статье

Клиент отправил форму, CRM создала карточку, но менеджер так и не связался с человеком. Или карточки нет вовсе, хотя сайт показал «Спасибо». Это разные неисправности. Чтобы выбрать исправление, пройдите путь одной контрольной заявки от отправки до действия сотрудника.

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

Проверьте шесть переходов одной заявки

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

Пример проверки: Маткласс

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

Подготовьте контрольное обращение

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

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

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

Карточки нет — проверьте передачу

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

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

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

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

Как разобрать одну отправку по следам

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

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

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

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

Карточка есть — проверьте ответственного и доступ

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

В Битрикс24 права на элементы CRM и действия с ними настраиваются по ролям. Поэтому проверяйте необходимый доступ, а не выдавайте всем права администратора как универсальное исправление. Конкретные настройки сверяйте с текущим порталом и официальной документацией.

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

Менеджер видит заявку — найдите следующее действие

Стадия «В работе» не показывает, что произойдёт с клиентом. Проверьте, есть ли конкретное дело, исполнитель и срок: уточнить потребность, подготовить предложение или вернуться после согласования. У ожидания тоже должна быть причина.

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

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

Отделите новую потребность от технического повтора

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

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

Примите исправление на нескольких ситуациях

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

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

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

После проверки наблюдайте за обработкой

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

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

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

Какие исправления могут спрятать проблему

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

Объединение по телефону без разбора потребности. Новая заявка рискует оказаться незаметным обновлением старой закрытой сделки. Сравните две ситуации: повтор того же запроса и новая задача постоянного клиента. В обоих случаях история должна помогать менеджеру продолжить работу, но результат обработки может различаться.

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

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