В CRM 98% карточек заполнены. В первой же выборке выясняется, что компания «Уточнить позже» купила на 16 миллионов, а менеджер «Администратор» закрывает больше сделок, чем весь отдел вместе. Система очень уверенно хранит то, чего никто на самом деле не знает. Если агенту разрешить читать эти поля как факты, он просто ускорит распространение ошибки.
Аудит качества данных в CRM начинайте с конкретного решения: кому агент может писать, какой статус может выставить и на каком основании построит отчёт. Затем берите стратифицированную выборку карточек, сверяйте значения с первоисточниками и назначайте каждой проблеме действие: исправить источник, проверить конкретные сделки или приостановить автоматизацию. Процент заполненности сам по себе пригодность данных не доказывает.

Как карточка с шестью полями провалила допуск
Условная карточка: организация «Северная логистика», контакт «отдел снабжения», телефон общий, сумма 480 000 рублей, этап «КП отправлено», ответственный «Интеграция». Из шести полей пустых нет. Коммерческое предложение в истории есть, но это черновик: события отправки нет. Сумма пришла из внутреннего прайса без доставки; конечное предложение ещё не согласовано. Общий номер можно использовать для поиска отдела, но он не подтверждает персональный контакт. Идентификатор интеграции описывает автора записи, а не сотрудника, который принял задачу.
Что разрешить? В список на ручную проверку карточку добавить можно. Обещать клиенту 480 000 нельзя. Поменять этап на «отправлено» нельзя. Автоматический отчёт может показать ориентир с отдельным признаком, что сумма не подтверждена; включать её в ожидаемые платежи наравне со счётом — нет. Три разных решения на одной карточке дают три ответа о пригодности. Поэтому единый зелёный значок «данные хорошие» делу не помогает.
Если сейчас выбираете, где разместить агента, на странице Цифры посмотрите связку работы со сделками и агентами. Для своего процесса передайте на обсуждение не весь справочник, а одну карточку с пометками: что агент вправе прочитать, что может подготовить и что ему нельзя менять.
Аудит начинается с проверки последствий, а не с чистки справочников

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

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

Вместо «почистить CRM» заведите журнал дефектов с образцом, условиями появления, владельцем источника, сроком и тестом повторной проверки. Отдельно выделите действия, которые временно надо ограничить. Для цены можно оставить подготовку черновика, отключив отправку. Для статуса — сохранить рекомендацию без записи. Для отчёта — вывесить покрытие подтверждённой суммой. Массовая правка базы без исправления причины даст хороший отчёт ровно до первого нового импорта.
Условно проверили 20 карточек из формы, 20 ручных и 20 импортированных. Для автоматической отправки годятся 18, 16 и 4. Общая цифра 38 из 60 не отвечает, какой маршрут включать. Импортированную группу лучше оставить на ручной проверке, пока не понятен источник контактных данных. По форме проверьте два случая и решите, допускаются ли исключения. Для ручного ввода проверяйте конкретную причину: например, разные значения поля при переводе с черновика на подтверждение. Подборка по три одинаковых по размеру группы удобна для аудита, но не оценивает всю CRM без весов реального потока.
Карточки для приёмки исправлений
Сумма записана без валюты
Из формы приходит 1200. Менеджер ожидал евро, интеграция считает рубли, отчёт показывает аккуратное число.
- Что проверить
- Откройте данные формы и контракт обмена. Если валюта определена в контексте тарифа, этот контекст должен сохраниться рядом с числом.
- Решение
- Остановите расчёт, когда валюта неизвестна. Для известных значений разделите исходную сумму и отчётную конвертацию с датой.
- Ожидаемый результат
- Проверьте две валюты и отсутствие валюты на новом событии. Без валюты автоматический результат не становится ценой.
Комментарий звучит увереннее первоисточника
В заметке стоит «оплачено», а в журнале есть выставленный счёт и не подтверждённая банком операция.
- Что проверить
- Сверьте назначение статуса, источник платежа и время. «Обещал оплатить» и «деньги зачислены» меняют дальнейшие действия.
- Решение
- Покажите заметку сотруднику как контекст, оставив официальный статус по платёжному журналу. Отложите отгрузку, если правило требует зачисления.
- Ожидаемый результат
- Обновление комментария не двигает этап. У подтверждённого платежа видны дата и запись, которая запустила действие.
Новый контакт у старой компании
Сделку перенесли в новый филиал, но телефон из старого контакта остался в карточке. Внешний номер пригоден для дозвона, человек не тот.
- Что проверить
- Сравните источник контакта, привязку к филиалу и историю роли. Наличие ответа на вызов не доказывает принадлежность человеку.
- Решение
- Перепривяжите активное дело после проверки. Старый контакт оставьте в истории; при необходимости уточните допустимый канал.
- Ожидаемый результат
- Проверьте, что новый импорт не откатывает связь. Для следующего исходящего действия берётся контакт нужной роли, а не самый ранний номер.
Назначена учётная запись интеграции
Отчёт показывает владельца «Синхронизация». Все карточки формально назначены и никто не замечает просрочки.
- Что проверить
- Различите автора записи, технического исполнителя и бизнес-владельца. На исходном событии можно сохранить все три роли.
- Решение
- Назначьте бизнес-очередь с правилом принятия. Если адресат недоступен, карточка должна оставаться видимой дежурному.
- Ожидаемый результат
- На новом событии видны человек или очередь, реальный срок и автор интеграции. Отсутствие владельца не маскируется системным именем.
Старый импорт перетирает уточнение
Менеджер подтвердил контакт сегодня, а пакет с прошлой недели пришёл вечером и вернул старый номер.
- Что проверить
- Сравните дату состояния с датой доставки. Уточнение должно иметь собственное время, источник и приоритет.
- Решение
- Разрешите импортировать исторический факт без замены подтверждённого значения. Конфликт отправляйте на проверку только там, где важен текущий контакт.
- Ожидаемый результат
- Доставьте два события в обратном порядке. Текущий контакт не меняется, история сохраняет оба исхода и объясняет принятое правило.
Одна запись, два нежелательных действия
Контрагент уникален, но одно событие из очереди дважды поставило сотруднику задачу на связаться.
- Что проверить
- Проверьте ключ действия и журнал повторов. Уникальный ключ контакта сам по себе не защищает очередь задач.
- Решение
- Привяжите поручение к исходному делу и смыслу действия, а повтор технической доставки учитывайте отдельно.
- Ожидаемый результат
- Доставьте событие дважды, затем добавьте настоящий новый запрос. Первый повтор не создаёт поручение, новый запрос сохраняет право на отдельное действие.
Где проводить границу между автоматическим исправлением и проверкой
Менять пробелы в номере заказа и менять сам номер — не одно действие. Нормализацию символов можно допустить при известном формате, сохранив исходную строку. Подбор другого контрагента потребует проверки, потому что ошибка влияет на письмо, документы и отчётность. Для каждого правила задайте обратимость: может ли сотрудник увидеть прежнее значение и восстановить его без инженера. Если ответ отрицательный, начните с предупреждения вместо массовой записи.
Сформируйте три области допуска. В зелёной значение подтверждено и действие обратимо: например, добавить техническую метку по известному источнику. В жёлтой агент готовит черновик: новый контакт похож на старый, но связь не установлена. В красной действие блокируется: неизвестен правовой статус, версия цены или принадлежность платежа. Цвет годится для интерфейса; в журнале пусть останутся понятные причины. Сотруднику важно не «красный уровень», а «не найден утверждённый документ».
Проверьте, можно ли сузить разрешение до безопасного поднабора. Сопоставление карточек заказов из собственного магазина может быть надёжным, а из старых Excel-таблиц — нет. Можно включить первый маршрут и сохранить проверку для второго. Усреднённая оценка качества заставляет либо открывать слишком многое, либо запрещать полезное там, где риска уже нет.
Как оценить цену дефекта, который пока не проявился
Дефект редко имеет одну универсальную стоимость. Ошибка телефона может стоить минуты сотрудника, если контакт уже есть в переписке, или потерянной сделки, если это единственный канал. У ошибки суммы цена зависит от того, показал ли её отчёт или агент отправил коммерческое предложение. Записывайте последствия на худшем разумном этапе, а не на первом техническом экране.
Представим десять неверных обязательных полей. Восемь — несущественные огрехи формата, два — изменившаяся версия цены. Чистка восьми даст красивый прирост правильных карточек, но ключевой риск останется. В журнале дефектов добавьте «потенциальное действие» и «условие наступления». Так руководитель может выбрать устранение двух проблем раньше восьми остальных, не споря об общем балле.
Отдельно посчитайте цену ручной защиты. Пусть проверка одного документа занимает условные три минуты, а в узком потоке таких документов десять в неделю. Полчаса работы может быть дешевле запуска дорогой автоматизации, пока команда не знает правила обработки исключений. Но если вручную сверяют тысячи одинаковых строк, выгоднее автоматизировать извлечение и оставить решения о спорных документах. Аудит должен дать аргументы для этого выбора, не только перечень ошибок.
Как согласовать владельца поля, когда систем несколько
Поле «дата отгрузки» может появляться в заказе, складе и CRM. Отдел продаж видит обещанную дату, склад — готовность, логистика — фактическую передачу. Попросите каждую команду выписать, о каком событии говорит её поле. Внесите в контракт данные раздельно, а экран, который видит менеджер, подпишите человеческими словами. После этого спор «какая дата истинная» часто исчезает: истинных дат несколько, у каждой другой смысл.
При первичной проверке полезно оформить мини-протокол на одной карточке: что поле называлось раньше, какое значение нашли, кто подтвердил, какой маршрут это значение разблокирует. Назначьте владельца согласования, если нужны изменения за пределами CRM. Сотрудник отдела продаж не должен чинить справочник склада вручную только потому, что его экран первым заметил расхождение.
Через две недели повторите маленькую выборку. Если число конфликтов сократилось, откройте несколько оставшихся. Возможно, одни связаны с редким сценариями, которых не было в требованиях, а другие — с привычным обходом процесса. Новая проверка полезна как проверка конкретной причины, а не как торжественная пересдача по тому же набору вопросов.
Чем отличается аудит от регламента заполнения
У обязательных полей по этапам цель — сделать ожидаемый минимум понятным на текущем шаге. У проверки дублей — определить, что считать отдельным обращением. История изменений нужна для восстановления действий. Аудит соединяет эти части в решение о допуске: пригоден ли конкретный набор карточек для конкретной автоматики.
После исправления прогоните новую выборку. Нельзя снова проверять только карточки, которые команда только что вручную отредактировала. Нужны события, порождённые обновлённым маршрутом. Если в журнале видно, почему действие разрешено, а сам владелец процесса может воспроизвести проверку без автора интеграции, качество базы становится рабочим свойством, а не оценкой на слайде.