Проведите по системе одно контролируемое обращение: заявка → ответственный → контакт → следующий шаг → результат. На каждом переходе проверьте не только наличие записи, но и то, кто должен действовать дальше. Так можно найти конкретный разрыв и сформулировать задачу специалисту.
Проверка нужна, когда руководитель видит заявки в рекламном кабинете, менеджеры говорят, что всё обработали, а CRM не позволяет восстановить путь клиента. Сразу менять платформу или покупать новые виджеты рано. Сначала стоит выяснить, на каком участке информация перестаёт соответствовать реальной работе.
Ниже — методика первичной диагностики для владельца бизнеса и РОПа. Она помогает собрать факты перед изменениями или профессиональным аудитом. Проверка одного обращения не доказывает исправность всей системы: после неё нужно повторить сценарий для остальных каналов и исключений.
1. Подготовьте контрольный сценарий и доступы
Выберите один важный канал: форму сайта, входящий звонок, письмо или сообщение. Опишите ожидаемый путь простыми словами: «После заявки с формы появляется сделка в воронке новых продаж, назначается дежурный менеджер, сохраняется услуга и источник, создаётся действие на первый контакт».
Для начала достаточно возможности просмотреть карточку, историю изменений и связанные задачи. Понадобится участие человека, который видит исходный канал: форму, журнал звонков или переписку. Не раздавайте права администратора всем участникам проверки. Если нужно проверить автоматизацию или журнал интеграции, попросите ответственного специалиста показать соответствующую запись.
- Заведите тестовый контакт с адресом и телефоном, которые контролируете вы.
- Пометьте обращение как тестовое и предупредите участвующего менеджера.
- До отправки выясните, какие сообщения и действия запускаются автоматически. Используйте тестовую среду либо согласованный сценарий, который не затронет реальных клиентов.
- Записывайте время в одном часовом поясе, ID обращения и ID сделки. Одного имени клиента для сверки недостаточно.
После базового сценария добавьте повторное обращение того же клиента, заявку вне рабочего времени и передачу другому менеджеру. Проверку сбоя интеграции проводите в тестовой среде вместе со специалистом, не отключая рабочий обмен ради эксперимента.
2. Проверьте, дошла ли заявка целиком
Отправьте форму с понятным тестовым комментарием и сохраните время отправки. Затем найдите запись в CRM по телефону или адресу. Сравните не только количество заявок, но и значения: имя, контакт, выбранная услуга, комментарий, страница отправки и рекламные параметры, если они предусмотрены вашей схемой.
Запись могла появиться, но оказаться бесполезной: телефон записан в примечание вместо поля, комментарий обрезан, сделка попала в другую воронку. В таком случае проблема уже локализована — нужно исправить сопоставление данных и повторить проверку.
Если записи нет, последовательно проверьте отправку формы, принятие обращения обработчиком и ответ CRM. Просите показать время, идентификатор и результат обработки конкретного обращения. Сообщение «заявка отправлена» на сайте само по себе не подтверждает, что она появилась в CRM. Не пересылайте в общий чат журналы с паролями, токенами и данными клиентов.
3. Убедитесь, что назначен доступный ответственный
Посмотрите, кто получил обращение и может ли этот человек его открыть. Проверьте, видит ли менеджер контактные данные, переписку и действие, которое от него ожидается. Проверка под администратором не заменяет проверку под рабочей ролью.
Отдельно разберите отпуск, выходной и увольнение сотрудника. Если повторная заявка всегда назначается прежнему ответственному, нужен понятный порядок замещения. Запишите правило и владельца исключения: кто замечает зависшее обращение и кому его передаёт.
В Битрикс24 историю изменений следует читать с учётом прав пользователя: доступная история зависит от доступных ему элементов CRM. Поэтому отсутствие события на экране менеджера ещё не доказывает, что события не было. Это поведение описано в официальной справке Битрикс24.
4. Проверьте контакт и следующий шаг
Откройте карточку после первого ответа клиенту. Должно быть понятно, чем закончился разговор и что произойдёт дальше: подготовить расчёт, согласовать встречу, получить недостающие данные. Запись «позвонить» без цели и срока плохо помогает и менеджеру, и руководителю.
В amoCRM проверьте, к какой сущности относится задача. Задача у контакта или компании может быть видна в контексте сделки, но не учитываться в её индикаторе задач. Поэтому фильтр сделок без задач нужно разбирать вместе с привязкой, а не считать каждую найденную карточку забытым клиентом. Подробности — в инструкции amoCRM по задачам в сделках.
Для закрытых сделок и отдельных сценариев ожидания могут быть свои правила. Например, ожидание подтверждённой даты поставки требует контроля наступления даты, а не ежедневной бессмысленной задачи «проверить». Сначала согласуйте, какое событие возвращает сделку в работу, затем выбирайте автоматизацию.
5. Сверьте результат сделки с исходным событием
Если система должна получать оплату из внешнего сервиса, проверьте согласованный тестовый сценарий: какая запись подтверждает платёж, к какой сделке он относится, что происходит при частичной оплате и возврате. Создавать реальные списания ради проверки не нужно. Сценарии оплаты можно воспроизвести в тестовом окружении или разобрать на разрешённом к просмотру завершённом заказе.
Успешная стадия и полученные деньги — разные признаки, пока команда явно не связала их правилом. Сделка может быть закрыта по факту договора, а оплата поступить позже. В отчёте нужно различать эти события. При отказе проверьте, можно ли по карточке понять причину и условия возвращения к клиенту.
Не считайте разницу между количеством рекламных конверсий и сделок автоматическим доказательством потери лидов. Сначала сопоставьте период, часовой пояс, определение заявки, повторные обращения и правила объединения. Сравнивать нужно одинаковые события.
Таблица для проверки своей CRM
Скопируйте таблицу в рабочий документ и добавьте справа фактический результат, ссылку на доказательство, ответственного и срок исправления. Для каждого канала заведите отдельный проход.
| Участок | Что проверить | Чем подтвердить |
|---|---|---|
| Поступление | Обращение дошло до нужной воронки | Время и ID в источнике и CRM |
| Содержание | Контакт, запрос и источник сохранены в нужных полях | Сравнение отправленных данных с карточкой |
| Назначение | Ответственный работает и имеет доступ | Просмотр под его ролью, правило замещения |
| Первый контакт | Видно время и содержание реального ответа | Запись разговора, письмо или сообщение |
| Продолжение | Указаны действие, срок и ответственный | Задача либо согласованное событие возврата |
| Результат | Стадия соответствует принятому правилу завершения | Заказ, платёж или зафиксированный отказ |
| Исключение | Повторная заявка и отсутствие менеджера обработаны предсказуемо | Повтор сценария с записью результата |
Учебный пример: задача есть, а работа не продолжается
Предположим, тестовая заявка на расчёт поступила через форму. Сделка создана, назначен менеджер, в карточке видна задача. Формально всё выглядит исправно. При проверке выясняется, что задача относится к контакту, её срок прошёл, а другой менеджер не видит сделку и не может подхватить обращение.
Здесь три разных вопроса: привязка следующего действия, контроль просрочки и права замещающего сотрудника. Покупка нового виджета до их разделения может добавить ещё одну задачу, но не исправить передачу клиента. Сначала описываем ожидаемое поведение, затем меняем настройки и повторяем тот же тест.
Это вымышленный пример для объяснения методики, а не клиентский кейс CHECK CRM.
Как должен выглядеть результат проверки
Полезный итог — список воспроизводимых проблем. Для каждой укажите: сценарий, ожидаемое поведение, фактическое поведение, доказательство, влияние на работу, владельца исправления и повторный тест. Формулировка «CRM неудобная» не позволяет проверить результат доработки. Формулировка «повторная заявка назначается сотруднику без доступа; нужен действующий заместитель» позволяет.
В первую очередь разбирайте потерю обращений, недоступные клиентские данные и нарушения передачи ответственности. Затем — неверные данные для решений и лишние ручные действия. Визуальные пожелания тоже можно сохранить, но их очередь определяйте отдельно от ошибок, мешающих работе.
Профессиональный аудит нужен, когда причина скрыта в нескольких интеграциях, изменения затрагивают права и автоматизацию или команда не может согласовать ожидаемый процесс. Чтобы предметно обсудить аудит amoCRM или аудит Битрикс24, подготовьте контрольный сценарий и заполненную таблицу. После исправления причины регулярную проверку можно включить в сопровождение CRM.