SABSUS
Help me chooseПомочь выбрать Book a demoПолучить демо
SABSUSSABSUS
DemoДемо
Customer data architectureАрхитектура клиентских данных

One customer profile across POS, CRM, app, chat, bookings, orders, and loyaltyЕдиный профиль клиента в POS, CRM, приложении, чатах, записях, заказах и лояльности

A practical guide to customer identity resolution across channels: consent, matching, merge rules, household and company relationships, timeline, preferences, loyalty, service, access, and analytics.Практическое руководство по объединению клиента между каналами: согласия, сопоставление, правила слияния, связи семьи и компании, история, предпочтения, лояльность, сервис, доступ и аналитика.

2026-07-13 RU + EN unified customer profile · single customer view · POS CRM integration
Customer relationship continuing across retail channels
A unified profile is not a larger contact card. It is a governed identity and event history that makes every channel continue the same relationship.Единый профиль не является большой карточкой контакта. Это управляемая личность и история событий, позволяющая каждому каналу продолжить одни отношения.
Decision in 60 secondsРешение за 60 секунд Is an email address enough to identify one customer across channels?Достаточно ли email, чтобы узнать одного клиента во всех каналах?

No. Email can be shared, mistyped, changed, or absent. Use verified identifiers and confidence-based matching with explicit merge and split controls. Preserve source, consent, and history so the business can explain why two records were joined and undo a mistake safely.Нет. Email может быть общим, ошибочным, измененным или отсутствовать. Используйте проверенные идентификаторы и сопоставление по уверенности с явным слиянием и разделением. Сохраняйте источник, согласия и историю, чтобы объяснить объединение и безопасно отменить ошибку.

IdentityЛичностьVerified phone, email, app account, payment token, loyalty ID, and business relationship have different confidence.Телефон, email, аккаунт, платежный токен, ID лояльности и связь компании имеют разную уверенность.
ConsentСогласиеMarketing, service, analytics, and channel preferences remain purpose-specific.Маркетинг, сервис, аналитика и каналы остаются привязанными к цели.
TimelineИсторияEvery call, order, booking, visit, payment, message, issue, and outcome keeps source and owner.Каждый звонок, заказ, запись, визит, платеж, сообщение, проблема и результат хранят источник и владельца.
Identity-to-service loopЦикл от личности до сервиса

Recognize the person, respect the permission, continue the contextУзнайте человека, соблюдайте разрешение, продолжайте контекст

The profile should improve service without turning uncertain matches into invisible surveillance or incorrect personalization.Профиль должен улучшать сервис, не превращая неопределенные совпадения в скрытое наблюдение или ошибочную персонализацию.

STEP 1ШАГ 1

Signal capturedСигнал получен

A POS visit, app login, chat, call, booking, order, or support request carries source identifiers.POS-визит, вход, чат, звонок, запись, заказ или поддержка несут идентификаторы источника.

STEP 2ШАГ 2

Identity resolvedЛичность сопоставлена

Deterministic or scored rules link, create, hold, or send the case to review.Детерминированные или оценочные правила связывают, создают, удерживают или отправляют на проверку.

STEP 3ШАГ 3

Consent checkedСогласие проверено

Purpose, channel, jurisdiction, timestamp, source, and withdrawal state are evaluated.Проверяются цель, канал, юрисдикция, время, источник и отзыв согласия.

STEP 4ШАГ 4

Context usedКонтекст использован

Staff or automation receives only the history and preferences needed for the task.Сотрудник или автоматизация получает только нужную для задачи историю и предпочтения.

STEP 5ШАГ 5

Outcome returnedРезультат записан

The action, owner, result, promise, and next step update the shared timeline.Действие, ответственный, результат, обещание и следующий шаг обновляют общую историю.

Identity resolutionСопоставление личности

Create confidence rules before merging customer recordsСоздайте правила уверенности до объединения клиентов

Classify identifiers as verified, strong, weak, shared, or contextual. Exact verified account IDs can match automatically; shared phone numbers, family emails, recycled numbers, device IDs, names, and addresses may require additional evidence. Keep candidate matches separate until the threshold is met and expose merge history to authorized staff.Разделите идентификаторы на проверенные, сильные, слабые, общие и контекстные. Точный подтвержденный ID можно связать автоматически; общий телефон, семейный email, перераспределенный номер, устройство, имя и адрес требуют дополнительных фактов. Храните кандидатов отдельно до порога и показывайте историю слияния уполномоченным ролям.

  • Deterministic first. Prefer verified login, loyalty ID, or confirmed channel over probabilistic clues.Сначала точное совпадение. Предпочитайте подтвержденный вход, ID лояльности или канал вероятностным признакам.
  • Explain the match. Store which fields, rules, confidence, and user created the link.Объясняйте совпадение. Храните поля, правила, уверенность и пользователя, создавшего связь.
  • Support split and undo. A mistaken merge must be reversible without losing source events.Поддерживайте разделение. Ошибочное слияние отменяется без потери исходных событий.
Customer profile and product relationship in retail
Purpose-limited consentСогласие по цели

Do not turn service permission into unlimited marketing permissionНе превращайте разрешение на сервис в безграничный маркетинг

Store the purpose, channel, source, language, timestamp, policy version, jurisdiction where relevant, and withdrawal state. A transactional message about an order is not the same as promotional messaging. Staff and automation should evaluate permission at the moment of action and respect quiet hours, channel preferences, and suppression lists.Храните цель, канал, источник, язык, время, версию политики, юрисдикцию и отзыв. Транзакционное сообщение о заказе не равно рекламе. Сотрудник и автоматизация проверяют разрешение в момент действия и учитывают тихие часы, предпочтения каналов и запреты.

01

Separate purposesРазделяйте цели

Service, marketing, analytics, profiling, and sensitive data may need distinct controls.Сервис, маркетинг, аналитика, профилирование и чувствительные данные требуют разных правил.

02

Real-time enforcementПроверка в момент действия

A campaign or AI agent checks current permission before sending or speaking.Кампания или AI проверяет текущее разрешение до сообщения.

03

Withdrawal propagationРаспространение отзыва

A preference change updates connected channels without delayed copies.Изменение предпочтения обновляет связанные каналы без задержанных копий.

Useful contextПолезный контекст

Show staff the next useful fact, not the entire data warehouseПоказывайте сотруднику следующий полезный факт, а не всю базу

A cashier, technician, marketer, support agent, and manager need different views. Present open commitments, recent issues, active order, preference, loyalty, warranty, and next action according to role. Mask sensitive fields, separate household and company relationships, and log access to high-risk data.Кассиру, технику, маркетологу, поддержке и менеджеру нужны разные представления. Показывайте открытые обещания, недавние проблемы, активный заказ, предпочтение, лояльность, гарантию и следующий шаг по роли. Маскируйте чувствительные поля, разделяйте семью и компанию и журналируйте доступ к рискованным данным.

01

Task contextКонтекст задачи

The view starts with the action the role is expected to complete.Представление начинается с действия, которое должна завершить роль.

02

Relationship modelМодель отношений

Represent person, household, organization, location, payer, recipient, and decision maker separately.Отдельно представляйте человека, семью, организацию, точку, плательщика, получателя и решающего.

03

Sensitive accessЧувствительный доступ

Use masking, purpose, elevated approval, and audit for protected fields.Используйте маскирование, цель, расширенное согласование и журнал для защищенных полей.

Behavior without manipulationПоведение без манипуляции

Use history to make service relevant, not to create pressureИспользуйте историю для релевантного сервиса, а не давления

A useful profile helps a business remember preferences, avoid repeating failures, honor warranties, replenish expected products, schedule maintenance, and recognize loyalty. It should not exploit sensitive inference or bury the customer in messages. Measure completed value and customer control, not only click-through rate.Полезный профиль помогает помнить предпочтения, не повторять ошибки, соблюдать гарантию, пополнять нужные товары, назначать обслуживание и учитывать лояльность. Он не должен использовать чувствительные предположения или заваливать сообщениями. Измеряйте завершенную ценность и контроль клиента, а не только клики.

01

Service recovery memoryПамять восстановления

Do not repeat a known failure or make the customer explain it again.Не повторяйте известную ошибку и не заставляйте клиента объяснять ее заново.

02

Relevant timingУместное время

Use expected need, active lifecycle, consent, and channel preference.Учитывайте ожидаемую потребность, этап, согласие и канал.

03

Customer controlКонтроль клиента

Make preferences, consent, correction, export, and deletion paths understandable.Сделайте предпочтения, согласия, исправление, экспорт и удаление понятными.

Profile maturityЗрелость профиля

A contact list, CRM record, and unified customer profile solve different problemsСписок контактов, CRM и единый профиль решают разные задачи

Use the model that preserves identity, permission, event history, and operational action across channels.Выберите модель, сохраняющую личность, разрешение, историю и действие между каналами.

CapabilityВозможностьContact listСписок контактовChannel CRMCRM одного каналаUnified profileЕдиный профиль
Identity confidenceУверенность личностиEmail or phoneEmail или телефонChannel-specific recordЗапись каналаVerified and scored matchingПроверенное и оценочное сопоставление
ConsentСогласиеSingle flagОдин флагOften channel-specificЧасто по каналуPurpose, channel, source, time, versionЦель, канал, источник, время, версия
HistoryИсторияNotesЗаметкиActivities in one toolДействия одного инструментаOrdered cross-channel events and outcomesСобытия и результаты всех каналов
OperationsОперацииManual lookupРучной поискSome tasks and salesНекоторые задачи и продажиOrders, bookings, payments, service, loyaltyЗаказы, записи, платежи, сервис, лояльность
CorrectionИсправлениеEdit fieldПравка поляMerge may be limitedСлияние ограниченоExplainable merge, split, source preservationОбъяснимое слияние, разделение, источники
Identity pilotПилот идентичности

Start with one customer journey that crosses two channelsНачните с одного пути клиента между двумя каналами

Booking to POS, app order to support, or phone lead to CRM are bounded flows where duplicate identity and missing context are visible.Запись в POS, заказ из приложения в поддержку или звонок в CRM являются ограниченными потоками, где видны дубли и потерянный контекст.

PHASE 1ЭТАП 1

Audit duplicatesАудит дублей

Sample records and classify shared identifiers, typo patterns, missing consent, and merge risk.Изучите записи и классифицируйте общие идентификаторы, ошибки, пропущенные согласия и риск слияния.

PHASE 2ЭТАП 2

Set match policyЗадать политику

Define deterministic links, confidence thresholds, manual review, split, and undo.Определите точные связи, пороги уверенности, ручную проверку, разделение и отмену.

PHASE 3ЭТАП 3

Build role viewsСоздать представления ролей

Show each role the minimum context required to complete the chosen journey.Покажите каждой роли минимальный контекст выбранного пути.

PHASE 4ЭТАП 4

Measure continuityИзмерить непрерывность

Track duplicate rate, repeat questions, consent errors, resolution time, and repeat value.Считайте дубли, повторные вопросы, ошибки согласий, время решения и повторную ценность.

Practical FAQПрактические вопросы

Questions to resolve before implementationВопросы, которые стоит закрыть до внедрения

Can SABSUS merge duplicate customer records?Может ли SABSUS объединять дубли клиентов?

The process can use verified and scored identifiers with authorized review, preserved source history, and controlled merge or split actions.Процесс использует проверенные и оценочные идентификаторы, уполномоченную проверку, сохранение источников и управляемое слияние или разделение.

How are family or company accounts handled?Как учитывать семью или компанию?

Model relationships explicitly: person, household, organization, payer, recipient, decision maker, location, and authorized contact should not be collapsed into one identity.Моделируйте связи явно: человек, семья, организация, плательщик, получатель, принимающий решение, точка и уполномоченный контакт не сливаются в одну личность.

Can employees see all customer data?Могут ли сотрудники видеть все данные клиента?

No. Views and actions should follow role, task, purpose, sensitivity, location scope, and approval policy, with masking and audit where needed.Нет. Представления и действия зависят от роли, задачи, цели, чувствительности, точки и согласования, с маскированием и журналом.

What is the first quality metric?Какая первая метрика качества?

Measure duplicate and false-merge rates together. Reducing duplicates is not success if incorrect people are joined.Измеряйте долю дублей и ошибочных слияний вместе. Снижение дублей не является успехом, если объединены разные люди.

Continue the decisionПродолжить выбор

Open the pages connected to this workflowОткройте страницы, связанные с этим процессом

Use product and industry pages to validate the scenario against your team, locations, and customer journey.Сверьте сценарий с вашей командой, точками и клиентским путем на продуктовых и отраслевых страницах.

See where one customer becomes five disconnected recordsУвидьте, где один клиент превращается в пять разных записей

Bring a real cross-channel customer journey. We will map identity signals, consent, merge rules, role views, timeline, next action, and the SABSUS modules that should share the profile.Возьмите реальный путь клиента между каналами. Мы разберем идентификаторы, согласия, правила слияния, представления ролей, историю, следующий шаг и модули SABSUS, которые должны использовать один профиль.

From reading to a decisionОт чтения к решению

Apply the idea to one workflow in your businessПримените идею к одному процессу вашего бизнеса

Bring a real request, order or customer journey. We will separate facts from assumptions and define the smallest useful next step.Возьмите реальную заявку, заказ или путь клиента. Мы отделим факты от предположений и определим минимальный полезный следующий шаг.

01Name the lossФиксируем потерю02Map owner and dataОпределяем владельца и данные03Agree on a proof metricСогласуем метрику проверки