Alakris — Customer Journey 2026

Версия	v1.0
Дата	2026-07-12
Статус	APPROVED — опубликовано 2026-07-12
Контракт	MKT-030-10 (PARENT: MKT-030)
Ссылается на	Sales Playbook (MKT-030-4), Demo Playbook (MKT-030-5), Pricing Book (MKT-030-3), AI Employee Catalog (MKT-030-1)
Принцип	ChurnZero: «someone always owns the moment» — у каждого перехода между этапами явный owner и триггер, иначе клиент «проваливается» между этапами.

---

Как устроен этот документ

Путь клиента разветвляется на два трека после этапа «Лид»: self-service (Lite/Self-Service/Managed — без участия sales на входе) и enterprise (добавляет ручные Demo + квалификацию перед оплатой). Каждый этап описан 4 обязательными полями: Owner, Expected outcome (критерии входа/выхода), KPI, Automation trigger (событие, запускающее переход к следующему этапу).

Реальные конверсии между этапами берутся из Brain CLI / CRM-объектов (Opportunity/Offer/Payment) — этот документ не создаёт отдельную систему учёта, только описывает маршрут.

---

Этап 1 — Лид

• Owner: Алекс (AI-консультант на сайте) для входящих через виджет; Игорь (AI-специалист по холодным продажам) для исходящих кампаний; sales-менеджер для реферальных/партнёрских лидов.
• Expected outcome: контакт зафиксирован в CRM (Марина, AI-менеджер по продажам) с минимальным набором данных — источник, канал, первый вопрос/интерес.
• KPI: количество новых лидов/мес по каналу, доля лидов с валидным контактом.
• Automation trigger: новое сообщение в виджет-чате ИЛИ ответ на исходящую кампанию Игоря → автоматическое создание записи лида в CRM (см. widget_chat.py::_create_lead_and_notify — реальный, работающий в проде триггер, не гипотетический).

Разветвление после этого этапа

• Self-service путь: Диагностика → Оплата (без Demo/Qualification вручную) — Lite/Self-Service/Managed продаются продукт-driven, без sales-touch.
• Enterprise путь: Диагностика → Демонстрация → Выбор тарифа (custom quote) → Оплата — с ручным участием sales.

---

Этап 2 — Диагностика

(Self-service и Enterprise — общий этап, разное наполнение)

• Owner (self-service): сам продукт — короткий diagnostic-flow в рамках conversational-онбординга (ниже, этап 6) фактически совмещён с началом онбординга, отдельного шага sales здесь нет.
• Owner (enterprise): sales-менеджер, discovery-call (Sales Playbook, раздел 2).
• Expected outcome: для enterprise — MEDDPICC-lite закрыт (Sales Playbook, раздел 2.2), понятен рекомендуемый тир (Qualification Guide, MKT-030-6). Для self-service — клиент сам понимает, какой тир ему подходит, ориентируясь на Pricing Book.
• KPI: доля лидов, прошедших квалификацию (SQL-конверсия) — для enterprise-трека.
• Automation trigger: для enterprise — назначенный discovery-звонок в CRM запускает таймер до следующего этапа (Demo в течение 3 рабочих дней, Sales Playbook раздел 1).

---

Этап 3 — Демонстрация (только Enterprise-путь)

• Owner: sales-менеджер, по сценарию Demo Playbook (MKT-030-5).
• Expected outcome: клиент увидел платформу через призму своей боли (этапы 3–6 Demo Playbook), тир подтверждён (не переопределён заново).
• KPI: demo-to-proposal conversion (доля демо, завершившихся отправкой предложения).
• Automation trigger: явный CTA в конце демо (Demo Playbook, этап 8) → фиксация next step в CRM с датой.

Self-service путь этот этап пропускает целиком — клиент видит продукт напрямую через conversational-онбординг (этап 6), не через звонок с менеджером.

---

Этап 4 — Выбор тарифа

• Owner (self-service): сам клиент, через Pricing Book / витрину тарифов.
• Owner (enterprise): sales-менеджер → владелец (approval matrix, Pricing Book Enterprise Pricing Policy, для custom quote).
• Expected outcome: тир (или для enterprise — custom quote) явно согласован, известна финальная цена.
• KPI: win rate (доля предложений, закончившихся оплатой), для enterprise — средний cycle time от quote до подписания.
• Automation trigger: для self-service — выбор тира в UI регистрации запускает переход к оплате напрямую; для enterprise — подписанный договор/принятый quote запускает генерацию счёта.

---

Этап 5 — Оплата

• Owner: платформа (автоматический биллинг) для self-service; sales/финансы для enterprise-договоров.
• Expected outcome: платёж проведён успешно, тенант активирован.
• KPI: trial-to-paid / lead-to-paid conversion по тиру, время от выбора тарифа до оплаты.
• Automation trigger: self-service — автоматическое списание через T-Bank-интеграцию (PAY-001/002, живая функциональность в проде) по картe клиента при регистрации/апгрейде. Enterprise — оплата по счёту согласно условиям договора (Pricing Book, Enterprise Pricing Policy: billing cycle, contract term).

---

Этап 6 — Онбординг

• Owner (self-service): платформа — conversational onboarding wizard (реальный поток: discovery-профиль клиента → recommend_onboarding формирует стартовый набор AI-сотрудников и черновик промпта → provision_widget создаёт виджет-токен и выдаёт embed-код, см. core/agent-core/src/api/onboarding_wizard_api.py, ONBOARD-WIZARD-006). Один активный виджет на тенанта на этом шаге (идемпотентность — повторный вызов даёт 409).
• Owner (managed/enterprise): закреплённый специалист / онбординг-команда — поверх того же технического flow добавляется ручная настройка интеграций.
• Expected outcome: тенант получил widget_url + embed_snippet, виджет готов к установке на сайт клиента.
• KPI: completion rate wizard'а (доля начавших онбординг, дошедших до выданного embed-кода), time-to-provision.
• Automation trigger: завершение discovery-профиля клиента (industry/primary_goal/tone/languages/company_name) → автоматический вызов recommend_onboarding → клиент подтверждает/правит рекомендованный system_prompt → POST /onboarding/provision-widget создаёт WidgetToken в БД.

---

Этап 7 — Запуск

• Owner: клиент (устанавливает embed-код на свой сайт) + платформа (техническая готовность виджета).
• Expected outcome: виджет технически встроен на сайт клиента и отвечает на реальный трафик.
• KPI: доля тенантов, установивших embed-код в течение N дней после провижининга (time-to-launch).
• Automation trigger: первый входящий запрос от установленного виджета — технически подтверждает, что embed-код действительно встроен, а не просто выдан.

---

Этап 8 — Использование (Activation / Adoption)

• Owner: платформа (автоматическое отслеживание), Alex/CSM-роль для managed/enterprise.
• Expected outcome — Activation определена измеримо: первая реальная запись в widget_threads для тенанта (первый обработанный диалог виджета с реальным посетителем, не тестовый клик самого клиента) — конкретное событие в системе, не абстрактная «первая ценность».
• KPI: activation rate (доля тенантов с ≥1 реальным диалогом в течение N дней после запуска), среднее время до первой активации (time-to-value).
• Automation trigger: первая запись в widget_threads с message_count ≥ 1 для тенанта → триггерит переход тенанта в статус «активирован» и, для managed/enterprise, уведомление закреплённому специалисту для follow-up звонка.

Edge case — клиент останавливается на Trial и не переходит в Purchase

Если тенант зарегистрировался, но оплата (этап 5) не прошла или подписка не активирована в течение N дней — автоматизированный follow-up триггер: email-напоминание через определённый интервал после регистрации без оплаты. Gap для будущей задачи: конкретный N (интервал) и содержание email-последовательности не определены существующей платформенной автоматизацией на 2026-07-12 — это фиксируется как gap, не реализуется в рамках этого docs-only контракта (SCOPE_LIMIT).

---

Этап 9 — Расширение (Expansion)

• Owner: платформа (сигналы использования) + sales/CSM для managed/enterprise (проактивный апселл).
• Expected outcome: тенант добавляет AI-сотрудников сверх текущего тира или апгрейдится на следующий тир из-за упора в лимит (диалоги/агенты).
• KPI: expansion rate (доля базы, апгрейдящейся ежемесячно — целевой ориентир 3–8%, pricing-strategy-2026.md раздел 4.1), NRR.
• Automation trigger: приближение к лимиту диалогов/агентов тира (сигнал использования) → уведомление тенанту о возможности апгрейда; для managed — этот сигнал также попадает закреплённому специалисту на ежемесячный созвон.

---

Этап 10 — Продление (Renewal)

• Owner: платформа (auto-renew по умолчанию) для self-service; sales/CSM для enterprise-контрактов с фиксированным сроком.
• Expected outcome: подписка продлевается автоматически (self-service, ежемесячно/ежегодно по умолчанию) либо контракт перезаключается по итогам review (enterprise, quarterly performance review — упомянут в старом sales_playbook_pricing_and_qualification_2026.md, Tier 2, актуален и здесь для Enterprise-сегмента).
• KPI: churn rate по тиру, renewal rate для enterprise-контрактов с фиксированным сроком.
• Automation trigger: self-service — стандартный биллинг-цикл (ежемесячное списание продолжается, пока клиент не отменит — 30-дневное уведомление, Pricing Book Terms). Enterprise — за N недель до окончания contract term (минимум 3 месяца, Pricing Book) автоматическое напоминание владельцу/sales о необходимости review условий.

---

Edge case — Enterprise-клиент пропускает Trial

Если enterprise-клиент проходит Demo → сразу custom-переговоры → Purchase, минуя self-serve trial/sandbox — это допустимый, штатный вариант enterprise-ветки, не отклонение от процесса. Enterprise-путь по определению не проходит через self-service онбординг-wizard (этап 6 для этого трека заменяется ручным онбордингом специалиста).

---

Документ ведётся отдельной задачей MKT-030-10. Onboarding-этап описывает реальный ONBOARD-WIZARD-006 flow (сверено через search_code по core/agent-core/src/api/onboarding_wizard_api.py), не идеализированную версию. Незакрытые автоматизации (например, follow-up email при незавершённом trial) зафиксированы как gap, не выдуманы как уже существующие.