Как вести единую базу клиентов в учетной системе

Когда у компании большая клиентская база, качество данных падает, а дублей становится все больше.

ФИО, адреса, телефоны и паспорта содержат ошибки и опечатки («мск сухонска 11/-89» — Почта России не захочет доставлять по такому адресу). Бывает, что данные неполные («тел 7165219» — это в каком городе?). Проблемных данных много — обычно от 20% до 60% базы.

Одних и тех же людей сотрудники заводят в базу два, три, четыре раза. Так появляются дубликаты. Компания внедряет новые информационные системы (автоматизация продаж, бэк-офисы, CRM, портал, личный кабинет) — и количество дублей возрастает. Один и тот же клиент есть на портале, в колл-центре и учетной системе, только контакты везде разные. Компания подключает дилеров — и дублей становится на порядок больше: дилеров качество данных волнует мало.

Карточка клиента в учетных системах

Чтобы получить лояльного клиента, который приносит максимум прибыли, компания хочет собрать о нем полную информацию. Без ошибок и противоречий. Для этого она использует систему data quality — например, «Фактор» от HFLabs. «Фактор» исправляет ошибки и опечатки, восстанавливает недостающую информацию. Проставляет коды качества, чтобы отличить 100% корректные данные от «сомнительных», которые проверяет человек. Ищет дубли по 30 сценариям с учетом похожести (ФИО, дата рождения, ИНН, адрес, телефон, паспорт — в различных сочетаниях).

Когда «Фактор» исправил контактные данные и нашел дубликаты, компания хочет построить «золотые» клиентские карточки и собрать эталонную базу клиентов. Но как это сделать?

«Единый клиент» vs учетная система

Первый вариант — взять специализированное решение: «Единый клиент» от HFLabs. Он сам работает с «Фактором», снимает головную боль по объединению дубликатов, решает конфликты при обновлении данных и помогает не плодить новые дубли в учетных системах. Умеет найти всех похожих людей в 100-миллионной базе за 4 часа и интегрируется с внешними системами через дюжину интерфейсов. Что можно сделать без участия сотрудника — делает сам. Спорные случаи отдает человеку, но помогает принять решение быстро. Прощает ошибки в работе с данными и помогает их исправить. Учитывает типичные проблемы, c которыми сталкивались заказчики «Единого клиента» (крупнейшие банки, страховые и телеком-компании в России).

200 млн клиентов у заказчиков «Единого клиента»

Второй вариант — собрать единую базу прямо в CRM или учетной системе. Добавить полей, интегрировать с «Фактором», научиться объединять дубли. Нанять побольше дата-стюардов. Доработать программные интерфейсы. Купить сервера помощнее и консалтинг от вендора, чтобы «разогнал» СУБД. Нарастить штат ИТ, чтобы поддерживать в работоспособном состоянии. Лечить «детские болезни» самописного решения. Но зато полностью управлять развитием системы.

Если компания выбирает второй вариант, хорошо бы «на берегу» представлять вопросы, которые придется решить. Вот они.

Работать с data quality

В системе автоматизации продаж адрес хранится в 5 отдельных полях — регион, город, улица, дом, квартира. Но иногда сотрудники пишут его целиком в одно из полей.

• В CRM адрес раскладывают по 8 полям.
• В личном кабинете 3 поля, но люди всегда пишут одной строкой.

Это многообразие надо аккуратно собрать, обработать через «Фактор» и сложить в эталонную базу. Состав полей в базе придется расширить, чтобы разложить адрес гранулярно: для Почты России нужен в одном формате, для налоговой — в другом, для скоринга — в третьем.

Неплохо еще сохранить исходные контактные данные, как были до обработки через «Фактор». Они понадобятся, чтобы проверять спорные случаи, привязать данные к первичным документам (анкетам, которые заполнил клиент) и устроить «разбор полетов» с клиентом, если что-то пойдет не так.

Адрес после обработки «Фактором»

Автоматически исправить все данные не получится: есть «серая зона» — контакты, которые «Фактор» отметил специальными кодами качества. Такие случаи сотрудникам придется отсматривать вручную. Значит, надо научить учетную систему фильтровать карточки по кодам качества и показывать пользователю («показать только VIP-клиентов без квартиры»). А еще находить за секунду клиента по слабым критериям (местный номер телефона без кода города + название улицы). Работать должно быстро, а набор и порядок критериев меняется от запроса к запросу. Поэтому индексами в БД не обойтись.

Искать дубликаты

Периодически клиентскую базу надо прогонять через «Фактор», чтобы найти дубли. Это еще одна интеграция — собрать клиентов из единой базы, выгрузить в «Фактор», дождаться результатов, загрузить обратно. Бывает, что «Фактор» отработал за полчаса, а выгрузка и загрузка в учетную систему идут неделю. Бизнес это вряд ли устроит, поэтому лучше сразу продумать, за счет чего учетная система сможет выгружать и загружать данные быстро.

Не все дубликаты стопроцентные, встречаются спорные случаи («Фактор» отдает коэффициент похожести от 0 до 100). Их сотрудники выверяют вручную. Следовательно, придется доработать пользовательский интерфейс в учетной системе. Чтобы дата-стюарды работали эффективно, учетная система должна им помогать:

• показывать группу дубликатов вместо отдельных пар (у клиента 5 дублей, это 8 пар. Принять решение по группе в целом человеку проще, чем по каждой из 8 пар в отдельности);
• подсвечивать отличия между похожими клиентами, чтобы дата-стюард не ломал голову;
• автоматически подтверждать непросмотренные дубли, как только человек дал достаточно информации (трех пар из восьми бывает достаточно).

«Как ежедневно проверять дубли по базе?»

Искать дубли по всей базе клиентов — долго. Хочется каждый день выбирать только тех клиентов, у которых поменялись контактные данные, и искать дубли между ними и с остальной базой. «Фактор» это умеет.

Учетной системе со своей стороны придется научиться выгружать суточный инкремент и обрабатывать результаты от «Фактора» — создавать новые дубли, актуализировать существующие, удалять неактуальные.

Объединять дубли и строить «золотую» карточку

«Фактор» нашел дубликаты. 5 миллионов пар клиентских карточек. Теперь из них надо построить «золотые». Вручную объединять — задача на следующие 50 лет, поэтому сделаем автоматически. Пройдем по всем парам и выберем лучшие — они и будут «золотые»:

Дубликаты? Ну удалим лишние

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

Иногда случаются конфликты:

• два домашних телефона: один с хорошим кодом качества, а второй сомнительный, но отмечен как основной в колл-центре. Что выбрать?
• два паспорта: 4503 629427 и 4603 629427, какой правильный?
• из колл-центра пришло ФИО «Игорь Демьяненко», а из бухгалтерии — «Демьяненко А И». Что делать?

Чтобы карточка получилась действительно «золотой», придется учитывать источник данных, дату актуальности, код качества, заполненность отдельных полей и взаимосвязи между атрибутами. И не забыть проверить, чтобы у эталонного клиента не получилось 3 адреса прописки и 5 одинаковых телефонов.

«Как обработать все дубликаты силами двух дата-стюардов?»

Не-100% дубли дата-стюарды объединяют вручную в учетной системе. Плохо, если человеку все придется делать самому. Хорошо, если система ему поможет: покажет прогноз золотой карточки и даст возможность исправить результат, если что-то не так.

Технический нюанс: когда слияние реализуют «в лоб», в учетной системе оно работает со скоростью 1–5 пар дублей в секунду. 5 миллионов пар — 57 дней. Не 50 лет, но тоже не слишком обнадеживает. Чтобы заставить слияние работать быстро, продумайте, как оно будет реализовано в учетной системе.

Ежедневно принимать изменения

Собрать эталонную базу — это только начало. Каждый день у компании появляются новые клиенты, а у старых меняются адреса, телефоны, паспортные данные, ФИО и даже иногда пол. Получается, учетная система должна уметь «пробросить» изменения на эталонную карточку. На первый взгляд, это несложно:

Последствия обновления «в лоб»

На «золотую» карточку пришло обновление с неполным адресом и «кривым» телефоном. И затерло информацию в золотой карточке. Чтобы этого не произошло, при обновлении учетная система должна по-умному разрешать конфликты: понимать, какие атрибуты от пришедшего обновления пропустить в золотую карточку, а какие — проигнорировать. Чем больше факторов учтем, тем лучше: дата обновления, «авторитетность» источника, код качества, полнота данных и наличие ручных правок.

Иногда изменение приходит на закрытую карточку (которую с кем-то объединили). Если не предусмотреть такой сценарий заранее, изменения потеряются. Правильно — найти эталонную карточку и применить изменения к ней. С разрешением конфликтов, конечно.

Изменения надо передавать во внешние системы: BI, CRM, личный кабинет. Потребности разные — кто-то хочет получать изменения в реальном времени, а кого-то устроят только ежедневные выгрузки через базу данных. Учетная система должна предоставлять программные интерфейсы для потребителей: на уровне БД, через SOAP / REST, очереди сообщений.

Отсекать дубли у новых клиентов

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

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

Хорошо, когда фронтенд-система может спросить у эталонной базы: «а есть уже у нас Игорь Кузнецов, живет в Москве на Снежной улице, дом 12?». И не создавать дубль, если в единой базе клиент уже заведен. Чтобы не прерывать бизнес-процесс, отрабатывать такой сервис должен за секунду.

Исправлять ошибки, не начиная жизнь с чистого листа

Чем больше у компании клиентов и сложнее ИТ-инфраструктура — тем выше вероятность однажды напортачить в данных:

• из-за дефекта в интеграции созданные за последние сутки клиенты пришли с датой рождения 1 января 1970 года;
• люди звонят и жалуются, что в СМС-рассылке чужие ФИО и даты рождения. Разобрались, обнаружили, что три месяца назад ошибочно объединили 20 тысяч клиентов;
• разработчик случайно подключился к промышленному стенду и удалил 100 000 клиентов. Заметили спустя полгода.

«Поднять базу из прошлогоднего бэкапа? Не вариант»

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

Извлекать знания и больше продавать

• Идентифицировать домохозяйства для кросс-продаж и апселла;
• находить дубликаты с учетом взаимосвязей между физлицами, продуктами и организациями;
• проверять потенциальных клиентов по «черным спискам».

Многое из этого умеет делать «Фактор». Но чтобы заработало с единой клиентской базой — нужна поддержка в учетной системе.

Выгоды vs затраты

Хорошая единая клиентская база — сложная штука:

• дает бизнесу новые знания о клиенте,
• работает с минимальным участием дата-стюардов,
• быстро адаптируется под бизнес-процессы,
• не тормозит на десятках миллионах карточек,
• прощает ошибки и помогает их исправить.

Поэтому «Единый клиент» стоит недешево. Добавлять в учетную систему или CRM несвойственные ей функции может оказаться еще дороже.

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