Сопоставление результатов массовой проверки номеров с записями в CRM

Чтобы сопоставить результаты массовой проверки телефонных номеров с записями в CRM, назначьте стабильные идентификаторы записей перед подготовкой файла к выгрузке и ведите локальную карту соответствия каждого нормализованного номера исходным записям. Объединяйте экспортированные результаты по проверенному номеру и этой карте, а не по порядковому номеру строки. Проверяйте несовпадающие случаи и связи «многие к одному» до изменения полей в CRM.

→ Узнайте больше о CheckNumber.AI →

Проблема сопоставления начинается еще до загрузки

Экспорт результатов проверки телефонов отвечает на вопрос о переданных номерах; CRM же хранит информацию о людях, организациях, правах доступа и истории взаимодействий. Эти объекты взаимосвязаны, но не представляют собой одну и ту же таблицу. У одной записи в CRM может быть несколько телефонных номеров, а один номер может присутствовать в нескольких записях. Нормализация или дедупликация также могут изменить количество и порядок отправленных строк. Если команда рассчитывает вставить полученные строки поверх исходной выгрузки из CRM, ориентируясь на позицию в таблице, даже корректно выполненная проверка может обновить данные не того контакта.

Создайте стабильный внутренний ключ записи до выполнения любых преобразований. Если в CRM есть постоянный идентификатор записи, экспортируйте его вместе с полями телефонов. Если в исходной системе он отсутствует, присвойте временный ключ в защищенной локальной промежуточной таблице и сохраните исходную выгрузку. Если у записи несколько номеров, добавьте идентификатор конкретного телефонного поля. Промежуточная таблица находится в ведении команды; это не означает, что CheckNumber.AI принимает пользовательские идентификаторы в каждом продукте или возвращает их в определенной схеме.

Построение карты соответствия номеров и записей

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

Подготовьте массив данных в соответствии с актуальными инструкциями по продукту. Задокументированный рабочий процесс обработки списков номеров в CheckNumber.AI использует формат CSV или TXT, по одному номеру с кодом страны на строку, и одну страну на файл. При программной интеграции следует обращаться к документации API, чтобы узнать о текущем поддерживаемом рабочем процессе и действующих лимитах. В этой статье намеренно не предполагается структура тела запроса, имя поля результата или формат ответа, которые не были подтверждены для выбранного инструмента проверки. Связывайте загружаемый файл, локальную карту соответствия, выбранный продукт и дату проверки с единым внутренним идентификатором пакета.

Согласованно нормализуйте ключ объединения

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

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

Применяйте сигналы конкретного продукта с учетом их истинного значения

Различные продукты CheckNumber.AI предоставляют разные сигналы. Проверку валидности телефона, сигнал активности и проверку регистрации на платформе не следует хранить так, будто это единое универсальное булево значение. Фиксируйте, какой именно инструмент проверки сформировал каждый результат, и дату его получения. Специфичный для платформы сигнал регистрации может помочь при планировании каналов связи на момент проверки; он не подтверждает личность, право владения, согласие, будущую доступность или доставку сообщений. Сигнал активности может помочь с расстановкой приоритетов, но не гарантирует ответ.

Прежде чем записывать значения обратно, решите, как CRM будет отображать результат проверки. Команда может использовать внутренний статус, например review needed или checked on date, однако это предлагаемые метки для CRM, а не поля вывода продукта. Не перезаписывайте данные о согласии, подтвержденные предпочтения по контактам или проверенное человеком телефонное поле только потому, что проверка вернула неоднозначный результат. Храните необработанный экспортированный результат отдельно от локальной интерпретации, чтобы последующие специалисты могли видеть, что именно вернул сервис, а какое решение приняла команда.

Согласовывайте исключения и делайте обновления обратимыми

Ведите подсчет количества записей на каждом этапе: исходные телефонные значения, исключенные или неоднозначные значения, уникальные загруженные номера, возвращенные строки, сопоставленные ключи результатов, несопоставленные ключи и записи CRM, предложенные для обновления. Эти показатели будут различаться по объективным причинам. Главное требование заключается в том, чтобы каждое расхождение можно было объяснить задокументированным сопоставлением или решением по результатам проверки. Проверяйте выборки общих номеров, записей с несколькими полями телефонов, разделений по странам и отсутствующих значений.

Перед массовым обновлением CRM сформируйте файл предлагаемых изменений, содержащий идентификатор записи, поле телефона, предыдущий внутренний статус, новый внутренний статус, исходный пакет и решение проверяющего. Обеспечьте защиту исходных данных и соблюдайте политику хранения информации организации. Используйте обратимый процесс обновления, чтобы любую ошибку сопоставления можно было исправить. Команды могут ознакомиться с продуктом Number Checker для получения подходящего сигнала на уровне номера, а затем реализовать сверку с CRM в рамках собственного контролируемого рабочего процесса. Ценность проверки зависит от правильности этой финальной привязки, а не от того, насколько быстро удастся скопировать и вставить строки.

Перед каждым предлагаемым обновлением проверяющий должен убедиться, что исходный идентификатор все еще существует, целевое поле телефона не менялось с момента экспорта, а пакет относится к той же стране и тому же продукту. Если запись в CRM тем временем изменилась, приостановите обновление и перепроверьте сопоставление.

Часто задаваемые вопросы

Как объединить результаты, если строки при загрузке были дедуплицированы?

Ведите карту соответствия каждого уникального нормализованного номера всем идентификаторам исходных записей и полям телефонов. Объедините результат на уровне номера с ключом, а затем сопоставьте его со всеми связанными записями.

Можно ли использовать порядок строк в результатах в качестве ключа CRM?

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

Что делать, если один номер указан у нескольких контактов?

Сохраняйте каждую запись контакта. Один и тот же сигнал на уровне номера может быть связан с несколькими записями, но это не доказывает, что они представляют одного человека.

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

Отложите результат для ручной проверки, сравните исходные и нормализованные номера и проверьте карту пакета. Не обновляйте запись в CRM при наличии сомнений в совпадении.