За несколько лет в CRM накапливается всё сразу: один клиент в трёх карточках, пустое поле «отрасль», одна и та же компания под названиями «ООО „Ромашка“», «Ромашка» и «Romashka Trade». Хочется отдать это модели: пусть найдёт дубли, заполнит пробелы и наведёт порядок.
Модель действительно может помочь. Но если она сразу пишет в рабочую базу, вы получаете не чистую CRM, а CRM, в которой ошибки выглядят аккуратно. Неверно заполненное поле никто не заметит, а неудачное объединение карточек может спрятать чужую сделку.
Рабочая схема разделяет три шага: модель предлагает, правила проверяют, а принимает изменение правило или ответственный человек. Ниже разберём, как устроить это на уже накопленной базе. Как сделать, чтобы новая заявка без потерь попадала в CRM, мы писали в статье о разрывах между формой и CRM. Здесь речь о данных, которые уже лежат в системе.
Что делает модель, что проверяют правила, что решает человек
Модели хорошо даются задачи, где нужно прочитать неструктурированный текст:
- достать название компании и должность из подписи в письме;
- предложить отрасль или категорию клиента по описанию запроса;
- разложить свободный комментарий менеджера по полям;
- найти пары карточек, которые похожи друг на друга.
Всё это предложения. Станет ли предложение данными, решают правила, которые не зависят от модели и каждый раз срабатывают одинаково:
- в какие поля вообще разрешено писать автоматически;
- какие значения допустимы, например категория только из утверждённого списка;
- какие поля обязательны и в каком формате;
- кто или что имеет право менять конкретное поле;
- какие переходы между статусами разрешены.
Там, где правило не даёт однозначного ответа, нужен человек с именем, а не «отдел продаж в целом». Например, руководитель продаж решает спорные объединения клиентов, а администратор CRM отвечает за справочники. Если ответственного нет, спорные случаи копятся, и очередь проверки становится ещё одним местом, где теряется работа.
Предложенное значение хранится отдельно от принятого
Главное решение: предложение модели не записывается в основное поле карточки. Оно хранится рядом и имеет свой статус.
Что хранить рядом с предложением
- само значение;
- источник: письмо, документ или комментарий, из которого оно взято;
- время, когда значение извлечено;
- кто его предложил: модель с конкретной настройкой, правило или сотрудник;
- статус: предложено, принято, отклонено, конфликт;
- кто принял решение и когда.
Так всегда видно, откуда в карточке взялось значение. А ещё можно улучшать извлечение и при этом не менять незаметно для себя правила, по которым запись считается корректной.
Проверенное не перезаписывается
Если значение уже подтверждено, например юридическое название компании сверено с договором, новое предложение модели не должно его заменять. При расхождении сохраните оба значения и отметьте конфликт для разбора. Иначе следующий запуск обогащения тихо отменит работу человека.
Правильный формат ещё не означает правду
Правило проверяет форму, а не факт. Категория может быть из утверждённого списка и при этом не подходить этому клиенту. Правдоподобное название компании пройдёт любую проверку текстового поля, но может относиться к другому юридическому лицу с похожим именем. Если от факта зависит решение (скидка, договор, отчёт), сверьтесь с надёжным источником или передайте вопрос ответственному. Нет подтверждения — значение остаётся неизвестным.
Отсюда два обязательных теста. В первом значение нарушает правило: категории нет в списке или формат неверный. Во втором значение выглядит правильно, но ничем не подтверждено. Ни одно из них не должно стать принятыми данными, но причины отказа разные, и система должна показывать, какая именно.
Найти дубль и объединить карточки — разные решения
Модель умеет находить похожие карточки. Но описывают ли две записи одно и то же, решает бизнес-правило, а не оценка похожести текста.
Почему человек, компания, обращение и сделка — разные объекты, мы разбирали в статье про заявки в CRM. Для чистки накопленной базы этого мало: правила объединения нужно согласовать до того, как автоматика начнёт что-либо сливать.
Вопросы, на которые стоит ответить заранее
- Какие признаки доказывают совпадение для каждого типа записи? Для компании это может быть регистрационный номер, если вы его храните. Для контакта — личный подтверждённый адрес почты, но не общий ящик вроде info@.
- Какие совпадения только создают кандидата на проверку: похожее имя, общий адрес офиса, один домен почты?
- Кто решает, если признаки противоречат друг другу?
- Какие значения полей остаются после объединения и из какой карточки?
- Что происходит со связанными задачами, письмами, ответственным менеджером и открытыми сделками?
Совпадение — одно решение, действие — другое
Правило поиска находит возможные дубли. Что с ними делать, решается отдельно, и последствия у вариантов разные: предупредить менеджера, запретить сохранение, объединить автоматически или оставить обе карточки и поставить пару в очередь на проверку. Для неуверенных совпадений разумен последний вариант: показать признаки рядом и не трогать записи, пока ответственный не решит.
При любом объединении сохраняйте исходные идентификаторы и историю: какие карточки слиты, по какому правилу, кто подтвердил. Тогда решение можно проследить, а при ошибке понять, что именно восстанавливать.
Пример: тот же контакт, два проекта
Пример условный. Менеджер по закупкам у дистрибьютора весной обращается по поставке оборудования, а осенью — по сервисному договору для другого филиала. Контакт один, проекты разные. Если чистка решит, что одинаковые человек и компания означают дубль, вторая сделка растворится в первой, и её никто не будет вести.
Поэтому тестов на объединение нужно как минимум три:
- Один человек пришёл через два канала. Система должна узнать существующий контакт.
- Тот же человек начал действительно новый проект. Новая сделка должна сохраниться.
- Два разных человека с похожими именами, например однофамильцы в одной компании. Их карточки должны остаться раздельными.
Система, которая борется с дублями, сливая реальных клиентов в одного, провалила вторую половину своей задачи.
Как понять, что чистка не делает хуже
Начните с пилота, в котором модель только предлагает, а записывает человек или правило. Так видно качество предложений до того, как они попадут в рабочие данные.
Главная метрика на этом этапе — доля ошибочно принятых изменений: сколько принятых значений и объединений позже оказались неверными. Чтобы её посчитать:
- регулярно берите выборку принятых решений и просите ответственного проверить их заново;
- при каждом исправлении записывайте причину: неверный источник, неудачное правило, ошибка при ручной проверке;
- считайте поля и объединения отдельно, потому что неверная отрасль и ошибочно слитые клиенты обходятся по-разному;
- следите за очередью на проверку: сколько в ней пунктов и как долго они ждут.
Не оценивайте чистку по числу удалённых дублей: такая метрика поощряет лишние объединения. Какой уровень ошибок допустим и когда можно разрешить автоматическое принятие для отдельного типа изменений, владелец процесса решает до пилота, а не по его итогам.
Чек-лист перед автоматической записью
- Для каждого поля известно, можно ли писать в него автоматически.
- Предложения модели хранятся отдельно от принятых значений, вместе с источником и временем.
- Подтверждённые значения защищены от перезаписи, конфликты сохраняются для разбора.
- Для каждого типа записи описано, какие признаки доказывают совпадение, а какие только создают кандидата.
- Для найденного совпадения выбрано действие: предупреждение, запрет, объединение или проверка.
- Описано, какие значения остаются после объединения и что происходит со связанными задачами и сделками.
- История объединений и исходные идентификаторы сохраняются.
- Пройдены тесты: нарушение правила, неподтверждённое значение, два канала, новый проект, однофамильцы.
- Назначен ответственный за спорные случаи, и понятно, как часто он разбирает очередь.
- Определено, как считается доля ошибочно принятых изменений и какой её уровень допустим.
С чего начать
Выберите один тип записей и одну проблему: например, дубли компаний или пустое поле «отрасль». Опишите правила для этого случая и включите модель в режиме предложений, без записи в рабочую базу. По итогам первого согласованного периода посмотрите, сколько предложений принято, сколько отклонено и сколько пришлось исправить уже после принятия. Расширять автоматику стоит, когда эти цифры понятны.
Если хотите разобрать такие правила для своей CRM, расскажите нам, какая база у вас сейчас и что в ней мешает работе, и мы начнём с одного типа записей.