Глава 15. Управление отношениями с клиентом после покупки

Объектное правило владения. OwnershipID идентифицирует контекст владения после сделки. Возникновение новой самостоятельной коммерческой потребности создаёт новый LeadID; реактивация прежней незавершённой потребности сохраняет существующий LeadID.

Вводный аппарат

Паспорт главы

Место в архитектуре: управление отношениями с клиентом после покупки — самостоятельный посттранзакционный контур, следующий после управления продажами. Он не является частью MOS, уровнем цепочка создания маркетинговой ценности, стадией управление жизненным циклом лида или продолжением управление продажами.

Граница входа: подтвержденное событие OWNER_ACCEPTED.

Единица управления: связь Identity–Product–Ownership Episode.

Основное преобразование: принятие владения → onboarding → получение ценности в использовании → исполнение обещаний → управление жизненными событиями → сервис и поддержка → complaint и recovery → удержание → распознавание нового спроса.

Непосредственный результат: управляемый Ownership Episode и доказательная обратная связь о качестве продукта, обещаний и отношений.

Коммерческий результат: при возникновении новой самостоятельной потребности создается новый Demand Episode, который проходит применимый маршрут привлечение лидов → MQL → управление жизненным циклом лида → SQL → управление продажами.

Место главы в общей архитектуре

Предшествующий управленческий контур MOS сохраняет нормативную последовательность:

цепочка создания маркетинговой ценности содержит ровно четыре функциональных уровня:

Прямым выходом MVC является MQL. Затем управление жизненным циклом лида преобразует MQL в SQL, а управление продажами — SQL в сделку. Только после подтвержденного принятия результата возникает управление отношениями с клиентом после покупки:

Цель главы

Цель главы — сформировать целостную управленческую модель посттранзакционного контура: определить момент его начала, объект управления, операционные продукты, организационные роли, правила измерения и нормативный способ возвращения повторного и реферального спроса в новый коммерческий цикл.

Результаты обучения

После изучения главы руководитель должен уметь:

• установить границу управление продажами и управление отношениями с клиентом после покупки;
• разработать Owner Acceptance Rules;
• определить Owner Record и Ownership Episode ID;
• развести buyer, owner, user, payer и representative;
• создать Ownership State Model и Ownership Plan;
• организовать onboarding через подтвержденный outcome;
• внедрить Promise Register;
• различать Service Episode, Complaint Case и Recovery Plan;
• измерять retention, churn, CLV и Customer Equity;
• сформировать Replacement Pool без объявления его pipeline;
• создать новый Demand Episode для повторного или реферального спроса;
• построить межфункциональные контракты и модель мощности.

Ключевой вопрос главы

Как превратить завершенную сделку в доказательно управляемое владение, обеспечить получение ценности и корректно распознать момент рождения нового спроса, не смешивая управление отношениями с клиентом после покупки с маркетингом, квалификацией лида и продажами?

15.1. управление отношениями с клиентом после покупки как следующий контур после управления продажами

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

15.1.1. Вход, преобразование и результат

Таблица 267. Входы, преобразование и результат управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

15.1.2. Архитектурные границы

Таблица 268. Границы управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

Скорость и качество передачи измеряются раздельно. Доля принятых передач:

Время до принятия:

Полнота Owner Record:

Авторское положение 15.1

Управление отношениями с клиентом после покупки начинается не после оплаты, подписания договора или внутреннего закрытия сделки, а после подтвержденного события OWNER_ACCEPTED, означающего, что новый Ownership Episode принят посттранзакционным контуром в управление.

15.2. Научные подходы и границы авторского синтеза

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

15.2.1. Междисциплинарное основание

Relationship marketing объясняет долгосрочную ценность отношений; commitment–trust theory — роль доверия и взаимных обязательств; service-dominant logic — возникновение ценности в использовании; customer experience и customer journey — целостность опыта между каналами и этапами. Исследования service quality, satisfaction, loyalty и retention раскрывают качество услуги и устойчивость поведения. Complaint handling и service recovery показывают, почему техническое исправление, справедливое разрешение и восстановление доверия следует измерять отдельно.

Customer engagement, Customer Success, CLV и Customer Equity расширяют анализ от отдельного контакта до портфеля отношений. Survival analysis позволяет корректно работать с незавершенными периодами наблюдения; causal inference — отделять эффект программы от самоотбора и рыночных факторов; record linkage — управлять неопределенностью идентичности; теория очередей и capacity management — соотносить обязательства с ресурсами.

Таблица 269. Научные основания управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

15.2.2. Уровни доказательности

Таблица 270. Различение типов знания в управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

Авторское положение 15.2

управление отношениями с клиентом после покупки объединяет положения relationship marketing, service-dominant logic, customer experience, service recovery, Customer Success, CLV и Customer Equity, но не сводится ни к одному из этих подходов: его самостоятельным объектом является управляемая связь Identity–Product–Ownership Episode.

15.3. Deal Handoff Acceptance и формирование Owner Record

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

15.3.1. Deal Handoff Package

Таблица 271. Минимальный состав Deal Handoff Package

Таблицу можно прокручивать по горизонтали.

15.3.2. События принятия

Таблица 272. События Deal Handoff Acceptance

Таблицу можно прокручивать по горизонтали.

15.3.3. Owner Record

Таблица 273. Структура Owner Record

Таблицу можно прокручивать по горизонтали.

Таблица 274. Роли в передаче владения

Таблицу можно прокручивать по горизонтали.

Доля пакетов, принятых с первой передачи:

Авторское положение 15.3

Передача сделки в управление отношениями с клиентом после покупки является двусторонним управленческим актом. Отправка Deal Handoff Package не завершает управление продажами: переход считается состоявшимся только после проверки пакета, принятия ответственности и регистрации OWNER_ACCEPTED.

15.4. Identity, Product и Ownership Episode

15.4.1. Три самостоятельных объекта

Identity отвечает на вопрос «кто участвует в отношении», Product — «по поводу какого продукта», Ownership Episode — «в какой роли, на каком основании и в какой период существует связь». Их объединение в одну карточку уничтожает важные различия.

Таблица 275. Объекты и связи управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

Одна Identity может одновременно иметь несколько продуктов. Один Product может последовательно переходить между владельцами. Один household может включать несколько Identity и несколько продуктов, но не должен автоматически объединяться без доказательств.

Целостность связей оценивается как:

15.4.2. Ownership State Model

Таблица 276. Базовые состояния Ownership Episode

Таблицу можно прокручивать по горизонтали.

Таблица 277. Запрещенные переходы и интерпретации

Таблицу можно прокручивать по горизонтали.

Авторское положение 15.4

Identity, Product и Ownership Episode являются разными объектами. Один субъект может участвовать в нескольких эпизодах владения, один продукт может последовательно менять владельцев и пользователей, а изменение одной связи не должно уничтожать историю остальных.

15.5. Onboarding, обещания и достижение ценности

15.5.1. Ownership Plan

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

Таблица 278. Минимальный состав Ownership Plan

Таблицу можно прокручивать по горизонтали.

15.5.2. Onboarding Outcome

Onboarding не завершается фактом отправки сообщения. Его результатом является подтвержденная способность владельца использовать продукт и получить первую ценность.

Таблица 279. Состояния onboarding

Таблицу можно прокручивать по горизонтали.

15.5.3. Promise Register

Таблица 280. Обязательные поля Promise Register

Таблицу можно прокручивать по горизонтали.

Авторское положение 15.5

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

15.6. Lifecycle milestones и сервисная оркестрация

15.6.1. Значимые события жизненного цикла

Владение развивается через продуктовые, сервисные, гарантийные, финансовые и отношенческие milestones. Событие требует действия только тогда, когда оно актуально, доказано и допускает выбранную цель обработки.

Таблица 281. Основные lifecycle milestones

Таблицу можно прокручивать по горизонтали.

15.6.2. Service Episode

Таблица 282. События Service Episode

Таблицу можно прокручивать по горизонтали.

Покрытие milestones:

Сервисное удержание зрелой когорты:

Соблюдение сервисного интервала:

Требуемая мощность:

Авторское положение 15.6

Жизненный цикл владельца управляется через значимые milestones и самостоятельные Service Episodes. Плановая дата, сервисный сигнал или созданная задача не доказывают наступление результата: каждый переход требует события, доказательства и ответственной роли.

15.7. Retention, доверие, жалобы и service recovery

15.7.1. Разделение трех результатов

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

Таблица 283. Complaint и recovery taxonomy

Таблицу можно прокручивать по горизонтали.

15.7.2. Причины риска прекращения отношений

Таблица 284. Churn drivers и требуемые доказательства

Таблицу можно прокручивать по горизонтали.

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

Авторское положение 15.7

Устранение технического дефекта, закрытие жалобы и восстановление отношений — три разных результата. Service Resolution не подтверждает Complaint Resolution, а Complaint Resolution не доказывает восстановление доверия без отдельной проверки Recovery Outcome.

15.8. Повторный, замещающий и реферальный спрос: новый Demand Episode

После начала владения возникают сигналы будущего спроса: срок замены, окончание гарантии, рост затрат на обслуживание, интерес к дополнительному продукту, запрос trade-in или готовность рекомендовать бренд. Ни один из них сам по себе не является MQL, SQL или opportunity.

15.8.1. Триггер, сигнал и квалификация

Таблица 285. Trigger, signal, Demand Episode и стадии квалификации

Таблицу можно прокручивать по горизонтали.

15.8.2. Сценарии owner-originated demand

Таблица 286. Сценарии повторного и реферального спроса

Таблицу можно прокручивать по горизонтали.

Replacement Readiness является вероятностной оценкой:

Replacement Pool — портфель эпизодов для допустимой проверки гипотезы. Он не является pipeline, числом лидов или гарантированным прогнозом.

15.8.3. Нормативный маршрут

Ускоренный маршрут допустим, только если все критерии MQL и SQL фактически выполнены и доступны для аудита:

Коэффициент повторной покупки зрелой когорты:

Конверсия Replacement Pool:

Реферальная конверсия:

Авторское положение 15.8

Наличие действующего Ownership Episode дает организации контекст, но не право объявлять новый спрос состоявшимся. Повторная, дополнительная, замещающая или реферальная ситуация должна получать новый Demand Episode и проходить применимые стандарты MQL, SQL и управление продажами. Ускоряться может маршрут, но не доказательность перехода.

15.9. Операционные продукты и управленческие активы

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

15.9.1. Каталог операционных продуктов

Таблица 287. Операционные продукты управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

15.9.2. Разграничение случаев

Таблица 288. Service Episode, Complaint Case и Recovery Plan

Таблицу можно прокручивать по горизонтали.

15.9.3. Качество операционных продуктов

Таблица 289. Стандарт качества операционных продуктов

Таблицу можно прокручивать по горизонтали.

Среднее значение не компенсирует критический дефект:

Авторское положение 15.9

управление отношениями с клиентом после покупки существует как управленческий контур только в той мере, в какой производит и поддерживает доказательные операционные продукты. CRM-карточка, заметки и история коммуникаций не заменяют систему Owner Record, Ownership Plan, Promise Register, Service Episode, Complaint Case, Recovery Plan, Health Profile и Demand Episode Link.

15.10. Организационная модель и межфункциональные контракты

управление отношениями с клиентом после покупки не является работой одного подразделения. Единый владелец результата координирует распределенное исполнение сервиса, контакт-центра, продукта, маркетинга, финансов, данных и партнеров.

15.10.1. Роли

Таблица 290. Основные роли управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

Таблица 291. Пример распределения ответственности

Таблицу можно прокручивать по горизонтали.

15.10.2. Integration Contracts

Таблица 292. Основные межфункциональные контракты

Таблицу можно прокручивать по горизонтали.

Переход состояния требует:

Соблюдение SLA:

Нагрузка на мощность:

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

Авторское положение 15.10

управление отношениями с клиентом после покупки должен иметь единого владельца результата, но не обязан быть единым подразделением. Его организационная основа — распределенная ответственность вокруг Ownership Episode, закрепленная правами решений, операционными продуктами, межфункциональными контрактами, SLA, правилами эскалации и регулярным управленческим ритмом.

15.11. Метрики, экономика и доказательная оценка

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

15.11.1. Дерево показателей

Таблица 293. Дерево показателей управление отношениями с клиентом после покупки

Таблицу можно прокручивать по горизонтали.

15.11.2. Retention, churn и survival

Retention имеет смысл только при указании объекта: договора, использования, владения, сервиса или отношений с брендом.

Для незавершенных наблюдений применяется функция выживания:

и hazard rate:

Причины прекращения должны различать переход к конкуренту, выход из категории, замену внутри бренда, передачу продукта и потерю наблюдения. Качество знания о причинах:

15.11.3. Value-in-Use и Owner Health Profile

Таблица 294. Структура Owner Health Profile

Таблицу можно прокручивать по горизонтали.

Критический флаг безопасности, жалобы или правомерности не должен исчезать в среднем score.

15.11.4. Cost-to-Serve, CLV и Customer Equity

Инкрементальная ценность программы:

Стоимость повторного принятого владения:

Реферальный вклад:

15.11.5. Причинная оценка и гипотезы

Таблица 295. Портфель рабочих гипотез

Таблицу можно прокручивать по горизонтали.

Таблица 296. Пример паспорта Repeat Purchase Rate

Таблицу можно прокручивать по горизонтали.

Авторское положение 15.11

Экономическая ценность управление отношениями с клиентом после покупки возникает не из факта существования клиентской базы, а из доказанного изменения результата владельца, длительности отношений, повторного и реферального спроса после учета Cost-to-Serve, стоимости капитала и контрфактического сценария. CLV и Customer Equity завершают систему измерения, но не заменяют показатели качества владения.

15.12. Внедрение управление отношениями с клиентом после покупки и модель зрелости

15.12.1. Уровни зрелости

Уровень 0 — фрагментированное обслуживание. Единого владения нет; сервис, маркетинг и продажи используют разные карточки; повторный спрос создается массовыми выборками.

Уровень 1 — учет владения. Введены OWNER_ACCEPTED, Owner Record, Product ID, Ownership Episode ID и базовая State Model.

Уровень 2 — стандартизированное сопровождение. Действуют Ownership Plan, onboarding, Promise Register, Service Episode, Complaint Case, SLA и Tracking Standard.

Уровень 3 — межфункциональная оркестрация. Назначен Relationship Owner, работают Integration Contracts, Recovery Plan, capacity control и нормативный новый Demand Episode.

Уровень 4 — аналитическое управление. Применяются когортный анализ, survival analysis, Owner Health Profile, Replacement Readiness, CLV и Customer Equity.

Уровень 5 — доказательно адаптивная система. Гипотезы проверяются причинно, модели контролируются, а стандарты изменяются на основании доказательств.

15.12.2. Последовательность внедрения

1. Провести архитектурную диагностику реальных записей и переходов.
2. Утвердить объекты, идентификаторы, события, статусы и reason codes.
3. Назначить роли и права решений.
4. Внедрить Deal Handoff → OWNER_ACCEPTED → Owner Record.
5. Подключить onboarding, promises, service, complaint и recovery.
6. Запустить пилот на управляемом продукте или бизнес-юните.
7. Проверить полноту событий, когорт и финансовой связности.
8. Отработать Ownership Episode → New Demand Episode → MQL → SQL → управление продажами.
9. Согласовать программы с мощностью.
10. Масштабировать стандарт, а затем автоматизацию.

Минимально жизнеспособный контур включает OWNER_ACCEPTED, Deal Handoff Package, Owner Record, Ownership Episode ID, State Model, Ownership Plan, Promise Register, Service Episode, Complaint Case, Relationship Owner, новый Demand Episode и Tracking Standard.

15.12.3. Стоп-правила

Масштабирование останавливается при систематически неверной Identity, отсутствии основания обработки, потере истории, ложных Demand Episodes, отсутствии владельца решения, неконтролируемом превышении мощности или ухудшении обязательных результатов владельца.

Технологическая последовательность:

Авторское положение 15.12

управление отношениями с клиентом после покупки — самостоятельный посттранзакционный контур, принимающий подтвержденное владение после управления продажами. Он обеспечивает получение ценности и исполнение обещаний, управляет сервисом, жалобами, восстановлением и удержанием, а при возникновении нового спроса создает новый Demand Episode и возвращает его в последовательность цепочка создания маркетинговой ценности → MQL → управление жизненным циклом лида → SQL → управление продажами.

Завершающий аппарат

Итоги главы

1. Продажа создает коммерческий результат, но не доказывает начало управляемого владения.
2. управление продажами завершается только после двустороннего принятия Deal Handoff Package и события OWNER_ACCEPTED.
3. управление отношениями с клиентом после покупки управляет не абстрактным клиентом, а конкретным Ownership Episode.
4. Identity, Product, Deal и Ownership Episode должны иметь самостоятельные идентификаторы и доказательные связи.
5. Onboarding завершается подтверждением Value-in-Use, а не фактом коммуникации.
6. Обещание является отдельным обязательством с источником, сроком, владельцем и критерием выполнения.
7. Service Episode, Complaint Case и Recovery Plan имеют разные результаты и условия закрытия.
8. Retention и churn требуют точного определения сохраняемого объекта, зрелых когорт и учета censoring.
9. Lifecycle trigger, behavioral signal и известная Identity не являются новым спросом или квалифицированным лидом.
10. Повторная, замещающая, дополнительная и реферальная потребность получает новый Demand Episode.
11. Новый спрос возвращается через привлечение лидов, MQL, LLM, SQL и управление продажами.
12. Replacement Pool является портфелем гипотез, а не pipeline или гарантированным forecast.
13. CLV рассчитывается по маржинальному вкладу после Cost-to-Serve, риска и дисконтирования.
14. Экономический эффект управление отношениями с клиентом после покупки должен быть инкрементальным, а не только наблюдаемым.
15. Автоматизация следует за определением объектов, состояний, прав решений и доказательств.

Свод 12 авторских положений

1. 15.1: Управление отношениями с клиентом после покупки начинается только после подтвержденного OWNER_ACCEPTED.
2. 15.2: научные подходы объясняют отдельные механизмы; Identity–Product–Ownership Episode является авторским синтезом.
3. 15.3: передача сделки завершается принятием, а не отправкой данных.
4. 15.4: Identity, Product и Ownership Episode нельзя объединять в один объект.
5. 15.5: onboarding должен завершаться outcome; обещания требуют отдельного управления.
6. 15.6: lifecycle milestones и Service Episodes требуют event, evidence и authorized role.
7. 15.7: сервисное исправление, разрешение жалобы и recovery — разные результаты.
8. 15.8: новый спрос получает новый Demand Episode и заново проходит квалификацию.
9. 15.9: управление отношениями с клиентом после покупки материализуется через систему операционных продуктов.
10. 15.10: единая ответственность совместима с распределенным исполнением.
11. 15.11: Customer Equity завершает, но не заменяет систему операционных показателей.
12. 15.12: зрелость определяется доказательностью, управляемостью и инкрементальной экономикой.

Контрольные вопросы

1. Какое событие завершает управление продажами и открывает управление отношениями с клиентом после покупки?
2. Почему оплата или подписание договора не всегда означают начало Ownership Episode?
3. Чем управление отношениями с клиентом после покупки отличается от CRM-маркетинга, сервиса и программы лояльности?
4. Почему управление отношениями с клиентом после покупки не является пятым уровнем MVC?
5. Чем Identity отличается от Owner Record?
6. Почему Product и Ownership Episode нельзя объединять?
7. Как различаются buyer, owner, user, payer и representative?
8. Какие доказательства необходимы для изменения Identity–Product Link?
9. Что должно входить в Deal Handoff Package?
10. Почему отправка пакета не означает завершения handoff?
11. Кто отвечает за транзакционные обязательства, не завершенные к моменту OWNER_ACCEPTED?
12. Как определяется целевое состояние onboarding?
13. Почему приветственный звонок не подтверждает завершение onboarding?
14. Какие поля обязательны для Promise Register?
15. Чем renegotiated promise отличается от breached promise?
16. Чем Service Episode отличается от Complaint Case?
17. Когда требуется Recovery Plan?
18. Почему завершенный ремонт не всегда означает восстановление отношений?
19. Какой объект может сохраняться при завершении конкретного Ownership Episode?
20. Почему отсутствие наблюдения нельзя автоматически считать churn?
21. Чем lifecycle trigger отличается от Demand Episode?
22. Почему известный владелец не является автоматически MQL или SQL?
23. При каких условиях допустим fast-track?
24. Почему Replacement Pool нельзя включать в pipeline?
25. Как должен регистрироваться реферальный спрос?
26. В чем состоит ответственность Relationship Owner?
27. Чем system of record отличается от system of engagement и workflow?
28. Как мощность ограничивает допустимый уровень обещаний?
29. Чем Historical CLV отличается от Predictive и Incremental CLV?
30. Почему корреляция повторной покупки с участием в программе не доказывает причинный эффект?

Практические задания

Задание 1. Граница владения

Восстановите реальный путь одного продукта от заключения сделки до фактического использования. Определите момент HANDOFF_READY, требования к Deal Handoff Package и доказательство OWNER_ACCEPTED.

Задание 2. Модель субъектов

На выборке сделок разделите buyer, owner, user, payer, representative и decision-maker. Установите, где существующая система ошибочно объединяет роли.

Задание 3. Ownership State Model

Разработайте состояния Ownership Episode. Для каждого задайте Entry Criteria, Exit Criteria, evidence, authorized role и запрещенные переходы.

Задание 4. Ownership Plan

Составьте план первых двенадцати месяцев владения выбранным продуктом: onboarding, milestones, обещания, сервис, риски и критерии результата.

Задание 5. Аудит обещаний

Извлеките обещания из рекламы, договора, продажи и сервиса. Для каждого назначьте Promise ID, Promise Owner, срок и доказательство выполнения.

Задание 6. Service Recovery

Разберите один повторный дефект на Service Episode, Complaint Case и Recovery Plan. Покажите отдельные условия завершения каждого объекта.

Задание 7. Retention

Сформируйте паспорт показателя retention: объект, старт, событие сохранения, окно, когорта, censoring, competing risks и правила неизвестных исходов.

Задание 8. Новый Demand Episode

Проверьте десять повторных продаж. Установите, создавались ли новые Demand Episode, MQL, SQL, opportunity и Ownership Episode.

Задание 9. Replacement Pool

Определите допустимые признаки Replacement Readiness, механизм проверки актуального владения и защитные метрики коммуникационной программы.

Задание 10. Реферальный сценарий

Спроектируйте Referral Record, самостоятельный отклик новой Identity, правила атрибуции и нормативный маршрут MQL–SQL–управление продажами.

Задание 11. Экономика владения

Для зрелой когорты объедините contribution margin, Cost-to-Serve, гарантийные расходы, recovery, повторные покупки и стоимость капитала. Рассчитайте Historical и Predictive CLV.

Задание 12. Пилот

Разработайте пилот управление отношениями с клиентом после покупки: границы, продукт, роли, объекты, события, SLA, мощность, KPI, guardrails, контроль и критерии масштабирования.

Учебный кейс «АвтоСфера»: от клиентской базы к управление отношениями с клиентом после покупки

Исходная ситуация

«АвтоСфера» — вымышленная многопрофильная автомобильная группа, работающая в трех территориальных кластерах и представляющая семь брендов. Группа продает новые автомобили, автомобили с пробегом и автомобили параллельного импорта, оказывает сервисные услуги, устанавливает дополнительное оборудование, предлагает trade-in, кредитование, лизинг и страхование.

За год реализовано 18 400 новых и 7 600 подержанных автомобилей. CRM содержит 312 000 клиентских карточек, DMS — 224 000 записей о клиентах и плательщиках, системы OEM — около 190 000 связанных записей. Руководство объявляет базу главным активом, сообщает NPS 71, LTV 1,8 млн рублей, 26 000 потенциальных замен и 9 400 «горячих владельцев».

Финансовая служба сомневается в показателях. LTV рассчитан как выручка первой сделки плюс ожидаемая стоимость следующего автомобиля. Себестоимость, скидки, гарантийные расходы, Cost-to-Serve, recovery и стоимость капитала не учитываются.

Формальное принятие владельца

В CRM существует поле Владелец принят, автоматически получающее значение «Да» в 23:59 дня выдачи. Поле изменяется независимо от того, был ли автомобиль фактически передан, получены ли документы, установлено ли оборудование, активирована ли гарантия и определен ли фактический пользователь.

В 8% сделок дата реальной передачи отличается от даты закрытия CRM. В 3% автомобиль остается в дилерском центре после формального завершения сделки. Отдельной принимающей роли и проверки пакета нет. Следовательно, поле не является настоящим OWNER_ACCEPTED.

Неполный Deal Handoff Package

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

Получатель не может отклонить передачу. Если VIN отсутствует или неверен, запись все равно считается принятой. Обещанное оборудование, документы и возвраты после закрытия сделки становятся «общей проблемой» без владельца.

Смешение buyer, owner, user и payer

Все участники записываются в одно поле «Клиент». Между тем в 11% случаев автомобиль оплачивает один человек, а регистрируется он на другого; в 7% автомобиль приобретается для члена семьи. В корпоративных продажах договор заключает организация, автомобилем пользуется сотрудник, сервис согласует руководитель автопарка. В кредитной сделке плательщик, собственник и пользователь также могут различаться.

При обращении фактического пользователя оператор иногда не видит автомобиль, поскольку VIN связан только с плательщиком. В других случаях сервисная история одного члена household показывается другому на основании общего телефона.

Отсутствие Ownership Episode ID

Системы используют Customer ID, Contract ID, VIN, Lead ID, Opportunity ID, OEM Customer ID, номер кредита, номер полиса и сервисную карту. Самостоятельного Ownership Episode ID нет.

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

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

Дубли между CRM, DMS и OEM

Аудит выявил вероятные дубли в 18% CRM-карточек. Один человек зарегистрирован по-разному по имени, телефону, электронной почте и номеру договора. Семейные автомобили объединяются по общему телефону. Корпоративные клиенты создаются заново в каждом филиале. VIN иногда содержит ошибку. Автомобили параллельного импорта отсутствуют у OEM.

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

Несвязанные направления

Продажа автомобиля, trade-in, кредит, страхование и сервис существуют как отдельные процессы. Подразделение автомобилей с пробегом не всегда видит связь принятого trade-in с новой сделкой. Сервис не знает о бесплатном первом ТО. Страховой отдел не передает срок полиса. Кредитный отдел трактует окончание кредита как готовность к покупке. Контакт-центр не видит претензии к оборудованию. Подразделения конкурируют за атрибуцию одной повторной сделки.

Разные lifecycle states

Северный кластер использует статусы новый, активный, потерянный; Центральный — клиент, сервисный, лояльный, на замену; Восточный — купил, прогрев, горячий, продал. Entry Criteria, Exit Criteria и evidence отсутствуют. Статус «лояльный» может означать высокий NPS, повторный сервис или отсутствие жалоб.

В CRM 41 000 «активных владельцев», хотя по 12 600 из них нет подтвержденных событий более трех лет.

Формальный onboarding

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

Не проверяется, получил ли владелец автомобиль, освоил ли функции, активировано ли приложение, выполнены ли обещания, установлено ли оборудование и понятны ли гарантийные условия. Onboarding Completion Rate равен 94%, но 22% владельцев в первый месяц повторно обращаются с вопросами, которые могли быть сняты при полноценном onboarding.

Потерянные обещания

Обещания фиксируются в свободном комментарии: установить колеса, передать ключи, вернуть переплату, выдать документ, активировать пакет, компенсировать задержку. Promise ID, срок, владелец, критерий и эскалация отсутствуют.

В выборке из 500 сделок найдено 126 обещаний. По 47 нельзя установить исполнителя, по 31 истек срок, по 18 компания считает обязательство выполненным, хотя владелец продолжает обращаться. В целом 740 владельцев ожидают оборудование, 96 — документы; 61 случай превышает 30 дней, а 23 обещания связаны с уволившимися сотрудниками.

Сервис без capacity alignment

Маркетинг ежемесячно формирует список автомобилей с приближающимся ТО. Контакт-центр направляет до 45 000 сообщений и совершает 12 000 звонков. Сервис способен принять около 7 500 дополнительных заказов. В пиковых филиалах ожидание записи достигает трех недель.

KPI маркетинга — число записей, сервиса — загрузка постов, контакт-центра — назначенные визиты. Владельцы не находят удобного времени, отменяют записи и уходят в независимый сервис. При этом first-service retention заявлен на уровне 68%.

Аудит показывает, что в знаменатель включены только владельцы с созданной сервисной записью, молодые когорты смешаны со зрелыми, межфилиальный сервис иногда считается потерей, а гарантийный ремонт — первым ТО. После исправления расчетов показатель зрелых когорт составляет 42–55% в зависимости от бренда.

Жалобы без root cause и recovery

Контакт-центр закрывает жалобу после ответа, сервис — после заказ-наряда, юридическая функция — после подготовки позиции. Один случай получает три разных статуса.

За год зарегистрировано 4 800 жалоб: 31% закрыты в день регистрации, 27% повторяются в другом канале, 19% связаны с обещаниями, 14% — с ожиданием деталей. Для 58% root cause не установлен. Recovery Plan не используется.

NPS и коммуникации

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

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

Согласия

CRM содержит один флаг Consent = Yes, который используется для исполнения договора, сервисных уведомлений, рекламы, предложений банка и страховщика, передачи OEM и телематики. Цели, срок и источник согласия не отображаются. Отказ от рекламы иногда блокирует обязательные сообщения, а сервисное основание используется для коммерческой рассылки.

Replacement Pool и автоматические SQL

Все автомобили старше трех лет включаются в Replacement Pool. Не учитываются действительность владения, пробег, сервис, жалобы, финансовая ситуация, остаточная стоимость и допустимость контакта. Руководство умножило 26 000 записей на историческую конверсию и включило 5 600 замен в прогноз.

Каждая запись пула автоматически создает SQL и назначается продавцу. Demand Episode отсутствует, MQL Standard не применяется, содержательного взаимодействия нет. Большинство объектов закрывается как Клиент не заинтересован; SQL-to-Deal Rate падает до 1,4%.

Повторный и реферальный спрос

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

В реферальной программе владелец сообщает телефон знакомого. Контакт сразу создается как SQL. Referral Record, самостоятельное волеизъявление нового субъекта и надежная атрибуция отсутствуют. Часть людей не знает источник номера, а некоторые сделки приписаны программе, хотя покупатели обращались раньше.

Capacity gaps и конфликт экосистемы

После запуска Replacement Pool нагрузка контакт-центра выросла на 37%. Увеличилось ожидание, обещанные перезвоны нарушаются, onboarding сокращается, жалобы попадают в общую очередь. Сервису не хватает диагностов и деталей.

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

Инвестиционное решение

Совет директоров готов профинансировать только два из пяти проектов:

1. единый Owner Record;
2. расширение сервисной мощности;
3. автоматизацию Replacement Pool;
4. Promise Register и Recovery Workflow;
5. прогнозные CLV и Owner Health Profile.

Коммерческий директор требует Replacement Pool ради быстрых продаж. ИТ предлагает CDP и predictive CLV. Сервис просит мощность. Финансовый директор требует доказать экономику.

Задания и вопросы к кейсу

1. Почему существующее поле Владелец принят не является OWNER_ACCEPTED?
2. Сформируйте минимальный Deal Handoff Package для семейной, корпоративной и кредитной сделки.
3. Постройте модель buyer–owner–user–payer–Product–Ownership Episode.
4. Предложите единую State Model для трех кластеров.
5. Определите outcome onboarding и события первых двенадцати месяцев.
6. Спроектируйте Promise Register для 126 выявленных обещаний.
7. Разделите повторный дефект на Service Episode, Complaint Case и Recovery Plan.
8. Пересоберите паспорт first-service retention.
9. Определите корректные критерии Replacement Pool и момент создания Demand Episode.
10. Спроектируйте нормативный маршрут повторного и реферального спроса.
11. Исправьте расчет CLV и назовите недостающие данные.
12. Свяжите сервисную кампанию с Capacity Required и Capacity Available.
13. Выберите два инвестиционных проекта и обоснуйте последовательность.
14. Определите guardrails пилота.
15. Сформулируйте критерии, после которых решение можно масштабировать.

Чек-лист руководителя

Шкала

• 0 — отсутствует: объект, правило или процесс не определен.
• 1 — фрагментарно: практика зависит от отдельных сотрудников.
• 2 — формализовано: правило описано, но применяется непоследовательно.
• 3 — управляется: стандарт действует, измеряется и имеет владельца.
• 4 — доказательно развивается: эффект проверяется, а стандарт улучшается.

Оценивать следует фактическую практику по выборке Ownership Episodes, а не наличие документа.

1. Самостоятельность контура

Определен ли управление отношениями с клиентом после покупки как отдельный посттранзакционный контур? Свидетельство: утвержденная архитектура и границы. Критический разрыв: да. Оценка: ___ / 4.

2. Владелец управление отношениями с клиентом после покупки

Назначена ли одна роль, отвечающая за результативность контура? Свидетельство: полномочия, ресурсные права и KPI. Критический разрыв: да. Оценка: ___ / 4.

3. Интерфейс с управление продажами

Установлено ли, где заканчивается управление продажами? Свидетельство: Integration Contract и критерии принятия. Критический разрыв: да. Оценка: ___ / 4.

4. Событие OWNER_ACCEPTED

Существует ли доказательное событие принятия владения? Свидетельство: event log, actor, time, evidence. Критический разрыв: да. Оценка: ___ / 4.

5. Deal Handoff Package

Определен ли обязательный состав данных, обещаний, согласий и рисков? Свидетельство: спецификация и заполненные пакеты. Критический разрыв: да. Оценка: ___ / 4.

6. Acceptance и rejection

Может ли получатель отклонить пакет с reason code и сроком исправления? Свидетельство: реальные отклонения и повторные передачи. Оценка: ___ / 4.

7. Identity

Различает ли система субъектов и управляет ли дублями? Свидетельство: Identity ID, matching rules, merge/split audit trail. Критический разрыв: да при массовой недостоверности. Оценка: ___ / 4.

8. Product ID

Есть ли устойчивый идентификатор конкретного продукта? Свидетельство: authoritative source и контроль валидности. Критический разрыв: да. Оценка: ___ / 4.

9. Ownership Episode ID

Имеет ли каждый эпизод самостоятельный ID, начало и состояние? Критический разрыв: да. Оценка: ___ / 4.

10. Роли субъектов

Разделены ли buyer, owner, user, payer, representative и decision-maker? Свидетельство: реальные случаи несовпадения ролей. Критический разрыв: да. Оценка: ___ / 4.

11. Identity–Product–Deal

Можно ли восстановить связь сделки, продукта, субъекта и эпизода? Свидетельство: сквозные ID. Критический разрыв: да. Оценка: ___ / 4.

12. Ownership State Model

Есть ли единая модель состояний и переходов? Свидетельство: state-transition specification. Критический разрыв: да. Оценка: ___ / 4.

13. Entry/Exit Criteria и evidence

Имеет ли каждый переход проверяемое событие и authorized role? Критический разрыв: да для существенных решений. Оценка: ___ / 4.

14. Ownership Plan

Существует ли план milestones и обязательств по эпизоду? Свидетельство: активные планы и статусы. Критический разрыв: да для сложного продукта. Оценка: ___ / 4.

15. Onboarding Outcome

Завершается ли onboarding подтвержденным результатом? Свидетельство: VALUE_CONFIRMED и TTFV. Критический разрыв: да. Оценка: ___ / 4.

16. Promise Register

Есть ли отдельный реестр обещаний? Свидетельство: Promise ID, срок, owner, criterion, evidence. Критический разрыв: да. Оценка: ___ / 4.

17. Владелец обязательства

Отсутствуют ли promises и незавершенные действия без владельца? Критический разрыв: да. Оценка: ___ / 4.

18. Lifecycle milestones

Управляются ли продуктовые, сервисные, финансовые и гарантийные события с учетом контекста? Оценка: ___ / 4.

19. Complaint и root cause

Разделены ли жалоба и обычное обращение, определяется ли причина? Критический разрыв: да при систематическом формальном закрытии. Оценка: ___ / 4.

20. Service Recovery

Существует ли Recovery Plan и отдельная проверка результата? Критический разрыв: да. Оценка: ___ / 4.

21. Retention и churn

Определены ли объект, когорта, окно, competing risks и censoring? Критический разрыв: да при финансовом использовании метрики. Оценка: ___ / 4.

22. Новый Demand Episode

Создается ли новый объект для каждой самостоятельной потребности? Критический разрыв: да. Оценка: ___ / 4.

23. Trigger, signal и demand

Исключено ли автоматическое признание сигнала квалифицированным спросом? Критический разрыв: да. Оценка: ___ / 4.

24. Replacement Pool

Используется ли пул только для проверки гипотезы, а не как pipeline? Критический разрыв: да, если включен в гарантированный forecast. Оценка: ___ / 4.

25. Маршрут MQL–SQL–управление продажами

Проходит ли новый Demand Episode применимые стандарты привлечение лидов и LLM? Критический разрыв: да. Оценка: ___ / 4.

26. Referral Record

Зафиксированы ли самостоятельный отклик новой Identity, основание и атрибуция? Критический разрыв: да при обработке контактов без основания. Оценка: ___ / 4.

27. Consent и purpose limitation

Разделены ли договорные, сервисные, рекламные, телематические и партнерские цели? Критический разрыв: да. Оценка: ___ / 4.

28. Источники истины и интеграции

Назначен ли authoritative source для критических объектов? Есть ли правила конфликтов и audit trail? Критический разрыв: да. Оценка: ___ / 4.

29. Capacity alignment

Согласованы ли объем программ, SLA и доступная мощность? Свидетельство: Workload Ratio и backlog age. Критический разрыв: да при хронической перегрузке. Оценка: ___ / 4.

30. KPI, CLV и инвестиции

Используются ли KPI Tree, Cost-to-Serve, когорты, CLV, Customer Equity, guardrails и causal evaluation? Критический разрыв: да, если LTV равен выручке. Оценка: ___ / 4.

Итоговый индекс

где $s_i$ — оценка критерия от 0 до 4.

• 0–20% — фрагментированное обслуживание;
• 21–40% — учет владения;
• 41–60% — стандартизация;
• 61–75% — межфункциональная оркестрация;
• 76–90% — аналитическое управление;
• 91–100% — доказательно адаптивная система.

Общая сумма не компенсирует критический разрыв:

Критические архитектурные разрывы

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

1. Размытая граница управление отношениями с клиентом после покупки

Проявление. управление отношениями с клиентом после покупки описывается как продолжение управление продажами, как часть операционное управление маркетингом или как переименованный CRM/сервис. Точка начала после OWNER_ACCEPTED не зафиксирована.

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

Минимальное исправление. Утвердить управление отношениями с клиентом после покупки как самостоятельный слой управления после OWNER_ACCEPTED; закрепить его вход, выходы, объекты, роли и интерфейсы с управление продажами, сервисом, финансами и маркетингом.

2. Подмена управление отношениями с клиентом после покупки коммуникационной программой

Проявление. Система сводится к рассылкам, клубу владельцев, акциям и опросам удовлетворенности.

Последствие. Организация умеет говорить с владельцем, но не умеет управлять обещаниями, состоянием продукта, сервисными эпизодами и достижением результата.

Минимальное исправление. Сделать ядром операционную модель владения: Owner Record, Ownership Episode, Ownership Plan, Promise Register, Service Episode и Recovery Plan. Коммуникации должны быть действиями внутри этих объектов, а не заменой системы.

3. Отсутствие формального состояния OWNER_ACCEPTED

Проявление. Факт оплаты, выдачи, активации и принятия пакета смешаны; переход выполняется по свободному комментарию.

Последствие. Начало эпизода владения нельзя доказать, когорты нестабильны, срок onboarding и SLA считаются от разных дат.

Минимальное исправление. Определить событие OWNER_ACCEPTED, authorized role, timestamp, обязательные свидетельства и правила возврата пакета на исправление.

4. Неполный Deal Handoff Package

Проявление. Передаются только контакт и сумма сделки; конфигурация, обещания, ограничения, роли субъектов, согласия и открытые вопросы отсутствуют.

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

Минимальное исправление. Утвердить обязательную схему пакета, валидацию полноты, механизм отклонения с reason code и журнал повторной передачи.

5. Незавершенные обязательства теряют владельца

Проявление. После закрытия сделки задачи продавца закрываются автоматически, хотя установка, документы, аксессуары, обучение или компенсация не выполнены.

Последствие. Обещание остается у клиента, но исчезает из операционной системы.

Минимальное исправление. Мигрировать каждое открытое обязательство в Promise Register только с явным Promise Owner, сроком, критерием исполнения и evidence.

6. Нет устойчивого Owner Record

Проявление. Владелец отождествляется с карточкой CRM, номером телефона или последней сделкой.

Последствие. Дубли, совместное владение, смена контактов и несколько продуктов разрушают историю; коммуникации и расчеты становятся недостоверными.

Минимальное исправление. Ввести отдельный Owner Record, связанный с Identity через управляемые правила matching, merge и split.

7. Нет самостоятельного Ownership Episode

Проявление. Вся история человека хранится в одной карточке без начала, окончания и состояний конкретного владения.

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

Минимальное исправление. Создавать отдельный Ownership Episode ID для каждой связи конкретных субъектов и продукта во времени.

8. Нарушена связь Identity–Product–Deal–Episode

Проявление. Сделка, серийный объект, сервисная история и субъект соединяются вручную или по неуникальному признаку.

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

Минимальное исправление. Закрепить сквозные идентификаторы и правила ссылочной целостности; блокировать существенное действие при неразрешенном конфликте.

9. Смешение ролей субъектов

Проявление. Buyer автоматически считается owner, user, payer и decision-maker.

Последствие. Обещания и сообщения направляются не тому человеку, согласия применяются не к той цели, а выводы о спросе и удержании искажаются.

Минимальное исправление. Моделировать роли раздельно, с периодом действия, основанием и правилами доступа.

10. Дедупликация уничтожает историю

Проявление. При объединении дублей старая запись перезаписывается без журнала происхождения и возможности обратного разделения.

Последствие. Невозможно объяснить решение, восстановить согласие или исправить ложное совпадение.

Минимальное исправление. Использовать reversible merge/split, provenance и audit trail; критические совпадения направлять на ручную верификацию.

11. Новый владелец перезаписывает прежнего

Проявление. При продаже или передаче продукта поле owner меняется, а предыдущий эпизод исчезает.

Последствие. Теряется история ответственности, сервиса, гарантий и влияния на стоимость продукта.

Минимальное исправление. Закрывать старый Ownership Episode и открывать новый, сохраняя временные границы и разрешенные связи между эпизодами.

12. Нет Ownership State Model

Проявление. Статусы создаются командами произвольно и не имеют общей семантики.

Последствие. Один и тот же владелец одновременно считается onboarded, at risk и inactive; автоматизация зависит от названия поля, а не от доказанного состояния.

Минимальное исправление. Утвердить конечный набор состояний, допустимые переходы, входные и выходные критерии, evidence и authorized roles.

13. Переходы происходят без evidence

Проявление. Сотрудник меняет статус по субъективной оценке; фактическое событие и источник данных не сохраняются.

Последствие. KPI можно улучшить административным действием без улучшения результата владельца.

Минимальное исправление. Для каждого существенного перехода определить проверяемое событие, источник, timestamp, confidence и журнал решения.

14. Ownership Plan отсутствует или является списком контактов

Проявление. План содержит даты рассылок, но не milestones, обязательства, риски и ожидаемые результаты.

Последствие. Команда оптимизирует активность вместо прогресса владельца.

Минимальное исправление. Строить план вокруг outcome, value-in-use, обещаний, сервисных событий и контрольных точек; пересматривать его при изменении состояния.

15. Onboarding равен факту отправки сообщения

Проявление. Завершение onboarding фиксируется после письма, звонка или выдачи инструкции.

Последствие. Компания считает процесс успешным, даже если продукт не активирован, ключевая функция не освоена и обещанная ценность не подтверждена.

Минимальное исправление. Завершать onboarding только по evidence результата: activation, first value, подтвержденная компетентность или иной продуктовый критерий.

16. Нет Promise Register

Проявление. Обещания находятся в письмах, заметках и памяти сотрудников.

Последствие. Сроки и условия нельзя контролировать; спор решается по фрагментам коммуникации.

Минимальное исправление. Регистрировать Promise ID, источник, содержание, получателя, Promise Owner, due date, acceptance criterion, статус и evidence исполнения.

17. Завершение задачи подменяет исполнение обещания

Проявление. Внутренняя задача закрыта, хотя владелец не получил обещанный результат.

Последствие. Операционная отчетность выглядит благополучно, а доверие владельца снижается.

Минимальное исправление. Развести task completion и promise fulfillment; второе подтверждать внешним или продуктовым результатом.

18. Service Episode не имеет жизненного цикла

Проявление. Обращения существуют как несвязанные тикеты без контекста продукта, обещания и предыдущих причин.

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

Минимальное исправление. Ввести Service Episode с причиной, приоритетом, SLO, Service Owner, связанными действиями, resolution и проверкой результата.

19. Жалоба закрывается без root cause

Проявление. Кейс закрывают после ответа или компенсации; причина дефекта не классифицирована и не передана владельцу процесса.

Последствие. Организация оплачивает повторение одной и той же ошибки и не меняет upstream-систему.

Минимальное исправление. Разделить complaint handling, recovery и root-cause elimination; установить обязательный feedback loop и контроль эффекта изменения.

20. Ремонт считается восстановлением отношений

Проявление. Техническая неисправность устранена, поэтому Recovery Plan автоматически закрывается.

Последствие. Функция продукта восстановлена, но потеря времени, уверенности и доверия владельца не учтена.

Минимальное исправление. Проверять отдельно technical resolution, компенсацию последствий, понятность объяснения и подтвержденное восстановление доверия.

21. Отсутствие жалобы трактуется как удовлетворенность

Проявление. Молчание считается позитивным сигналом.

Последствие. Тихий уход, снижение использования и нерешенные трудности становятся видимыми слишком поздно.

Минимальное исправление. Соединять поведенческие данные, milestones, сервисные сигналы и осторожные проверки; не делать вывод по отсутствию контакта.

22. Сигнал автоматически объявляется спросом

Проявление. Просмотр страницы, окончание гарантии или рост пробега сразу создает opportunity.

Последствие. Pipeline раздувается, владелец получает неуместное давление, а прогноз теряет смысл.

Минимальное исправление. Хранить trigger как гипотезу; создавать Demand Episode только при наличии самостоятельной потребности и допустимого основания для взаимодействия.

23. Новый спрос не получает Demand Episode ID

Проявление. Повторный интерес добавляют в старую сделку или Owner Record как заметку.

Последствие. Нельзя измерить конверсию, время и источник новой потребности; история решений смешивается.

Минимальное исправление. Для каждой самостоятельной потребности создавать новый Demand Episode, не меняя исходный Ownership Episode.

24. Владелец автоматически становится MQL или SQL

Проявление. Наличие предыдущей покупки заменяет стандарт квалификации.

Последствие. Известность Identity ошибочно принимается за готовность спроса; команды получают низкокачественные передачи.

Минимальное исправление. Пропускать новый эпизод через применимые функции MVC и привлечение лидов до MQL, затем через LLM до SQL и управление продажами до новой сделки.

25. Replacement Pool включается в pipeline

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

Последствие. Forecast завышен, а коммерческое давление начинается до появления намерения.

Минимальное исправление. Держать Replacement Pool как аналитический пул для проверки гипотез; переводить запись в demand flow только по определенному событию и стандарту.

26. Рекомендация считается лидом до отклика новой Identity

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

Последствие. Нарушаются ожидания, privacy и стандарты квалификации; атрибуция стимулирует некачественные контакты.

Минимальное исправление. Вести Referral Record отдельно; новый Demand Episode создавать после допустимого самостоятельного отклика или иного законного основания.

27. Единый флаг согласия

Проявление. Одно поле «согласен» применяется к договорным, сервисным, рекламным, телематическим и партнерским целям.

Последствие. Компания не может доказать purpose limitation, срок и канал; отзыв согласия обрабатывается непоследовательно.

Минимальное исправление. Разделить основания по цели, субъекту, данным, каналу, сроку и источнику; обеспечить отзыв и propagation во все системы.

28. Нет authoritative source и правил конфликтов

Проявление. CRM, ERP, сервисная система и приложение содержат разные значения, а «истина» выбирается вручную.

Последствие. Решения воспроизводятся случайно; исправление в одной системе откатывается следующей синхронизацией.

Минимальное исправление. Назначить authoritative source по атрибутам, правила приоритета и разрешения конфликтов, наблюдаемость интеграций и audit trail.

29. Удержание измеряется без когорт и censoring

Проявление. В одной доле смешаны продукты, возрасты владения и клиенты, для которых период наблюдения еще не закончился.

Последствие. Тренд отражает структуру портфеля, а не изменение удержания.

Минимальное исправление. Определить объект retention, временное окно, когорту, competing risks и правое цензурирование; при необходимости применять survival analysis.

30. LTV равен выручке

Проявление. Сумма продаж называется пожизненной ценностью без маржи, Cost-to-Serve, вероятностей, дисконтирования и риска.

Последствие. Наиболее затратные сегменты могут выглядеть самыми ценными; инвестиции в удержание нельзя сравнить с альтернативами.

Минимальное исправление. Рассчитывать инкрементальный CLV на уровне contribution margin, учитывать CTS, горизонт, discount rate и сценарии; агрегировать до Customer Equity.

31. Все повторные покупки приписываются управление отношениями с клиентом после покупки

Проявление. Любая следующая сделка известного владельца считается результатом программы.

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

Минимальное исправление. Разделять описательную атрибуцию и causal evaluation; использовать holdout, рандомизацию или обоснованный квазиэксперимент.

32. Рост базы не связан с мощностью обслуживания

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

Последствие. SLA деградирует именно в момент роста, а ценность программы уничтожается перегрузкой.

Минимальное исправление. Планировать workload, service rate, backlog age и required capacity по сценариям; ограничивать запуск при нарушении guardrails.

33. SLA измеряет только первый ответ

Проявление. Быстрое автоматическое сообщение засчитывается как соблюдение сервиса.

Последствие. Время до решения и результата растет при формально хорошем KPI.

Минимальное исправление. Разделить first response, time-to-resolution, promise due compliance и outcome confirmation.

34. Эскалация заменяет нормальный процесс

Проявление. Любой сложный кейс решается через руководителя или личные связи.

Последствие. Хороший результат зависит от героизма, а система не масштабируется.

Минимальное исправление. Кодифицировать authority matrix, стандартные сценарии, лимиты компенсаций и learning loop; эскалацию оставить исключением.

35. Обратная связь не меняет upstream-системы

Проявление. Жалобы и сигналы агрегируются в презентации, но требования к продукту, продаже, маркетингу и handoff остаются прежними.

Последствие. управление отношениями с клиентом после покупки становится приемником дефектов без права устранить источник.

Минимальное исправление. Привязать recurring root causes к change owner, сроку, решению, проверке эффекта и обратному подтверждению в управление отношениями с клиентом после покупки.

Порядок устранения разрывов

Исправление следует вести не от самого заметного интерфейса, а от причинной основы:

1. Governance: границы, полномочия, решения и ownership ролей.
2. Objects: Identity, Product, Ownership Episode, Promise, Service Episode, Demand Episode.
3. Execution: state transitions, handoff, onboarding, service, recovery и new-demand routing.
4. Measurement: определения, когорты, CTS, CLV, качество данных и guardrails.
5. Prediction: только после стабилизации объектов и наблюдений.
6. Automation: только для решений с определенными правами, evidence, контролем риска и возможностью остановки.

Если нарушен более ранний слой, инвестиция в более поздний повышает скорость ошибок, а не зрелость системы.

Терминологический словарь

Active Ownership Episode — эпизод владения, который находится в действующем состоянии и не завершен передачей, прекращением, списанием или иной утвержденной причиной.

Authoritative Source — назначенная система или источник, значение которого считается нормативным для конкретного атрибута при конфликте данных.

Behavioral Signal — наблюдаемое действие или изменение поведения, которое может поддерживать гипотезу, но само по себе не доказывает намерение или спрос.

Churn — определенное событие прекращения конкретного отношения или использования в заданном окне; требует явного объекта и правил наблюдения.

Complaint Case — формализованный случай выраженного неудовлетворения, требующий ответа, решения, анализа причины и, при необходимости, восстановления отношений.

Complaint Owner — роль, отвечающая за прохождение жалобы от регистрации до проверенного закрытия и передачи root cause владельцу изменения.

Cost-to-Serve, CTS — полная релевантная стоимость обслуживания владельца, продукта, эпизода или сегмента, включая прямые и распределяемые ресурсы.

Customer Equity — приведенная стоимость совокупности ожидаемых contribution-margin потоков от портфеля отношений с учетом риска, времени и стоимости обслуживания.

Customer Lifetime Value, CLV — ожидаемая приведенная contribution value конкретного отношения или когорты за определенный горизонт при явных предположениях.

Deal Handoff Package — структурированный пакет, передаваемый из управления продажами в управление отношениями с клиентом после покупки при достижении OWNER_ACCEPTED.

Demand Episode — самостоятельный во времени и контексте эпизод потребности, интереса и движения к возможной покупке; новая потребность требует нового ID.

Demand Episode Link — типизированная связь нового спроса с Owner Record, Ownership Episode, trigger, referral или иным допустимым источником контекста.

Fast-track — сокращенный маршрут квалификации нового спроса, допустимый только при заранее определенных evidence и без отмены стандартов MQL и SQL.

First-Pass Recovery — восстановление результата и отношений без повторного открытия, дополнительной эскалации или повторного обращения по той же причине.

Identity — устойчивое представление субъекта с идентификатором, атрибутами, provenance и управляемыми правилами matching, merge и split.

Identity–Product Link — временная типизированная связь субъекта с конкретным продуктом, отражающая роль, основание и период действия.

Incremental CLV — изменение ожидаемого CLV, причинно связанное с рассматриваемым решением относительно обоснованной альтернативы.

Lifecycle Milestone — значимое событие жизненного цикла продукта или владения, для которого определены trigger, контекст, действие и ожидаемый результат.

Lifecycle Trigger — наблюдаемое событие, создающее основание проверить необходимость действия; не тождественно спросу.

управление жизненным циклом лида, LLM — функция квалификации и развития MQL до SQL на основании утвержденного SQL Standard.

Marketing Qualified Lead, MQL — Demand Episode, прошедший стандарт качества привлечения лидов и готовый к обработке LLM.

MQL Standard — проверяемый набор обязательных критериев, evidence и исключений, определяющий переход в MQL.

New Ownership Episode — эпизод владения, создаваемый после новой сделки или законной передачи продукта; он не перезаписывает предыдущий эпизод.

Onboarding — управляемый переход от принятия владельца к первому доказанному результату и способности безопасно получать ценность от продукта.

Onboarding Case — рабочий объект onboarding с владельцем, milestones, обещаниями, рисками, сроками и evidence завершения.

Operational Product — конкретный идентифицируемый экземпляр, подписка, договорное право или иная единица, вокруг которой строится владение.

Opportunity — коммерческий объект управление продажами, созданный после SQL и управляемый до результата сделки.

Outcome Attainment — доказанное достижение результата, ради которого владелец использует продукт в данном контексте.

Owner — субъект в определенной роли и временной связи с продуктом; owner не обязательно совпадает с buyer, user, payer или decision-maker.

OWNER_ACCEPTED — формальное состояние, в котором управление отношениями с клиентом после покупки принял полный и валидный Deal Handoff Package и ответственность за новый эпизод.

Owner Data Quality Index, ODQI — составной показатель пригодности данных владельца и владения для конкретных решений с учетом полноты, точности, актуальности, согласованности и происхождения.

Owner Health Profile — объяснимый набор показателей состояния владения, риска, ценности и качества опыта; не должен сводиться к одному непрозрачному score.

управление отношениями с клиентом после покупки — самостоятельная управленческая система после OWNER_ACCEPTED, отвечающая за обещания, ценность в использовании, сервис, удержание и корректное возвращение нового спроса.

управление отношениями с клиентом после покупки Executive — accountable-роль за архитектуру, экономику, межфункциональные решения, качество данных и результаты управление отношениями с клиентом после покупки.

Owner Record — нормативная запись о владельце, его ролях, связях, разрешениях и активных эпизодах без смешения с конкретной сделкой.

Owner Response — наблюдаемая реакция владельца на действие или событие; отсутствие ответа не является автоматически отрицательным или положительным результатом.

Ownership Episode — ограниченная во времени связь субъектов, продукта и контекста владения с собственным ID, состоянием и историей.

Ownership Plan — актуальный план достижения результата и управления milestones, promises, рисками, сервисными событиями и следующими решениями в эпизоде.

Product — объект предложения или конкретный operational product; уровень определения должен быть указан в каждой метрике и связи.

Promise — явно или неявно принятое обязательство компании перед конкретным субъектом с проверяемым критерием исполнения.

Promise Owner — единственная accountable-роль, обязанная обеспечить исполнение promise или согласованное изменение его условий.

Promise Register — журнал обязательств с Promise ID, источником, содержанием, сроком, владельцем, статусом, критерием и evidence.

Recovery — целенаправленное восстановление результата и отношений после существенного сбоя; не равно только техническому ремонту.

Recovery Owner — accountable-роль за Recovery Plan, межфункциональную координацию и подтверждение результата владельцем.

Recovery Plan — план устранения причины и последствий сбоя, компенсации, коммуникации, контроля сроков и проверки восстановления.

Referral Record — запись о рекомендации, ее источнике, основании, получателе, статусе отклика и правилах атрибуции; не является автоматически лидом.

Referral Demand — новый Demand Episode новой или существующей Identity, возникший через рекомендацию и прошедший применимые стандарты квалификации.

Relationship Owner — роль, отвечающая за целостность Ownership Episode и координацию решений, но не присваивающая ответственность функциональных владельцев.

Replacement Pool — аналитический пул эпизодов с признаками возможной замены продукта; используется для проверки гипотез, а не как готовый pipeline.

Replacement Readiness — оценка вероятности и контекста готовности к замене, которая должна быть объяснима, откалибрована и проверена действием.

Retention — сохранение определенного отношения, продукта, активности или экономической ценности в заданном окне и когорте.

Service Episode — самостоятельный рабочий объект сервисной потребности от открытия до проверенного результата с причиной, приоритетом, SLO и ответственными.

Service Owner — роль, отвечающая за завершение конкретного Service Episode по стандарту результата.

Service Resolution — устранение функциональной потребности, подтвержденное заданным evidence; может не означать полного recovery.

Service-Level Agreement, SLA — договоренность о показателях уровня сервиса, ответственности и последствиях отклонения.

Service-Level Objective, SLO — измеримая целевая граница надежности, времени или качества конкретного сервиса.

Sales Qualified Lead, SQL — Demand Episode, прошедший SQL Standard в LLM и готовый к принятию управление продажами.

SQL Standard — проверяемые критерии потребности, пригодности, роли, времени, evidence и исключений для перехода в SQL.

Survival Function — вероятность того, что определенное событие прекращения не наступит дольше времени $t$; позволяет корректно учитывать неполные наблюдения.

System of Analytics — слой расчета, исследования, экспериментов и моделей, не являющийся сам по себе источником операционной истины.

System of Engagement — слой взаимодействия с владельцем через каналы и интерфейсы в пределах цели, согласия и контекста.

System of Record — система нормативного хранения объекта или атрибута с контролем качества, происхождения и истории.

System of Workflow — слой назначения, исполнения, SLA, эскалации и фиксации рабочих действий.

Time to First Value, TTFV — время от определенной стартовой точки до первого подтвержденного полезного результата.

Time to Outcome Attainment, TTOA — время до достижения целевого результата владения, а не до завершения внутренней задачи.

Time to Resolution, TTR — время от открытия сервисного эпизода до подтвержденного решения по определенному стандарту.

Tracking Standard — правила именования, идентификации, timestamps, источников, атрибуции и качества событий, обеспечивающие сопоставимость данных.

Value-in-Use — ценность, возникающая в процессе использования продукта в контексте владельца, а не содержащаяся автоматически в факте продажи.

Workload Ratio — отношение ожидаемого объема работы к доступной пропускной способности с учетом mix сложности и требуемых навыков.

Практические протоколы эксплуатации управление отношениями с клиентом после покупки

Следующие протоколы переводят модель главы из набора объектов в повторяемую управленческую практику. Они не заменяют локальные регламенты и отраслевые требования. Их задача — задать минимальную логику решения: стартовое событие, обязательные данные, accountable-роль, допустимые действия, evidence завершения и stop rule. Каждый протокол должен быть реализован одновременно в политике, workflow и наблюдаемости. Если правило существует только в презентации, система не может считаться введенной в эксплуатацию.

Протокол 1. Приемка Deal Handoff Package

Процесс начинается не с технической синхронизации карточки, а с события готовности пакета к приемке. управление продажами формирует версионированный Deal Handoff Package и указывает Deal ID, Identity ID, Product ID или временный идентификатор продукта, роли субъектов, конфигурацию, договорные параметры, обещания, согласия, открытые вопросы и evidence завершения коммерческого шага. Пакет получает timestamp и отправителя, чтобы последующее изменение не уничтожило состояние на момент передачи.

Workflow выполняет автоматические проверки. Структурная валидация контролирует наличие обязательных полей и допустимый формат. Семантическая проверка сопоставляет роли, продукт, условия и обещания. Проверка ссылочной целостности подтверждает, что идентификаторы существуют и не находятся в неразрешенном конфликте. Compliance-проверка определяет, можно ли использовать переданные данные для конкретных сервисных и коммуникационных целей. Автоматическая проверка не должна принимать решение там, где требуется содержательная оценка обещания или исключения.

Назначенный Handoff Receiver изучает исключения, открытые обязательства и применимость Ownership Plan. Он может принять пакет, принять с явно разрешенным условием либо отклонить. Условная приемка допустима только для некритичного дефекта, если известны correction owner и due date, а владельцу не причиняется риск. Критическое отсутствие Product ID, основания связи с Identity, обязательного promise или юридически значимого evidence блокирует приемку.

При отклонении фиксируются reason code, описание дефекта, требуемое исправление и срок повторной передачи. Пакет не редактируется принимающей стороной скрытно: иначе ответственность за исходные данные становится неясной. управление продажами выпускает новую версию, сохраняя связь с отклоненной. Метрика First-Pass Acceptance используется вместе с guardrails: высокая доля приемки не является успехом, если receiver перестал замечать дефекты.

Событие OWNER_ACCEPTED возникает только после успешной приемки. Одновременно создаются или активируются Owner Record, Identity–Product Link и Ownership Episode; незавершенные обязательства переходят в Promise Register, а значимые milestones — в Ownership Plan. Idempotency key защищает от повторного создания объектов при техническом повторе сообщения. Если часть объектов не создана, транзакция получает состояние ошибки и попадает в контролируемую очередь, а не считается завершенной.

Ежедневный контроль рассматривает отклоненные и зависшие пакеты, возраст очереди, долю условных приемок и orphan promises. Еженедельный разбор анализирует причины дефектов по источнику и меняет upstream-стандарт. Завершенность протокола доказывается не отчетом об отправленных пакетах, а возможностью восстановить всю цепочку: версия пакета → решение receiver → OWNER_ACCEPTED → созданные объекты → принятые обязательства.

Протокол 2. Запуск и завершение onboarding

Onboarding Case открывается из принятого Ownership Episode, а не из маркетингового списка. На старте система определяет продукт, роли, ограничения, ожидаемый outcome, обязательные действия компании и владельца, доступные каналы и риски. Для сложного продукта следует различать техническую активацию, безопасное начало использования, освоение ключевой функции, first value и устойчивое самостоятельное использование. Один универсальный статус «активирован» скрывает разные причины неуспеха.

План onboarding строится от результата назад. Сначала формулируется наблюдаемый outcome: например, владелец активировал продукт, выполнил критическую настройку и подтвердил способность использовать основную функцию. Затем определяются evidence, необходимые milestones, promises, ответственные и допустимые окна. Контакт является средством: звонок или сообщение включаются только тогда, когда помогают пройти конкретный milestone.

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

TTFV считается от единой стартовой точки, обычно OWNER_ACCEPTED или физической готовности продукта, если это предусмотрено паспортом метрики. Паузы, вызванные согласованным ожиданием владельца, должны быть классифицированы, но не обязательно исключены: исключение меняет смысл показателя. Параллельно измеряются доля достигнутого outcome, число просроченных promises, effort владельца, обращения и Cost-to-Serve.

Onboarding нельзя закрыть на основании отправки материалов или внутренней отметки. Допустимые основания закрытия: подтвержденный outcome, документированный отказ владельца продолжать, объективная невозможность с утвержденным reason code либо переход в сервисный/recovery-процесс. Если возникает неисправность, основной кейс не исчезает: он связывается с Service Episode, а ожидаемый outcome и обещания сохраняются.

После закрытия выполняется короткая проверка качества. Она отвечает, достигнута ли ценность, все ли promises исполнены, корректны ли роли и разрешения, какой следующий milestone, требуется ли обновление Ownership Plan. Выборка кейсов проходит ручной audit. Если высокий completion rate не сопровождается outcome attainment, стандарт закрытия признан дефектным.

Протокол 3. Регистрация и контроль promises

Promise возникает из договора, публичного предложения, слов сотрудника, интерфейса, сервисного решения, программы компенсации или нормативного требования. Организация не вправе считать обещанием только то, что сотрудник вручную назвал promise. Источники должны быть перечислены в governance, а существенные неструктурированные коммуникации — доступны для выявления и подтверждения обязательства.

При регистрации формулировка обещания нормализуется без потери исходного текста. Запись содержит получателя, объект, источник, время, условия, due date, acceptance criterion, Promise Owner, contributors, допустимое изменение и evidence. Если срок или критерий неясны, promise получает статус clarification required, но не исчезает из контроля. Назначение владельца процесса вместо конкретной accountable-роли не считается достаточным.

Изменение promise не выполняется односторонним редактированием. Система сохраняет прежнюю версию, основание изменения, authorized role и, когда требуется, подтверждение получателя. Просрочка определяется по исходно согласованному сроку, а не скрывается переносом due date. Допустимая renegotiation отражается отдельным событием и анализируется как часть качества обещаний.

Ежедневная очередь promise control делится минимум на due soon, overdue, blocked, disputed и evidence pending. Приоритизация учитывает ущерб, уязвимость, договорный риск, зависимость результата и длительность ожидания. Score может рекомендовать порядок, но не отменяет hard rules. Например, обязательство, влияющее на безопасность, всегда имеет приоритет независимо от прогнозируемой стоимости владельца.

Исполнение подтверждается acceptance criterion. Если обещано доставить документ, evidence может быть фактом доступности и получения; если обещано устранить проблему — подтвержденным функциональным результатом; если обещана компенсация — проведенной транзакцией. Внутреннее действие «передано коллегам» не является fulfillment. При споре promise связывается с Complaint Case и сохраняет собственный статус.

На уровне управления анализируется не только доля исполнения в срок. Нужны promise defect rate по источнику, доля promises без owner, повторные переносы, стоимость исполнения, нарушения по этапам и влияние на service/recovery. Root cause может находиться в рекламе, дизайне продукта, скрипте продаж, договоре или capacity. Поэтому Promise Register является одновременно операционным инструментом и датчиком качества всей системы.

Протокол 4. Service Episode, complaint и recovery

Входом является потребность владельца, сигнал продукта, обращение представителя или обнаруженный компанией дефект. На первом шаге определяется Identity, Product, Ownership Episode и характер события. Ошибка идентификации опаснее задержки маршрутизации: действие по чужому продукту может нарушить privacy, гарантию и безопасность. При неполной уверенности создается временная связь с ограниченными правами до верификации.

Service Episode классифицируется по типу, срочности, воздействию и требуемому навыку. Complaint Case создается, когда выражено неудовлетворение или событие соответствует утвержденному критерию жалобы. Recovery Plan требуется, если сбой затронул доверие, значимый outcome, безопасность, существенные затраты времени или повторился. Эти три объекта могут быть связаны, но не заменяют друг друга.

Первичный ответ сообщает, что принято, кто отвечает, какой следующий шаг и когда ждать обновление. Он не должен называться решением. Service Owner координирует диагностику и functional resolution. Complaint Owner обеспечивает справедливое рассмотрение и понятный ответ. Recovery Owner отвечает за последствия и восстановление. В простом случае роли может выполнять один человек, но критерии результатов остаются разными.

В ходе кейса фиксируются действия, evidence, обещания, зависимости, решения и коммуникации. Таймеры SLO должны учитывать не только first response, но и время до диагностики, решения, fulfillment и outcome confirmation. Статус waiting for owner допустим при конкретно запрошенной информации и напоминании; он не должен использоваться для остановки часов без реальной зависимости.

Техническое устранение проверяется на продукте или достоверном заместителе. Complaint Case закрывается после рассмотрения требований и предоставления обоснованного результата. Recovery завершается, когда устранены существенные последствия и получено допустимое подтверждение либо выполнен заранее определенный объективный критерий. Отсутствие ответа после компенсации не доказывает восстановление доверия.

Root cause оформляется на уровне, где возможно изменение. Причина «ошибка сотрудника» недостаточна, если интерфейс допускает ошибку, план мощности провоцирует спешку или обучение не содержит нужного сценария. Change owner принимает действие с due date и метрикой эффекта. После внедрения сравнивается частота повторения в сопоставимых условиях. Только эта связь превращает сервисные данные в улучшение системы.

Протокол 5. Формирование нового Demand Episode

Источником гипотезы могут быть milestone, изменение использования, поиск, вопрос о совместимости, referral, окончание договора, новый контекст или прямое заявление владельца. Система сначала сохраняет trigger и provenance. Она не создает коммерческий статус по одному косвенному сигналу. Для чувствительных данных дополнительно проверяются цель, основание использования и допустимость профилирования.

Создание нового Demand Episode требует самостоятельного предмета потребности, временной границы и минимального evidence. Эпизод получает Demand Episode ID, ссылку на известную Identity, разрешенный контекст Ownership Episode и source classification. Исходный эпизод владения остается неизменным. Если владелец одновременно рассматривает замену и дополнительный продукт для другого пользователя, это могут быть два разных эпизода.

Replacement Pool формируется как аналитическая очередь проверки. Запись содержит причины включения, confidence, окно, допустимое действие и stop rule. Массовое предложение всем участникам пула не является проверкой качества модели. Лучше использовать ступенчатую проверку: нейтральное исследование контекста, явная реакция, затем квалификация. Отрицательная реакция и отсутствие основания прекращают коммерческую ветвь, но не ухудшают право владельца на сервис.

Referral Record отделяет рекомендателя, потенциального нового субъекта, основание контакта и вознаграждение. Передача номера не доказывает согласие получателя. Без допустимого основания организация может предоставить рекомендателю нейтральную ссылку или код, позволяющий новой Identity проявить инициативу. Demand Episode возникает после такого отклика и получает собственную квалификационную историю.

Известный контекст может обеспечить fast-track. Например, подтвержденные Identity и совместимость продукта не проверяются повторно. Но потребность, роль решения, временной горизонт и иные элементы MQL/SQL Standard остаются обязательными. Fast-track — это определенный альтернативный маршрут с evidence, а не право пропустить привлечение лидов или LLM.

Передача нового Demand Episode в MVC сопровождается purpose-bound context: только те данные, которые нужны для соответствующей функции. привлечение лидов формирует MQL. LLM развивает и квалифицирует его до SQL. управление продажами принимает SQL и управляет новой сделкой. управление отношениями с клиентом после покупки получает результат обратно только при новом OWNER_ACCEPTED. Такая дисциплина делает повторный спрос сопоставимым с первичным и сохраняет честность pipeline.

Протокол 6. Identity, роли и качество связей

Identity resolution начинается с определения решения, ради которого требуется совпадение. Для отправки сервисного уведомления и для юридически значимого изменения владельца нужны разные пороги confidence. Универсальный matching score опасен: он либо создает лишние дубли, либо допускает ложные объединения в критических процессах.

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

Автоматическое объединение допускается только выше утвержденного порога и при отсутствии конфликтующих hard signals. Пограничные случаи поступают в stewardship queue. Решение steward содержит основание и использованные evidence. Merge не уничтожает исходные записи; split восстанавливает историю зависимых объектов или создает контролируемую задачу их перераспределения.

Identity–Product Link имеет роль, дату начала, дату окончания, основание и confidence. Передача, совместное владение, корпоративное использование, представитель и временный пользователь моделируются явно. При изменении связи система проверяет, какие доступы, согласия, сервисные права и активные promises должны измениться. Нельзя просто заменить фамилию в поле owner.

Качество оценивается не абстрактной полнотой карточки, а пригодностью к решениям. ODQI должен показывать, какие дефекты блокируют handoff, сервис, коммуникацию или расчет. Например, отсутствие дня рождения может быть нейтральным, а неразрешенный конфликт Product ID — критическим. Вес атрибута зависит от use case и пересматривается governance-форумом.

Контроль включает duplicate rate, false merge, unresolved conflict age, долю связей без основания, долю критических атрибутов без provenance и последствия дефектов. Отдельно измеряется скорость исправления и propagation. Исправленная ошибка, которая сохраняется в engagement-системе, остается операционным дефектом.

Протокол 7. Управление согласиями и целью использования

Архитектура начинается не с флага opt-in, а с карты целей. Договорное исполнение, обязательное сервисное сообщение, безопасность, аналитика, персонализация, реклама, партнерское предложение и телематика имеют разные основания, наборы данных, получателей и сроки. Конкретная правовая квалификация определяется применимым правом и ответственным специалистом, но система должна уметь выразить принятое решение.

Consent Record, когда основанием является согласие, хранит субъекта, цель, текст версии, канал получения, timestamp, срок, охват данных и способ отзыва. Для другого основания фиксируются соответствующий документ и purpose. Согласие одного участника Ownership Episode не распространяется автоматически на другого. Изменение роли также не переносит права без проверки.

Перед действием policy decision point сопоставляет purpose, Identity, канал, данные, юрисдикцию и действующее основание. Решение возвращает allow, deny или review с reason code. Engagement-система не должна копировать аудиторию и использовать ее позднее без повторной проверки: между выборкой и отправкой основание может измениться.

Отзыв распространяется во все системы с контролируемым сроком. При этом отзыв рекламного согласия не должен отключать обязательное сообщение о безопасности, если для него существует иное основание; обратная ошибка столь же опасна. Suppression rules должны быть понятны, версионированы и проверяемы.

Минимизация означает не только удаление лишних полей, но и ограничение контекста конкретной функции. операционное управление маркетингом не обязательно получает детали complaint; сервису не нужен прогноз дохода для устранения дефекта. Доступ выдается по роли и цели, а выгрузка чувствительных данных требует дополнительного контроля.

Аудит выбирает реальные решения и восстанавливает цепочку: какие данные использованы, для какой цели, на каком основании, кем, в каком канале и с каким результатом. Наличие записи о согласии без доказуемой связи с конкретным действием не завершает контроль.

Протокол 8. Метрики и причинная оценка

Каждая метрика получает паспорт до включения в KPI. В нем определяются объект, единица анализа, событие старта, числитель, знаменатель, окно, когорта, exclusions, censoring, источники, допустимая задержка, владелец и ограничения интерпретации. Изменение формулы создает новую версию, а исторический ряд пересчитывается либо явно маркируется как несопоставимый.

Дерево KPI начинается с outcomes владельца и экономики, затем связывает их с операционными драйверами и качеством процесса. Например, снижение TTR может поддерживать recovery, но чрезмерное ускорение способно увеличить reopen rate. Поэтому цель сопровождается guardrails. Нельзя оптимизировать показатель, если команда может улучшить его простой переклассификацией статуса.

Retention требует определить, что именно сохраняется: активный договор, использование, продукт в эпизоде, сервисное отношение или экономическая ценность. Когорты формируются по зрелости наблюдения, типу продукта и существенным условиям. Для незавершенных наблюдений используется censoring; для разных способов завершения — competing risks. Простая доля допустима только при выполненных предпосылках.

CLV строится на contribution margin после Cost-to-Serve, учитывает вероятности, горизонт, стоимость капитала и риск. Сценарии отделяют базовый прогноз от результата конкретной программы. Customer Equity агрегирует совместимые оценки, но не скрывает концентрацию риска и не заменяет анализ распределения.

Чтобы заявить эффект управление отношениями с клиентом после покупки, нужен контрфактический сценарий. Предпочтителен рандомизированный holdout, если он этически и операционно допустим. Иначе используется заранее обоснованный квазиэксперимент: matching, difference-in-differences, regression discontinuity или иной дизайн с проверкой предпосылок. Сравнение участников программы с неучастниками без контроля выбора обычно завышает результат.

Экспериментальный паспорт определяет единицу рандомизации, primary metric, guardrails, минимально значимый эффект, период, правила остановки и анализ неоднородности. Решение принимается не только по статистической значимости, но и по практической величине, стоимости и риску. Нулевой результат сохраняется в реестре знаний: повторять тот же тест под другим названием — потеря организационной памяти.

Протокол 9. Capacity, очереди и управленческий ритм

Портфель управление отношениями с клиентом после покупки создает поток работы: onboarding cases, promises, service episodes, complaints, recovery plans, data conflicts и проверки triggers. Для каждого класса оцениваются arrival rate, mix сложности, service time, требуемый навык и допустимое ожидание. Среднее значение недостаточно: пиковая нагрузка и тяжелый хвост определяют просрочки.

Workload Ratio используется вместе с backlog age и SLO risk. Значение ниже единицы в среднем не гарантирует устойчивость, если ресурсы недоступны в нужный момент или навыки не взаимозаменяемы. План мощности должен учитывать отпуска, обучение, повторную работу, межфункциональные зависимости и время на root-cause changes.

При перегрузке система применяет заранее утвержденные правила. Сначала защищаются безопасность, юридические сроки, уязвимые владельцы и обязательства с высоким ущербом. Затем пересматриваются необязательные кампании и запускаемые программы. Нельзя скрывать дефицит capacity массовым переводом кейсов в waiting status или снижением стандарта evidence.

Ежедневный операционный ритм контролирует исключения: просроченные promises, критические service/recovery cases, отклоненные handoff, неразрешенные identity conflicts и интеграционные сбои. Цель встречи — назначить решение и срок, а не перечитать дашборд. Повторяющийся тип исключения выносится на процессный уровень.

Еженедельный cross-functional review рассматривает причины, capacity и изменения стандартов. Ежемесячный governance review утверждает определения, rights, thresholds, модель данных и портфель гипотез. Квартальный value review связывает outcomes, CTS, CLV, риски и инвестиции. Один и тот же показатель может использоваться на разных ритмах, но вопрос решения должен различаться.

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

Протокол 10. Безопасная автоматизация и остановка

Кандидат на автоматизацию сначала описывается как управленческое решение. Указывается объект, входные данные, authorized role, допустимые действия, цена ошибки, затронутые права, evidence и альтернативный ручной процесс. Если решение нельзя описать без ссылки на «логику модели», оно еще не готово к автоматизации.

Правила и модели разделяются. Hard constraints — согласие, безопасность, юридический запрет, существование объекта, критический конфликт данных — исполняются детерминированно. Модель может ранжировать допустимые действия, но не обходить ограничения. Threshold выбирается по стоимости false positive и false negative, а не по максимальной общей accuracy.

Для каждого решения сохраняются версия модели или правила, признаки, источник данных, output, confidence, примененное действие и результат. Объяснение должно быть пригодно для операционного владельца: какие факторы повлияли и какое действие разрешено. Список технических весов без связи с процессом не обеспечивает accountability.

Guardrails включают жалобы, opt-out, неравномерность воздействия, service load, ошибочную идентификацию и экономические пределы. Мониторинг проверяет drift данных, калибровку, изменение доли действий и downstream outcome. Высокая модельная метрика не компенсирует ухудшение результата владельца.

Stop rule формулируется до запуска. Автоматизация останавливается при потере authoritative source, превышении риска, всплеске жалоб, невалидной версии consent policy, деградации calibration или невозможности восстановить audit trail. Остановка должна быть технически доступна назначенной роли без ожидания разработчика, если риск требует немедленной реакции.

После остановки используется безопасный fallback: ручная очередь, нейтральное сообщение или отсутствие действия в зависимости от ситуации. Нельзя автоматически заменить сломанную персонализацию массовой коммуникацией. Возобновление требует анализа причины, исправления, ограниченного теста и решения owner. Так автоматизация остается инструментом управляемой системы, а не источником автономной ответственности.

Протокол 11. Аудит эпизода и трассировка решения

Аудит управление отношениями с клиентом после покупки проводится не только по агрегированной отчетности. Базовой единицей проверки является сквозной след конкретного эпизода: от Deal Handoff Package и OWNER_ACCEPTED до outcomes, promises, service/recovery и, если возникла новая потребность, Demand Episode. Выборка должна включать обычные кейсы, исключения, молчащих владельцев, сложные ролевые структуры, повторные обращения и эпизоды с отрицательным результатом. Проверка только «лучших историй» оценивает презентацию, а не систему.

Аудитор начинает с независимого восстановления хронологии. Для каждого существенного события он проверяет timestamp, actor, source, version и evidence. Затем сопоставляет фактическое действие с действовавшим на тот момент правилом. Текущая версия политики не должна задним числом использоваться для оправдания старого решения. Если система хранит только последнее состояние, доказательная трасса считается утраченной.

По Deal Handoff проверяются полнота пакета, решение receiver и перенос promises. По Identity — основание совпадения, роли и история merge/split. По Ownership Plan — связь действий с outcome, а не только наличие активностей. По Service Episode — различие первого ответа, resolution и recovery. По новому спросу — наличие самостоятельного Demand Episode ID и прохождение применимых MQL/SQL-стандартов.

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

Каждое замечание классифицируется как единичная ошибка исполнения, системный дефект данных, дефект правила, дефицит capacity или governance gap. Класс определяет владельца коррекции. Нельзя закрывать системный дефект повторным инструктажем одного сотрудника. Корректирующее действие содержит due date, критерий, затронутые объекты и способ проверки на новой выборке.

Финальный отчет аудита показывает не только число нарушений, но и их возможный ущерб: неверная Identity, потерянное promise, пропущенный критический milestone, незаконное действие, искаженный KPI или ложный Demand Episode. Критические случаи инициируют stop rule. Повторный аудит проверяет изменение причины, а не механическое наличие закрывающей задачи.

Протокол 12. Поэтапный ввод системы в эксплуатацию

Первый этап — архитектурное решение. Руководство утверждает границы управление отношениями с клиентом после покупки, точку OWNER_ACCEPTED, accountable-роли, минимальные объекты и перечень критических разрывов. На этом этапе полезно взять реальные эпизоды и попытаться восстановить их в предлагаемой модели. Если модель не объясняет передачу продукта, несовпадение buyer и user, устное обещание или повторный спрос, она еще не готова к реализации.

Второй этап — минимальная доказательная версия. Организация реализует Deal Handoff Package, Owner Record, Ownership Episode, Promise Register и базовый Ownership Plan для ограниченного продукта или региона. Цель пилота — проверить целостность объектов, переходов и ответственности. Количество автоматизированных сообщений не является критерием успеха. Основные показатели — acceptance quality, orphan rate, подтвержденный onboarding outcome и возможность восстановить audit trail.

Третий этап расширяет исполнение: lifecycle milestones, Service Episode, Complaint Case и Recovery Plan. Перед масштабированием проводится capacity test. Команда моделирует нормальную и пиковую нагрузку, проверяет очереди, эскалации, полномочия и fallback. Если пилот работает только благодаря ежедневному ручному вмешательству руководителя, необходимо превратить эти вмешательства в правила либо признать ограничение мощности.

Четвертый этап замыкает новый спрос. Сначала вводятся Trigger Record, Replacement Pool и Referral Record как наблюдаемые гипотезы. Затем создается Demand Episode Link и проверяется маршрут через применимые функции MVC, привлечение лидов, MQL, LLM, SQL и управление продажами. Пилот должен доказать, что новый контекст повышает качество решения, не раздувая pipeline и не ухудшая privacy guardrails.

Пятый этап вводит экономику и эксперименты. Метрики получают паспорта, когорты и владельцев; CTS связывается с рабочими объектами; CLV рассчитывается в сценариях. Для ключевых вмешательств резервируется holdout или выбирается обоснованный квазиэксперимент. Только после стабилизации входных данных результат используется для перераспределения бюджета.

Шестой этап допускает прогнозирование и автоматизацию. Каждая модель проходит offline validation, ограниченный shadow mode, controlled launch и постконтроль. В shadow mode рекомендация рассчитывается, но не исполняется, что позволяет сравнить ее с решениями и выявить скрытые ограничения. Controlled launch ограничивает аудиторию, действия и период; при нарушении guardrail действует заранее проверенный stop rule.

Масштабирование выполняется волнами, каждая из которых имеет entry criteria и exit criteria. Entry criteria подтверждают готовность данных, ролей, capacity, интеграций и правовых решений. Exit criteria требуют стабильности outcomes, качества и экономики в заданном периоде. Переход к следующей волне не должен основываться на календарной дате, если критический разрыв остается открытым.

Через 90–180 дней после каждой волны проводится benefits review. Он сравнивает фактический результат с базовой линией, учитывает внешние изменения и проверяет непредвиденные эффекты: рост нагрузки, исключение отдельных групп, увеличение жалоб, перенос затрат или падение качества квалификации. Неиспользуемый объект, дублирующая метрика или неработающее правило удаляются через контролируемое изменение, а не сохраняются ради полноты схемы.

Ввод завершен не тогда, когда программное обеспечение доступно всем пользователям, а когда организация воспроизводимо принимает эпизоды, исполняет promises, подтверждает outcomes, устраняет причины сбоев, корректно возвращает новый спрос и умеет показать инкрементальную экономику. До этого момента следует говорить о стадии внедрения, сохраняя видимость ограничений и незавершенных решений.

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

Библиография и доказательная база

Библиография разделена на четыре группы. Это позволяет различать учебные издания, первичные исследования, нормативные требования и профессиональные модели. Упоминание источника не означает механического переноса его терминологии в архитектуру главы: MOS, MVC, LLM, управление продажами и управление отношениями с клиентом после покупки сохраняют определения, данные в настоящей книге.

Русскоязычные издания

1. Блэттберг Р., Гетц Г., Томас Дж. Клиентский капитал: управление взаимоотношениями с клиентами с целью увеличения стоимости компании. М.: Гребенников, 2005.
2. Гембл П., Стоун М., Вудкок Н. Маркетинг взаимоотношений с потребителями. М.: ФАИР-ПРЕСС, 2002.
3. Диксон М., Томан Н., Делиси Р. Всегда ваш клиент: как добиться лояльности, решая проблемы клиентов за один шаг. М.: Альпина Паблишер, 2015.
4. Котлер Ф., Келлер К. Л. Маркетинг менеджмент. 15-е изд. СПб.: Питер, 2018.
5. Кристенсен К., Холл Т., Диллон К., Данкан Д. Закон успешных инноваций: зачем клиент нанимает ваш продукт и как знание об этом помогает новым разработкам. М.: Альпина Паблишер, 2017.
6. Пайн Б. Дж., Гилмор Дж. Х. Экономика впечатлений: как превратить покупку в захватывающее действие. М.: Альпина Паблишер, 2018.
7. Пепперс Д., Роджерс М. Управление отношениями с клиентами: как превратить базу ваших клиентов в деньги. М.: Манн, Иванов и Фербер, 2006.
8. Прахалад К. К., Рамасвами В. Будущее конкуренции: создание уникальной ценности вместе с потребителями. М.: Олимп-Бизнес, 2006.
9. Райхельд Ф. Эффект лояльности: движущие силы экономического роста, прибыли и непреходящей ценности. М.: Вильямс, 2005.
10. Сьюэлл К., Браун П. Клиенты на всю жизнь. М.: Манн, Иванов и Фербер, 2019.
11. Шмитт Б. Клиентский опыт: как заставить клиента почувствовать, думать, действовать, а также соотносить себя с вашей компанией. М.: Эксмо, 2008.
12. Шоул Дж. Первоклассный сервис как конкурентное преимущество. М.: Альпина Паблишер, 2017.

Англоязычные монографии и учебные источники

1. Allison, P. D. Survival Analysis Using SAS: A Practical Guide. 2nd ed. SAS Institute, 2010.
2. Blattberg, R. C., Getz, G., Thomas, J. S. Customer Equity: Building and Managing Relationships as Valuable Assets. Harvard Business School Press, 2001.
3. Buttle, F., Maklan, S. Customer Relationship Management: Concepts and Technologies. 4th ed. Routledge, 2019.
4. Cox, D. R., Oakes, D. Analysis of Survival Data. Chapman and Hall, 1984.
5. Fader, P. S. Customer Centricity: Focus on the Right Customers for Strategic Advantage. 2nd ed. Wharton School Press, 2020.
6. Grönroos, C. Service Management and Marketing: Customer Management in Service Competition. 3rd ed. Wiley, 2007.
7. Gummesson, E. Total Relationship Marketing. 3rd ed. Butterworth-Heinemann, 2008.
8. Gupta, S., Lehmann, D. R. Managing Customers as Investments: The Strategic Value of Customers in the Long Run. Wharton School Publishing, 2005.
9. Hernán, M. A., Robins, J. M. Causal Inference: What If. Chapman & Hall/CRC, 2020.
10. Heskett, J. L., Sasser, W. E., Schlesinger, L. A. The Service Profit Chain. Free Press, 1997.
11. Imbens, G. W., Rubin, D. B. Causal Inference for Statistics, Social, and Biomedical Sciences. Cambridge University Press, 2015.
12. Klein, J. P., Moeschberger, M. L. Survival Analysis: Techniques for Censored and Truncated Data. 2nd ed. Springer, 2003.
13. Kohavi, R., Tang, D., Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020.
14. Kumar, V., Reinartz, W. Customer Relationship Management: Concept, Strategy, and Tools. 3rd ed. Springer, 2018.
15. Lovelock, C., Wirtz, J. Services Marketing: People, Technology, Strategy. 8th ed. World Scientific, 2016.
16. Palmatier, R. W. Relationship Marketing. Marketing Science Institute, 2008.
17. Payne, A. Handbook of CRM: Achieving Excellence in Customer Management. Butterworth-Heinemann, 2005.
18. Pearl, J. Causality: Models, Reasoning, and Inference. 2nd ed. Cambridge University Press, 2009.
19. Provost, F., Fawcett, T. Data Science for Business. O’Reilly Media, 2013.
20. Redman, T. C. Data Driven: Profiting from Your Most Important Business Asset. Harvard Business Press, 2008.
21. Reichheld, F. F. The Loyalty Effect. Harvard Business School Press, 1996.
22. Rust, R. T., Zeithaml, V. A., Lemon, K. N. Driving Customer Equity: How Customer Lifetime Value Is Reshaping Corporate Strategy. Free Press, 2000.
23. Vargo, S. L., Lusch, R. F., eds. The SAGE Handbook of Service-Dominant Logic. SAGE, 2018.
24. Wang, R. Y., Ziad, M., Lee, Y. W. Data Quality. Kluwer Academic Publishers, 2001.
25. Zeithaml, V. A., Bitner, M. J., Gremler, D. D. Services Marketing: Integrating Customer Focus Across the Firm. 7th ed. McGraw-Hill, 2018.

Научные статьи

1. Anderson, E. W., Sullivan, M. W. “The Antecedents and Consequences of Customer Satisfaction for Firms.” Marketing Science, 1993, 12(2), 125–143. DOI: 10.1287/mksc.12.2.125.
2. Becker, L., Jaakkola, E. “Customer Experience: Fundamental Premises and Implications for Research.” Journal of the Academy of Marketing Science, 2020, 48, 630–648. DOI: 10.1007/s11747-019-00718-x.
3. Bolton, R. N. “A Dynamic Model of the Duration of the Customer’s Relationship with a Continuous Service Provider.” Marketing Science, 1998, 17(1), 45–65. DOI: 10.1287/mksc.17.1.45.
4. Brodie, R. J., Hollebeek, L. D., Jurić, B., Ilić, A. “Customer Engagement: Conceptual Domain, Fundamental Propositions, and Implications for Research.” Journal of Service Research, 2011, 14(3), 252–271. DOI: 10.1177/1094670511411703.
5. Cayirli, T., Veral, E. “Outpatient Scheduling in Health Care: A Review of Literature.” Production and Operations Management, 2003, 12(4), 519–549. DOI: 10.1111/j.1937-5956.2003.tb00218.x.
6. Cronin, J. J., Taylor, S. A. “Measuring Service Quality: A Reexamination and Extension.” Journal of Marketing, 1992, 56(3), 55–68. DOI: 10.1177/002224299205600304.
7. Davis, M. M., Rigaux, B. P. “Perception of Marital Roles in Decision Processes.” Journal of Consumer Research, 1974, 1(1), 51–62. DOI: 10.1086/208581.
8. Dick, A. S., Basu, K. “Customer Loyalty: Toward an Integrated Conceptual Framework.” Journal of the Academy of Marketing Science, 1994, 22, 99–113. DOI: 10.1177/0092070394222001.
9. Fader, P. S., Hardie, B. G. S., Lee, K. L. “Counting Your Customers the Easy Way: An Alternative to the Pareto/NBD Model.” Marketing Science, 2005, 24(2), 275–284. DOI: 10.1287/mksc.1040.0098.
10. Fellegi, I. P., Sunter, A. B. “A Theory for Record Linkage.” Journal of the American Statistical Association, 1969, 64(328), 1183–1210. DOI: 10.1080/01621459.1969.10501049.
11. Fornell, C. “A National Customer Satisfaction Barometer: The Swedish Experience.” Journal of Marketing, 1992, 56(1), 6–21. DOI: 10.1177/002224299205600103.
12. Grönroos, C., Voima, P. “Critical Service Logic: Making Sense of Value Creation and Co-Creation.” Journal of the Academy of Marketing Science, 2013, 41, 133–150. DOI: 10.1007/s11747-012-0308-3.
13. Gupta, S., Lehmann, D. R., Stuart, J. A. “Valuing Customers.” Journal of Marketing Research, 2004, 41(1), 7–18. DOI: 10.1509/jmkr.41.1.7.25084.
14. Holland, P. W. “Statistics and Causal Inference.” Journal of the American Statistical Association, 1986, 81(396), 945–960. DOI: 10.1080/01621459.1986.10478354.
15. Keaveney, S. M. “Customer Switching Behavior in Service Industries: An Exploratory Study.” Journal of Marketing, 1995, 59(2), 71–82. DOI: 10.1177/002224299505900206.
16. Kohavi, R., Deng, A., Frasca, B., Walker, T., Xu, Y., Pohlmann, N. “Online Controlled Experiments at Large Scale.” KDD, 2013. DOI: 10.1145/2487575.2488217.
17. Lemon, K. N., Verhoef, P. C. “Understanding Customer Experience Throughout the Customer Journey.” Journal of Marketing, 2016, 80(6), 69–96. DOI: 10.1509/jm.15.0420.
18. Libai, B., Bolton, R., Bügel, M. S., de Ruyter, K., Götz, O., Risselada, H., Stephen, A. T. “Customer-to-Customer Interactions: Broadening the Scope of Word of Mouth Research.” Journal of Service Research, 2010, 13(3), 267–282. DOI: 10.1177/1094670510375600.
19. Little, J. D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961, 9(3), 383–387. DOI: 10.1287/opre.9.3.383.
20. Maxham, J. G., Netemeyer, R. G. “A Longitudinal Study of Complaining Customers’ Evaluations of Multiple Service Failures and Recovery Efforts.” Journal of Marketing, 2002, 66(4), 57–71. DOI: 10.1509/jmkg.66.4.57.18512.
21. McColl-Kennedy, J. R., Sparks, B. A. “Application of Fairness Theory to Service Failures and Service Recovery.” Journal of Service Research, 2003, 5(3), 251–266. DOI: 10.1177/1094670502238918.
22. Morgan, R. M., Hunt, S. D. “The Commitment-Trust Theory of Relationship Marketing.” Journal of Marketing, 1994, 58(3), 20–38. DOI: 10.1177/002224299405800302.
23. Oliver, R. L. “Whence Consumer Loyalty?” Journal of Marketing, 1999, 63, 33–44. DOI: 10.1177/00222429990634s105.
24. Palmatier, R. W., Dant, R. P., Grewal, D., Evans, K. R. “Factors Influencing the Effectiveness of Relationship Marketing: A Meta-Analysis.” Journal of Marketing, 2006, 70(4), 136–153. DOI: 10.1509/jmkg.70.4.136.
25. Parasuraman, A., Zeithaml, V. A., Berry, L. L. “SERVQUAL: A Multiple-Item Scale for Measuring Consumer Perceptions of Service Quality.” Journal of Retailing, 1988, 64(1), 12–40.
26. Patricio, L., Fisk, R. P., Falcão e Cunha, J., Constantine, L. “Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting.” Journal of Service Research, 2011, 14(2), 180–200. DOI: 10.1177/1094670511401901.
27. Reinartz, W. J., Krafft, M., Hoyer, W. D. “The Customer Relationship Management Process: Its Measurement and Impact on Performance.” Journal of Marketing Research, 2004, 41(3), 293–305. DOI: 10.1509/jmkr.41.3.293.35991.
28. Reinartz, W. J., Kumar, V. “On the Profitability of Long-Life Customers in a Noncontractual Setting.” Journal of Marketing, 2000, 64(4), 17–35. DOI: 10.1509/jmkg.64.4.17.18077.
29. Reichheld, F. F. “The One Number You Need to Grow.” Harvard Business Review, 2003, 81(12), 46–54.
30. Rust, R. T., Lemon, K. N., Zeithaml, V. A. “Return on Marketing: Using Customer Equity to Focus маркетинговая стратегия.” Journal of Marketing, 2004, 68(1), 109–127. DOI: 10.1509/jmkg.68.1.109.24030.
31. Smith, A. K., Bolton, R. N., Wagner, J. “A Model of Customer Satisfaction with Service Encounters Involving Failure and Recovery.” Journal of Marketing Research, 1999, 36(3), 356–372. DOI: 10.1177/002224379903600305.
32. Tax, S. S., Brown, S. W., Chandrashekaran, M. “Customer Evaluations of Service Complaint Experiences: Implications for Relationship Marketing.” Journal of Marketing, 1998, 62(2), 60–76. DOI: 10.1177/002224299806200205.
33. van Doorn, J., Lemon, K. N., Mittal, V., Nass, S., Pick, D., Pirner, P., Verhoef, P. C. “Customer Engagement Behavior: Theoretical Foundations and Research Directions.” Journal of Service Research, 2010, 13(3), 253–266. DOI: 10.1177/1094670510375599.
34. Vargo, S. L., Lusch, R. F. “Evolving to a New Dominant Logic for Marketing.” Journal of Marketing, 2004, 68(1), 1–17. DOI: 10.1509/jmkg.68.1.1.24036.
35. Vargo, S. L., Lusch, R. F. “Service-Dominant Logic: Continuing the Evolution.” Journal of the Academy of Marketing Science, 2008, 36, 1–10. DOI: 10.1007/s11747-007-0069-6.
36. Vargo, S. L., Lusch, R. F. “Institutions and Axioms: An Extension and Update of Service-Dominant Logic.” Journal of the Academy of Marketing Science, 2016, 44, 5–23. DOI: 10.1007/s11747-015-0456-3.
37. Verhoef, P. C., Lemon, K. N., Parasuraman, A., Roggeveen, A., Tsiros, M., Schlesinger, L. A. “Customer Experience Creation: Determinants, Dynamics and Management Strategies.” Journal of Retailing, 2009, 85(1), 31–41. DOI: 10.1016/j.jretai.2008.11.001.
38. Villanueva, J., Yoo, S., Hanssens, D. M. “The Impact of Marketing-Induced versus Word-of-Mouth Customer Acquisition on Customer Equity Growth.” Journal of Marketing Research, 2008, 45(1), 48–59. DOI: 10.1509/jmkr.45.1.48.
39. Wang, R. Y., Strong, D. M. “Beyond Accuracy: What Data Quality Means to Data Consumers.” Journal of Management Information Systems, 1996, 12(4), 5–33. DOI: 10.1080/07421222.1996.11518099.

Стандарты, право и профессиональные модели

1. ISO 9001:2015. Quality management systems — Requirements.
2. ISO 10001:2018. Quality management — Customer satisfaction — Guidelines for codes of conduct for organizations.
3. ISO 10002:2018. Quality management — Customer satisfaction — Guidelines for complaints handling in organizations.
4. ISO 10003:2018. Quality management — Customer satisfaction — Guidelines for dispute resolution external to organizations.
5. ISO 10004:2018. Quality management — Customer satisfaction — Guidelines for monitoring and measuring.
6. ISO 23592:2021. Service excellence — Principles and model.
7. ISO 22458:2022. Consumer vulnerability — Requirements and guidelines for the design and delivery of inclusive service.
8. ISO/IEC 27001:2022. Information security management systems — Requirements.
9. ISO/IEC 27701. Privacy information management systems.
10. ISO 8000-61:2016. Data quality — Part 61: Data quality management — Process reference model.
11. ISO/IEC 25012:2008. Software engineering — Software product Quality Requirements and Evaluation — Data quality model.
12. ISO 31000:2018. Risk management — Guidelines.
13. ГОСТ Р ИСО 9001-2015. Системы менеджмента качества. Требования.
14. ГОСТ Р ИСО 10002-2020. Менеджмент качества. Удовлетворенность потребителей. Руководящие указания по управлению претензиями в организациях.
15. ГОСТ Р ИСО 10003-2020. Менеджмент качества. Удовлетворенность потребителей. Руководящие указания по урегулированию спорных вопросов вне организации.
16. Закон РФ от 07.02.1992 № 2300-1 «О защите прав потребителей».
17. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
18. Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе».
19. Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
20. Федеральный закон от 07.07.2003 № 126-ФЗ «О связи».
21. Федеральный закон от 21.12.2013 № 353-ФЗ «О потребительском кредите (займе)».
22. Закон РФ от 27.11.1992 № 4015-1 «Об организации страхового дела в Российской Федерации».
23. Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи».
24. Гражданский кодекс Российской Федерации.
25. Постановление Правительства РФ от 31.12.2020 № 2463 о правилах продажи товаров по договору розничной купли-продажи.
26. International Chamber of Commerce. ICC Advertising and Marketing Communications Code.
27. ICC/ESOMAR. International Code on Market, Opinion and Social Research and Data Analytics.
28. GS1. General Specifications и модели глобальной идентификации продуктов, мест и логистических единиц.
29. W3C Data Privacy Vocabularies and Controls Community Group. Data Privacy Vocabulary (DPV).
30. National Institute of Standards and Technology. NIST Privacy Framework.
31. National Institute of Standards and Technology. AI Risk Management Framework (AI RMF 1.0).
32. OECD. Recommendation of the Council on Consumer Protection in E-commerce.
33. IAB Europe. Transparency & Consent Framework — профессиональная модель для цифровых рекламных экосистем; применимость требует отдельной правовой оценки.

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

Заключение: замыкание нового цикла спроса

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

Правильная граница принципиальна. До OWNER_ACCEPTED управление продажами отвечает за движение SQL к сделке. После OWNER_ACCEPTED управление отношениями с клиентом после покупки принимает валидный Deal Handoff Package и начинает самостоятельную ответственность. При этом ни маркетинг, ни продажи, ни сервис не исчезают: они становятся поставщиками и получателями четко определенных объектов и решений.

Полный контур имеет следующий вид:

В этом контуре MOS сохраняет точную последовательность маркетинговая стратегия → управление маркетингом → операционное управление маркетингом. Внутри согласованной модели создания маркетинговой ценности MVC содержит ровно четыре функции: создание бренда, стимулирование спроса, коммерческое присутствие и привлечение лидов. Выход привлечения лидов — MQL. LLM переводит MQL в SQL. управление продажами переводит SQL в сделку и завершает свою часть в точке OWNER_ACCEPTED. Управление отношениями с клиентом после покупки начинается после нее и не является пятой функцией MVC, модулем операционное управление маркетингом или последним этапом продаж.

Вторая принципиальная граница относится к повторному спросу. Сервисный сигнал, окончание гарантии, рост использования, изменение состава семьи, рекомендация или интерес к новому продукту не должны коротким путем превращаться в сделку. Сначала организация определяет, возникла ли самостоятельная потребность. Если да, создается новый Demand Episode с собственным ID, контекстом и evidence. Затем эпизод возвращается через применимые функции MVC, включая привлечение лидов до MQL, проходит LLM до SQL и только после этого поступает в управление продажами.

Такой возврат не является кругом, в котором система приходит в исходную точку без изменений. Это спираль. Новый Demand Episode несет проверенный контекст предыдущего владения: роли, продукт, исполненные и нарушенные promises, достигнутые outcomes, сервисную историю, разрешения и признаки готовности. Контекст сокращает неопределенность, но не отменяет квалификацию. Известный владелец может пройти часть проверок быстрее, однако не получает MQL или SQL только за факт предыдущей покупки.

Практическое значение этой логики видно в четырех результатах.

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

Во-вторых, ценность становится наблюдаемой в использовании. Продажа подтверждает обмен, но не доказывает достижение результата. Onboarding, TTFV, TTOA, milestones и Owner Health Profile помогают видеть, способен ли владелец получить ожидаемую пользу и какие препятствия требуют вмешательства.

В-третьих, сервис превращается в источник организационного обучения. Complaint Case и Service Episode не заканчиваются формальным ответом. Root cause получает change owner, исправление проверяется, а результат возвращается в стандарты продукта, маркетинга, продажи, handoff и операций. Без этого управление отношениями с клиентом после покупки лишь принимает дефекты, созданные выше по потоку.

В-четвертых, экономика отделяется от удобных прокси. Удовлетворенность, активность и выручка важны, но ни один из этих показателей не равен ценности отношений. Управленческое решение требует Cost-to-Serve, contribution margin, retention по когортам, CLV, Customer Equity, guardrails и, когда заявляется эффект программы, причинной оценки.

Зрелая система поэтому строится в строгой последовательности. Сначала организация определяет governance, границы и полномочия. Затем стабилизирует объекты и источники истины. После этого проектирует состояния, handoff, promises, onboarding, service, recovery и маршрут нового спроса. Далее вводит определения метрик, когорты, экономику и контроль качества данных. Только на этой основе оправданы прогнозные модели и автоматические решения.

Автоматизация не должна устранять ответственность. Любая модель, рекомендация или триггер обязаны иметь decision owner, допустимое действие, основание, объяснение, guardrail, журнал и stop rule. Если система не способна показать, почему владельцу назначено действие и кто отвечает за его последствия, автоматизация преждевременна независимо от точности модели на исторической выборке.

Финальная формула главы может быть записана как последовательность управляемых преобразований:

После этого новый Demand Episode не «принадлежит» управление отношениями с клиентом после покупки до сделки. Он возвращается в согласованную архитектуру спроса:

Если результатом становится новая сделка, управление отношениями с клиентом после покупки принимает новый Deal Handoff Package и открывает новый Ownership Episode. Старый эпизод не стирается: он сохраняет историческую правду и становится частью разрешенного контекста. Так образуется управляемая спираль, в которой каждая итерация способна повышать качество решения, но не отменяет стандартов следующего перехода.

Финальная управленческая проверка

Перед утверждением модели руководитель должен уметь дать доказательный ответ на семь вопросов:

1. Где проходит формальная граница между управление продажами и управление отношениями с клиентом после покупки?
2. Можно ли восстановить связь Identity, Product, Deal и Ownership Episode без ручной догадки?
3. Существуют ли обещания, сервисные события или переходы состояния без accountable owner и evidence?
4. Завершается ли onboarding результатом владельца, а recovery — восстановлением, а не только закрытием задачи?
5. Может ли новый спрос получить самостоятельный Demand Episode и пройти MQL–SQL–управление продажами без архитектурного короткого замыкания?
6. Отличает ли экономика выручку от contribution value, а корреляцию — от причинного эффекта?
7. Может ли организация остановить автоматическое действие, объяснить решение и восстановить историю данных?

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