CRM-аналитика
Как сменить телефон клиента и сохранить правильную историю
Время чтения: 6 мин
Уровень материала: Для экспертов
Содержание
Клиент меняет номер телефона и ожидает, что магазин сохранит его покупки, бонусы и настройки. Одновременно старый номер может оказаться у другого человека. Если номер служит единственным ключом клиента, новая регистрация рискует открыть прежнюю историю или запустить сообщения, предназначенные прошлому владельцу.
Телефон выполняет несколько функций: это контакт для связи, иногда логин и иногда способ подтвердить вход. Эти функции нельзя автоматически считать одним и тем же. Получение SMS доказывает доступ к номеру сейчас, но не владение аккаунтом, который использовал его раньше.
Надёжный процесс строится вокруг постоянного ID аккаунта и проверяемой смены контакта. Ниже — схема для совместной работы CRM, продукта и команды безопасности. Конкретные способы подтверждения выбирает владелец авторизации.
Храните связь с номером во времени
В карточке недостаточно одного поля phone. Нужны хотя бы текущее значение, момент подтверждения, источник изменения и состояние связи: действует, заменена или требует проверки. Старый номер может оставаться в защищённой истории изменений, но не должен продолжать использоваться для входа и маркетинговой отправки.
Исторический заказ хранит собственные сведения на момент оформления. Если покупатель изменил телефон сегодня, это не повод переписать контакт во всех закрытых заказах. При этом интерфейс профиля не должен показывать прежние данные новому владельцу номера.
NIST рассматривает изменение заранее зарегистрированного телефона для аутентификации как привязку нового средства подтверждения. Это полезное основание разделять обычное редактирование контакта и изменение способа доступа к аккаунту. Рекомендация NIST здесь приводится как инженерный ориентир, а не как описание требований российского законодательства.
Разведите два маршрута смены
Первый маршрут — клиент вошёл в существующий аккаунт и подтверждает новый контакт. Система проверяет достаточность текущей аутентификации, подтверждает новый номер и фиксирует замену. Для чувствительных операций может потребоваться дополнительная проверка, определённая командой безопасности.
Второй маршрут — доступа к аккаунту нет, но человек сообщает, что раньше пользовался старым номером. Такой запрос относится к восстановлению доступа. Его нельзя закрыть только кодом на новый телефон: заявитель ещё не доказал связь с прежним аккаунтом.
| Ситуация | Следующий шаг | Чего не делать автоматически |
|---|---|---|
| Доступ к аккаунту есть, новый номер подтверждён | Применить утверждённую процедуру смены | Создавать второго клиента вместо изменения контакта |
| Доступа нет, старый номер недоступен | Восстановление доступа по отдельному процессу | Переносить историю по заявлению человека |
| Новый номер уже связан с другим аккаунтом | Проверить конфликт владения | Склеивать аккаунты по совпадению номера |
| Повторно пришло старое значение из кассы | Проверить версию и источник | Возвращать устаревший контакт в текущий профиль |
Обновите все места использования контакта
После подтверждения изменение должно попасть не только в карточку CDP — платформы клиентских данных. Старый номер может оставаться в сервисе SMS, очереди отложенных сообщений, сегменте, выгруженном файле или системе поддержки.
Передавайте изменение с постоянным ID клиента, временем действия и версией записи. Версия — порядковый номер изменения в источнике, который позволяет отличить новое состояние от запоздавшего старого. Если обновления приходят из нескольких систем, понадобятся правила приоритета источников.
У очереди отправок есть особенность: сообщение могло сохранить старый номер ещё при постановке в очередь. Поэтому смена поля в профиле не всегда изменит уже подготовленные задания. Их нужно отменить либо повторно проверить перед отправкой. Возможность такой проверки выясняют у конкретного поставщика.
Не переносите разрешения по одному совпадению
Настройки коммуникаций должны иметь понятную область действия: человек или аккаунт, контакт, канал и бренд. Смена телефона не должна создавать новое разрешение там, где его не было, и не должна отменять действующий отказ от рекламы.
Если компания допускает перенос определённых настроек внутри подтверждённого аккаунта, опишите это как отдельное правило с основанием. Если связь нового владельца номера с прежним аккаунтом не подтверждена, прежние разрешения и история к нему не переходят.
CRM-команде полезно получать готовое решение системы авторизации: «смена подтверждена для аккаунта A17». Самостоятельно выводить принадлежность аккаунта из последних покупок, имени или содержания переписки маркетинговая платформа не должна.
Условный пример запоздавшего обновления
В понедельник клиент меняет телефон в личном кабинете. Событие получает версию 12. Во вторник касса выгружает накопленные записи за выходные и передаёт старый номер из версии 11. Если применяется правило «последнее полученное значение побеждает», CRM возвращает старый телефон.
В корректной схеме поздний файл обновляет историю покупки, но не отменяет более новую подтверждённую связь с контактом. В журнале остаётся причина отказа от изменения поля. Следующая SMS проверяет действующий номер и актуальные разрешения непосредственно перед передачей провайдеру.
Если версии между системами несопоставимы, нельзя сравнивать их как обычные числа. Тогда решение опирается на назначенный источник контакта и его время изменения, а конфликт отправляется на разбор.
Опишите переход как отдельную операцию
В задаче интегратору полезно задать состояния «запрошено», «подтверждено», «применено» и «отклонено». Это состояния процесса смены, а не самого клиента. Запрос содержит ID аккаунта, новый контакт и код операции; подтверждение — основание принятого решения; применение — отметки зависимых систем.
Пока проверка не завершена, новый номер не должен незаметно заменить рабочий контакт во всех каналах. Если часть систем обновилась, а часть нет, операция остаётся незавершённой и требует восстановления. Повтор того же запроса должен продолжать одну операцию, а не создавать ещё одну смену.
Отдельно определите, каким способом клиент узнаёт о завершении. Не отправляйте уведомление с подробностями аккаунта на прежний номер, если его принадлежность уже не подтверждена. Уведомление о безопасности и рекламное сообщение имеют разные назначения и правила.
Принимайте процесс по наблюдаемому результату
Проведите смену на тестовом аккаунте с покупками, бонусами и отложенным сообщением. Проверьте, что ID сохранился, история не исчезла, старый номер больше не используется, а повторная регистрация на нём не открывает прежние данные.
Отдельно воспроизведите конфликт двух аккаунтов и повторную загрузку старого файла. Зафиксируйте время распространения изменения по системам и способ остановки сообщений на переходный период. Эти проверки дают более полезный результат, чем подтверждение «поле phone успешно обновлено».
Источники
National Institute of Standards and Technology. Digital Identity Guidelines Authentication and Authenticator Management. NIST SP 800-63B-4. Раздел Authentication Using the Public Switched Telephone Network. Проверено 22.09.2026.