В этой статье
Представьте ситуацию: руководитель хочет понять, почему у одного менеджера конверсия выше, а повторных заказов меньше. Он открывает сделки в amoCRM и замечает: один сотрудник создаёт новую карточку на каждую покупку, другой несколько месяцев ведёт заказы постоянного клиента в одной сделке. Сравнение уже зависит от разных правил учёта.
Качество данных — это возможность уверенно ответить на рабочий вопрос. Заполненные поля и аккуратные названия помогают, но сначала нужно понять, что именно обозначают записи и события. Проверка до построения аналитики позволяет найти ограничения, которые красивый отчёт только скроет.
Начните с решения, для которого нужны цифры
Проверять всю amoCRM сразу трудно и часто бессмысленно. Для оценки скорости первого ответа нужны одни данные, для повторных продаж — другие, для планирования загрузки менеджеров — третьи. Начните с конкретного решения: какую проблему руководитель собирается обнаруживать и что будет делать после получения результата.
Допустим, нужно сравнить работу с новыми запросами по одному направлению. Сначала описываем выборку: какие обращения учитываются, когда начинается период и что означает успешный результат. Отдельно решаем, как показывать незавершённые сделки и повторные покупки. Эти договорённости станут основанием для проверки.
Для конверсии можно выбрать сделки, созданные за согласованный период, и на определённую дату оценивать, какая часть этой же группы завершена успешно. Открытые сделки тогда показывают отдельно. Это один из вариантов расчёта, который нужно соотнести с задачей и выбранным отчётом. Деление всех закрытых продаж месяца на все созданные в нём сделки может смешать разные группы при длинном цикле.
В разных отчётах amoCRM есть свои фильтры и правила отбора. Поэтому перед поиском ошибки фиксируют сам отчёт, период, воронку, ответственного, статусы и вид даты. Два числа с похожими подписями могут описывать разные события. Сверка начинается с одинаковых условий.
Проверьте, что считается одной сделкой и одним клиентом
В amoCRM сделки связаны с контактами и компаниями. Такая структура позволяет отделить конкретную продажу от отношений с клиентом. Но качество разделения зависит от правил, по которым сотрудники и интеграции создают записи.
В нашем примере самостоятельный заказ должен иметь собственную сделку, а новый звонок по этому заказу — продолжать существующую историю. Для повторной покупки используют связь с уже известным клиентом. Проверять полезно обе ошибки: лишние сделки по одному запросу и несколько самостоятельных покупок, спрятанных в одной карточке.
Начать можно с нескольких типичных историй: новый клиент, повторный заказ, обращение через другой канал и заказ организации с несколькими контактными лицами. По каждой истории восстановите связь между запросом, сделкой, человеком и компанией. Если команда не может однозначно объяснить эту связь, число сделок ещё нельзя уверенно трактовать как число возможностей продажи.
Совпадение телефона или почты помогает искать похожие записи, но не доказывает, что все связанные сделки нужно объединить. У компании бывает общий номер, а у одного человека — несколько отдельных покупок. Перед объединением определяют, какие записи описывают один объект, какие сведения сохраняют и как это повлияет на историю и отчёты.
Убедитесь, что этапы и даты обозначают реальные события
Одинаковое название этапа не гарантирует одинакового понимания. Один менеджер считает предложение согласованным после устного разговора, другой — после письменного подтверждения. Если эти сделки попадают в одну группу, отчёт объединяет разные степени готовности клиента.
Для значимых этапов нужно записать условие перехода и доступное подтверждение. Затем открыть реальные карточки выбранной выборки: есть ли договорённость, сообщение или иной результат, который объясняет статус? Для проверки на тестовых карточках можно заранее подготовить такие подтверждения и пройти сценарий с участниками процесса.
Даты тоже требуют смысла. Создание карточки, поступление обращения, отправка предложения и изменение этапа могут происходить в разное время. Если менеджер внёс утром вчерашние запросы, дата создания записи не равна времени обращения клиента. Для оценки скорости ответа понадобятся согласованные события начала и конца, часовой пояс и правило учёта нерабочего времени.
Бюджет сделки следует понимать в принятом компанией значении. Плановая сумма, подтверждённая сумма заказа и поступившая оплата — разные показатели. Если данные об оплатах приходят из учётной системы, необходимо знать, какое значение и на какой момент передаётся. Название поля «Сумма» не превращает его автоматически в показатель выручки или прибыли.
Посмотрите, что скрывается за заполненными полями
Поле может быть заполнено и при этом не помогать анализу. В причинах отказа везде стоит «Другое», в источнике — название формы вместо рекламного канала, в сроке — условная дата, которую вводят ради перехода дальше. Проверять нужно соответствие значения вопросу, на который оно должно отвечать.
В amoCRM дополнительные поля бывают разных типов, в том числе текст, число, дата и список. Для устойчивой классификации часто удобнее согласованный набор значений. Свободный текст полезен для пояснений, но одинаковые категории, написанные разными словами, потребуют дополнительной обработки. Тип и обязательность поля выбирают с учётом момента, когда сотрудник действительно получает сведения.
| Проверка | Почему это важно | Что разбирать |
|---|---|---|
| Пустое или неизвестное значение | Показывает предел доступной информации | Отсутствие данных, неподходящий момент заполнения, ошибка передачи |
| Формально заполненное поле | Может создавать ложную уверенность | Заглушки, одинаковые ответы, значения без подтверждения |
| Разный формат одного признака | Мешает объединить записи для сравнения | Варианты названий, единицы измерения, даты |
| Противоречие между полями | Делает вывод неоднозначным | Статус заказа, сумма, дата и подтверждающее событие |
Неизвестный источник лучше оставить явно неизвестным, чем восстановить его предположением. Если достоверные сведения удалось найти в журнале или другой системе, сохраняют основание исправления. Для исторических данных полезно различать первоначальное значение и результат последующей проверки.
Проверьте ответственность, задачи и доступ к данным
Карточка с заполненными полями может оставаться без движения, потому что следующий шаг не получил исполнителя. В amoCRM задача имеет отдельного ответственного и срок. Поэтому аудит активной работы должен учитывать не только владельца сделки, но и актуальные обязательства перед клиентом.
Просроченная задача требует объяснения: действие не выполнено, срок потерял актуальность или сотрудник сделал работу, но не сохранил результат? Массовое закрытие просрочек делает список короче, однако не отвечает на этот вопрос. Сначала нужно понять причину и определить, что должно происходить в каждой ситуации.
Обратите внимание на сделки бывших сотрудников, передачи между подразделениями и обращения без понятного следующего шага. По выборке проверьте, кто сейчас должен продолжать работу и достаточно ли ему информации. Это связывает качество данных с возможностью обслужить клиента.
Права на сделки, контакты, компании и задачи настраиваются раздельно. Отсутствие записи в представлении конкретного сотрудника может объясняться доступом. Поэтому результаты проверки сопровождают описанием роли и области видимости. Сравнивать данные администратора с ограниченной выборкой менеджера без учёта этого различия некорректно.
Исправляйте причины и сохраняйте возможность проверить изменения
Результат аудита удобнее оформить как список конкретных расхождений. Для каждого указать пример, влияние на выбранное решение, причину, владельца исправления и проверку результата. Так команда увидит, какие проблемы мешают работе сейчас, а какие можно разобрать позже.
Сначала исправляют правила, которые продолжают создавать ошибочные записи. Это может быть неоднозначная инструкция, неподходящее поле или логика интеграции. Затем согласуют работу с накопленной историей. Иначе очищенные данные быстро вернутся в прежнее состояние.
Массовые изменения начинают с ограниченной проверяемой выборки. Сохраняют исходные значения и список затронутых записей, смотрят влияние на задачи, связи и отчёты, а затем расширяют обработку. Где однозначного решения нет, оставляют задачу на разбор. Автоматическое заполнение догадками увеличивает уверенность отчёта, но не достоверность.
- У выбранного показателя определены состав выборки, период и событие результата.
- Сделки и клиенты создаются по одинаковым понятным правилам.
- Значимые этапы и даты подтверждаются содержанием карточек.
- Неизвестные значения отделены от проверенных, а классификации согласованы.
- У активных обязательств есть исполнители, сроки и доступ к нужным сведениям.
- Исправления можно проследить, а причины повторного появления ошибок устранены или назначены ответственным.
После проверки отчёт может показать менее удобную картину: часть источников неизвестна, часть сделок требует уточнения, периоды пока несопоставимы. Это полезный результат. Он объясняет, какие решения уже можно принимать и что ещё нужно наладить в учёте.
Для подготовки аналитики SalesLogic помогает разобрать качество данных и процессы amoCRM. Начать стоит с одного управленческого вопроса и нескольких карточек, на которых видно расхождение между ожидаемой работой и тем, что сохранилось в системе.