Зарегистрируйтесь и обратитесь в поддержку, чтобы получить 100 бесплатных проверок.Зарегистрироваться бесплатно
Иллюстрация процесса CarrierLookup к статье «Определение исходного оператора для CRM: добавление полей исходного оператора и типа линии»
Наглядная схема процесса, рассматриваемого в этой статье CarrierLookup.

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

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

Проектирование полей CRM перед началом определения оператора

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

Метка поля CRM Рекомендуемый тип Примечания
Исходный оператор Однострочный текст Названия операторов различаются в зависимости от страны; фиксированный выпадающий список быстро устаревает
Базовый оператор Однострочный текст Часто остается пустым; заполняется, только если бренд работает в сети другого оператора
Тип номера Выпадающий список Мобильный, фиксированный, VoIP, другое, недоступно
Регион распределения Однострочный текст Регион, привязанный к диапазону номеров
Город распределения Однострочный текст Город, привязанный к диапазону номеров
Статус проверки оператора Выпадающий список Выполнено, выполнено-пусто, Не определено, не проверялось
Дата проверки оператора Дата Дата выполнения проверки

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

Подготовка полей номеров телефонов для проверки

Результат проверки зависит от качества входных данных. Перед первым запуском проверьте, как номера телефонов хранятся в CRM:

  1. Выберите одно исходное поле. У контактов часто есть поля «Телефон», «Мобильный» и текстовое поле «Другое». Решите, какое из них будет использоваться для проверки, или создайте одну запись проверки для каждого поля.
  2. Нормализуйте до E.164. Удалите пробелы и знаки препинания, отбросьте национальные префиксы и добавьте знак «плюс» и код страны, например +447700900123. Формат определен в ITU-T Recommendation E.164.
  3. Сохраняйте нормализованное значение отдельно от исходной записи, чтобы менеджеры по продажам видели то, что ввел контакт.
  4. Удалите дубликаты на уровне номеров, чтобы один номер, общий для нескольких контактов, проверялся один раз и записывался для каждого из них.
  5. Укажите страну для каждого номера на основе его кода страны. Синхронные проверки не требуют этого, но пакетные задачи — да.

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

Новые записи: синхронные проверки внутри рабочего процесса CRM

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

  • Вебхук рабочего процесса или промежуточное ПО. Когда запись создается или поле телефона изменяется, ваш сервер интеграции вызывает POST /api/v1/check для одного номера и записывает результат обратно в поля CRM.
  • Запланированные микропакеты. Каждые несколько минут собирайте новые записи и отправляйте 1–100 номеров в формате E.164 в POST /api/v1/batch-check. Результаты возвращаются в порядке ввода, поэтому сопоставляйте их с записями по позиции или по отправленному номеру.
  • Ручная проверка. Оператор может вставить до 500 номеров в область пакетной проверки на панели управления для быстрой выборочной проверки.

Храните X-API-Key на своем сервере интеграции; никогда не размещайте его в клиентских скриптах CRM или расширениях браузера. Публичный API документирует небольшое количество общих слотов для параллельных запросов и один мультизапрос на аккаунт за раз, поэтому ставьте проверки в очередь, а не запускайте по одной на запись во время крупного импорта.

Существующая база данных: одна пакетная задача на страну

Для обработки накопленной базы экспортируйте нормализованные номера и обрабатывайте их как пакетные задачи вместо тысяч синхронных вызовов.

  1. Группируйте по коду страны. Пакетная задача использует одну выбранную страну, а строки вне ее исключаются, поэтому создавайте один экспорт на страну.
  2. Записывайте по одному номеру в строке в файле TXT или одностолбцовом CSV в виде цифр с кодом страны.
  3. Отправляйте каждый файл через панель управления или с помощью POST /api/v1/bulk-tasks, указывая страну перед файлом в multipart-запросах.
  4. Опрашивайте GET /api/v1/bulk-tasks/{id} не чаще одного раза в 30 секунд.
  5. Загрузите CSV для каждой успешной задачи и импортируйте его в CRM, сопоставляя по идентификатору из цифр с вашим нормализованным полем.

Предварительная обработка удаляет неверные строки, дубликаты и номера без кода страны; за такие исключенные строки плата не взимается. Применяются ограничения на размер списка и файла для каждого продукта, поэтому ознакомьтесь с документацией API, прежде чем решать, как разделить большой экспорт. Страны, номера которых поддерживаются только для синхронных проверок (например, материковый Китай, Гонконг и Макао), должны проходить через синхронный маршрут.

Правильная запись пустых результатов и результатов «Не определено»

Три результата выглядят похоже в таблице, но означают разное в CRM:

Результат Что произошло Что записать
Выполнено со значениями Проверка вернула данные о распределении Заполните поля, статус «выполнено»
Выполнено с пустыми полями Проверка завершена, но некоторые или все значения недоступны Оставьте поля пустыми или запишите «недоступно», статус «выполнено-пусто»
Не определено Проверка вернула ненулевой бизнес-код или истекло время ожидания Оставьте поля без изменений, статус «Не определено», повторите позже

В синхронном мультизапросе строка без нормального результата относится к категории недоступных, а не к списку ошибочных номеров. Никогда не перезаписывайте хорошие ранние значения пустыми данными из более поздней неудачной попытки. За неудачные или неопределенные проверки плата не взимается, поэтому ограниченное количество повторных попыток (например, несколько раз в течение дня) является разумным.

Использование новых полей в сегментах и отчетах

После настройки полей команды CRM обычно создают:

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

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

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

Как часто командам CRM следует повторно запускать проверку оператора для существующих записей?

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

Должна ли CRM перезаписывать исходного оператора, если контакт сообщает о смене сети?

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

Как команды могут подключить ИИ-ассистента к тем же данным проверки?

Официальный MCP-эндпоинт позволяет ИИ-ассистенту выполнять синхронные проверки одного или 1–100 номеров и считывать баланс, используя те же учетные данные и ограничения, что и REST API. Он не предлагает инструмент для пакетных задач, поэтому обновление всей базы данных по-прежнему должно проходить через панель управления или Bulk API. Ассистенты полезны для выборочных проверок во время анализа записей, результаты которых записываются человеком или интеграцией.

Узнать больше

Выберите информацию о продукте, соответствующую следующему шагу вашего рабочего процесса.

Источники