Экономическая модель платформы

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа

Документ определяет экономическую модель платформы (platform economic model) Vitiana — единую каноничную картину источников доходов, структуры расходов, экономики на единицу (unit-economics), тарифной структуры партнёрского доступа, экономики переходов между фазами зрелости и обоснование коммерческих решений.

Включает:

Каноничную модель: RevenueStream, CostCategory, TenantEconomicProfile, PricingPlan, PricingComponent, PricingPolicyVersion.
Три каноничных источника доходов и связь с поверхностями взаимодействия.
Структуру расходов по категориям, привязку к фазам инфраструктуры.
Unit-economics — доходы и расходы на единицу (тенант, бронирование, поисковый вызов).
Структуру тарифной сетки (Free / Starter / Professional / Enterprise) с порядками величин и формулами расчёта.
Динамическое ценообразование платформенных услуг — формулу комплексной тарификации.
Экономику переходов между фазами зрелости платформы.
Прогнозы безубыточности и точку выхода в плюс по unit-economics.
Регуляторные следствия (НДС, налог с продаж, маржинальный режим Tour Operators').
Защиту от ценовых аномалий.
Фазы развёртывания финансового слоя.

Документ читается последним в фазе 4 — после всех остальных reference-документов, потому что синтезирует их коммерческие следствия.

Документ читается после:

Архитектурный якорь и бизнес-модель — три направления, тарифные уровни концептуально.
Манифест переосмысления § 1.4 — три источника монетизации.
Платформа как продукт — атрибуты платформенного продукта.
Программный интерфейс как продукт — детальная тарифная структура партнёрского доступа.
Платёжный домен — операции взаиморасчёта.
Партнёрские взаиморасчёты — расчётные периоды.
Учёт потребления и квоты — метрики тарификации.
Аналитика и бизнес-аналитика — витрина экономики тенантов.
Дорожная карта инфраструктурного масштабирования — структура расходов на инфраструктуру по фазам.

В корневых документах зафиксировано что платформа продаёт и кому. Этот документ описывает сколько и почему именно столько — каноничные сущности, формулы, обоснования, фазы.

Экономическая модель — финальный синтезирующий слой платформы. Без неё все продуктовые решения остаются концептуальными — нельзя ответить на вопрос «при каком объёме партнёров платформа выходит в плюс» или «какая маржа на тарифе Professional». Это документ даёт ответ.

Реальное состояние реализации (home-to-go-api): пока работает только vitrip.store с собственной B2C-маржой; партнёрский доступ как продукт ещё не запущен. Экономика будущего — горизонт 12–36 месяцев — формируется этим документом.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: тарифная сетка платформы задаётся платформой, не подгоняется под привычки конкретного партнёра. Партнёр, согласный на тарифную дисциплину, получает доступ; партнёр, требующий захватных условий — нет.

Главное решение

Экономическая модель — отдельный архитектурный документ с каноничными сущностями, явными формулами и явными правилами. Это, помимо прочего:

Три каноничных источника доходов — собственный канал vitrip.store, партнёры с платным программным интерфейсом, агентства. Никакого скрытого или ad-hoc дохода.
Каноничная структура расходов по категориям с привязкой к фазам инфраструктуры. Каждая категория имеет владельца и метрики управления.
Unit-economics считается до запуска тарифного уровня, не после. Запуск без расчёта — запрещён.
Динамическое ценообразование платформенных услуг строится на каноничной формуле, не на интуиции команды продаж.
Запрет на захватные коммерческие соглашения — отступление от каноничной тарифной сетки только через эскалацию владельцу платформы и фиксацию в PricingPolicyVersion.
Прогнозы безубыточности строятся регулярно (ежеквартально) на основе фактических данных из аналитической витрины.
Экономика переходов между фазами заложена в архитектуру — каждая фаза имеет триггеры, обоснование стоимости, прогноз окупаемости.

Каноничная модель экономики

Главные сущности

`RevenueStream` — источник дохода

Сущность, представляющая именованный источник дохода платформы.

{
  stream_id: UUID,
  stream_key: string,
  stream_class: enum,
  description: string,
  applicable_surfaces: array,
  applicable_tenant_classes: array,
  associated_tariff_id: UUID,
  applicable_phase: integer,
  is_active: boolean,
  created_at: timestamp
}

Поля:

stream_class — класс источника:
- b2c_storefront_margin — маржа платформы на собственных сайтах (vitrip.store).
- partner_api_subscription — подписка партнёра на тариф (Starter / Professional / Enterprise).
- partner_api_usage — плата за фактическое потребление сверх квоты тарифа.
- agency_subscription — подписка агентства.
- agency_commission — комиссия с продаж агентства.
- tour_builder_paid_access — отдельная плата за конструктор туров.
- enterprise_revenue_share — разделение выручки с корпоративными партнёрами.
- analytics_export_fee — плата за экспорт сырых аналитических данных (Enterprise).
- dedicated_infrastructure_fee — плата за выделенную инфраструктуру (Enterprise, фаза 4).
applicable_surfaces — на каких поверхностях источник активен.
applicable_tenant_classes — на каких классах тенантов.
associated_tariff_id — связь с конкретным тарифным планом (если применимо).

`CostCategory` — категория расходов

Сущность, представляющая категорию операционных расходов платформы.

{
  category_id: UUID,
  category_key: string,
  category_class: enum,
  is_variable: boolean,
  cost_driver: enum,
  cost_unit: string,
  applicable_phase: integer,
  owners: array,
  is_active: boolean,
  created_at: timestamp
}

Поля:

category_class — класс расходов:
- infrastructure_compute — вычислительные ресурсы (VPS, Bare Metal, Kubernetes).
- infrastructure_storage — хранилища (Object Storage, БД).
- infrastructure_network — сеть и трафик (CDN).
- infrastructure_managed_services — управляемые сервисы (Kafka, OpenSearch, PostgreSQL).
- payment_processing — комиссии провайдеров платёжных услуг.
- external_services — сторонние сервисы (машинный перевод, ML API).
- compliance_legal — юридические расходы, аудиты, лицензии.
- customer_support — поддержка пользователей.
- engineering — расходы на инженерную команду.
- sales_marketing — продажи и маркетинг.
- general_administrative — общие административные расходы.
is_variable — переменные (зависят от объёма) или постоянные.
cost_driver — что движет расходы (per_request / per_gb_storage / per_gb_traffic / per_payment / headcount / monthly_subscription).

`TenantEconomicProfile` — экономический профиль тенанта

Сущность, представляющая детальную экономическую картину конкретного тенанта.

{
  profile_id: UUID,
  tenant_id: UUID,
  current_pricing_plan_id: UUID,
  monthly_revenue_breakdown: object,
  monthly_cost_breakdown: object,
  monthly_gross_margin: numeric,
  ltv_estimate: numeric,
  cac_attributed: numeric,
  payback_period_months: integer,
  health_score: numeric,
  churn_risk: enum,
  upsell_opportunity: enum,
  last_calculated_at: timestamp
}

Поля:

monthly_revenue_breakdown — разбивка дохода по RevenueStream.
monthly_cost_breakdown — разбивка расходов по CostCategory.
monthly_gross_margin — валовая маржа на тенанта.
ltv_estimate — оценка пожизненной ценности (lifetime value).
cac_attributed — привязанная стоимость привлечения клиента (customer acquisition cost).
payback_period_months — период окупаемости в месяцах.
health_score — численный показатель здоровья отношений.
churn_risk — оценка риска оттока (low / medium / high).
upsell_opportunity — оценка возможности повышения тарифа.

Профиль обновляется регулярно через витрину tenant_economics_mart (см. Аналитика и бизнес-аналитика).

`PricingPlan` — тарифный план

Сущность, представляющая конкретный тарифный план, на который тенант подписывается.

{
  plan_id: UUID,
  plan_key: string,
  plan_tier: enum,
  applicable_tenant_class: enum,
  base_subscription_amount: object,
  included_quotas: object,
  overage_components: array,
  features: object,
  sla_class: string,
  contract_terms: object,
  is_default_for_tier: boolean,
  is_active: boolean,
  effective_from: timestamp,
  effective_to: timestamp,
  schema_version: string
}

Поля:

plan_tier — free / starter / professional / enterprise / enterprise_custom.
base_subscription_amount — базовая ежемесячная сумма (с разделением на валюты).
included_quotas — что входит в базу (например, число поисковых вызовов, число коммерческих фиксаций).
overage_components — массив PricingComponent для расчёта стоимости сверх квоты.
features — какие возможности доступны.
sla_class — класс SLA по Программный интерфейс как продукт.

`PricingComponent` — компонент тарификации

Сущность, представляющая отдельный компонент в формуле расчёта стоимости.

{
  component_id: UUID,
  component_key: string,
  metering_metric: string,
  unit_price: numeric,
  unit_currency: string,
  pricing_function: enum,
  pricing_function_parameters: object,
  applies_above_threshold: numeric,
  multipliers: array,
  schema_version: string
}

Поля:

metering_metric — метрика учёта потребления из Учёт потребления и квоты.
unit_price — базовая цена за единицу.
pricing_function — функция (linear / tiered_volume / volume_discount / complexity_weighted).
applies_above_threshold — порог, выше которого компонент активирует overage.
multipliers — массив множителей (например, supplier load profile multiplier для платежей по «дорогим» поставщикам).

`PricingPolicyVersion` — версия тарифной политики

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

{
  version_id: UUID,
  version_label: string,
  effective_from: timestamp,
  superseded_at: timestamp,
  applicable_pricing_plans: array,
  approval_record_id: UUID,
  rollback_pricing_policy_version_id: UUID,
  schema_version: string
}

Каждое значимое изменение тарифной политики — новая версия. Старые версии остаются в журнале для:

Аудита (регулятор, корпоративные партнёры).
Обратной совместимости (партнёры могут оставаться на «зафиксированном» тарифе по контракту).
Возможности отката при проблемах.

Связь с другими каноничными сущностями

RevenueStream.applicable_surfaces — связь с поверхностями из Поверхности взаимодействия.
CostCategory.applicable_phase — связь с фазами из Дорожная карта инфраструктурного масштабирования.
TenantEconomicProfile строится из витрины tenant_economics_mart (Аналитика и бизнес-аналитика).
PricingPlan применяется через Tenant.pricing_plan_id (см. Тенантная настройка).
PricingComponent.metering_metric — каноничная метрика из Учёт потребления и квоты.
PricingPolicyVersion — для разрешения тенанту оставаться на конкретной версии (контрактная стабильность для Enterprise).

Три каноничных источника доходов

Источник 1. Собственный канал — vitrip.store

Класс: b2c_storefront_margin.

Поверхность: B2C Storefront Surface (см. Поверхности взаимодействия).

Модель: платформа закупает у поставщика по цене A, продаёт конечному клиенту по цене A + маржа M. Маржа — главный источник дохода.

Размер маржи:

Базовая маржа платформы — диапазон, типичный для B2C-агрегаторов (порядок 5–15% от стоимости бронирования).
Динамическая часть маржи — зависит от сезонности, конкуренции, типа продукта.

Главные расходы: маркетинг (привлечение конечного клиента — основная статья), поддержка клиентов, операции платежей.

Размер прибыльности: низкая в первые годы (B2C — высокая стоимость привлечения), нормализуется по мере роста бренда vitrip.store.

Источник 2. Партнёры с платным программным интерфейсом

Классы: partner_api_subscription, partner_api_usage, tour_builder_paid_access, enterprise_revenue_share, analytics_export_fee, dedicated_infrastructure_fee.

Поверхность: Partner API Surface, Tour Builder Closed Surface (для тарифов с конструктором туров).

Модель: партнёр платит платформе за доступ (подписка) и за фактическое потребление (overage). Это не «комиссия с бронирования» — платформа продаёт доступ к платформенному слою, не бронирования.

Размер платы: диапазон от десятков долларов в месяц (Starter) до десятков тысяч в месяц (Enterprise).

Главные расходы: инфраструктура (вычислительные ресурсы, базы данных), управляемые сервисы, ML-инференс.

Размер прибыльности: высокая (типично 60–80% валовая маржа на программный интерфейс, как у современных API-платформ). Это главный направление монетизации по архитектурному якорю (см. Архитектурный якорь и бизнес-модель).

Источник 3. Агентства

Классы: agency_subscription, agency_commission.

Поверхность: Agency Working Surface.

Модель: агентство платит подписку (за рабочее место и доступ) + комиссию с подтверждённых бронирований конечных клиентов.

Размер платы: небольшая ежемесячная подписка + переменная комиссия (типично 1–3% от стоимости бронирования).

Главные расходы: инфраструктура (агентский интерфейс), поддержка агентств.

Размер прибыльности: средняя — рынок ограничен (несколько тысяч активных агентств в географии первой волны), но операционные расходы тоже умеренные.

Запрет на ad-hoc монетизацию

❌ Скрытые комиссии, не отражённые в каноничной модели.
❌ Захватные соглашения с одним партнёром, нарушающие тарифную сетку без эскалации.
❌ Исключительные комиссии с поставщиков (платформа не получает доход от поставщиков напрямую — только от своих клиентов: vitrip.store / партнёров / агентств).

Структура расходов

Категории расходов

Инфраструктура (variable)

infrastructure_compute — VPS, Bare Metal, Managed Kubernetes. Драйвер: per_request_load.
infrastructure_storage — Object Storage (медиа), управляемые БД, DWH. Драйвер: per_gb_storage.
infrastructure_network — CDN, исходящий трафик. Драйвер: per_gb_traffic.
infrastructure_managed_services — Kafka, OpenSearch, Managed PostgreSQL, Managed Grafana. Драйвер: per_managed_unit.

См. Дорожная карта инфраструктурного масштабирования для конкретных порядков по фазам.

Платёжная обработка (variable)

payment_processing — комиссии провайдеров платёжных услуг (типично 1.5–3% за платёж + фикс).

Внешние сервисы (variable)

external_services — машинный перевод (DeepL/Google), ML API (если используются), специализированные сервисы.

Compliance и юридические расходы (mostly fixed)

compliance_legal — лицензии, аудиты (PCI DSS, ежегодный compliance-аудит), юридические консультации, GDPR-DPO (data protection officer).

Поддержка клиентов (semi-variable)

customer_support — команда поддержки, тикетная система. Растёт с числом тенантов и конечных клиентов.

Инжиниринг (mostly fixed)

engineering — главная статья расходов в первые годы. Растёт ступенчато при расширении команды.

Продажи и маркетинг (variable)

sales_marketing — особенно велика для B2C-канала vitrip.store; для партнёрского API — меньше (длинный sales cycle, развитые партнёрские отношения).

Общие административные (mostly fixed)

general_administrative — офис, бухгалтерия, операции HR.

Соотношение постоянных и переменных расходов

Раннее состояние платформы (фазы 0–2):

Постоянные расходы доминируют (~70%): инжиниринг, compliance, общие административные.
Переменные расходы умеренные (~30%): инфраструктура, платежи, маркетинг.

Зрелое состояние (фазы 3–4):

Переменные расходы доминируют (~60%): инфраструктура растёт с объёмом, платежи растут с оборотом.
Постоянные стабилизируются (~40%).

Это типичная картина SaaS-платформы с переходом от инвестиционной фазы к операционной.

Unit-economics

Главные единицы анализа

Платформа отслеживает четыре каноничные единицы для unit-economics:

Единица 1. На тенанта (per-tenant)

Метрики:

Месячная выручка от тенанта (monthly revenue per tenant, MRPT) — все источники дохода от тенанта за месяц.
Месячная стоимость обслуживания тенанта (monthly cost-to-serve per tenant) — переменные расходы, привязываемые к тенанту, плюс справедливая доля постоянных.
Маржа на тенанта (gross margin per tenant) — MRPT минус cost-to-serve.
Lifetime value (LTV) — приведённая ценность тенанта за всю историю отношений.
Customer acquisition cost (CAC) — стоимость привлечения тенанта.
Payback period — срок окупаемости CAC из накопленной маржи.
LTV/CAC ratio — главный показатель здоровья unit-economics. Целевая величина — 3+ для здоровой SaaS-платформы.

Единица 2. На бронирование (per-booking)

Метрики:

Доход с бронирования — для vitrip.store (маржа), для партнёра (комиссия + платежи за платформенные услуги, привязанные к бронированию).
Стоимость обслуживания бронирования — операции платежей, обработка коммерческой фиксации, хранение, поддержка.
Маржа на бронирование — доход минус стоимость.

Полезна для анализа эффективности по типам продуктов (отель vs тур vs трансфер).

Единица 3. На вызов программного интерфейса (per-API-call)

Метрики:

Доход с вызова — выводится через тариф партнёра.
Стоимость вызова — инфраструктура (compute + сеть), вызовы поставщику.
Маржа на вызов — для каждого типа вызова отдельно (поиск, коммерческая фиксация, бронирование, ML-инференс).

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

Единица 4. На поверхность взаимодействия (per-surface)

Метрики:

Доход с поверхности — суммарный по всем тенантам этой поверхности.
Стоимость поверхности — выделенная инфраструктура поверхности, специфические возможности.
Маржа на поверхность — для понимания, какие поверхности приносят основную прибыль.

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

Точка безубыточности (break-even)

Цель платформы: достичь точки безубыточности на горизонте 18–30 месяцев (типично для SaaS-платформ с инвестиционной фазой).

Формула break-even:

постоянные_расходы_в_месяц = (число_тенантов × средняя_маржа_на_тенанта_в_месяц) + B2C_маржа + agency_маржа

При фиксированных постоянных расходах ~$Х/месяц и средней марже на тенанта ~$Y/месяц — нужно ~Х/Y тенантов для безубыточности.

Расчёт обновляется ежеквартально в витрине tenant_economics_mart с фактическими данными.

Тарифная сетка партнёрского доступа

Структура

Каноничная структура из Архитектурный якорь и бизнес-модель и Программный интерфейс как продукт:

Уровень	Базовая подписка	Включённые квоты	Overage	Возможности
Free	$0	Только sandbox; ограничено 10 000 поисковых вызовов в месяц	(нет — переход на Starter)	Sandbox, документация, 5 пользователей
Starter	Низкая (десятки $)	Production: ~100 000 поисковых вызовов, 1 000 бронирований	По канонической формуле	Базовый партнёрский интерфейс, лимит. поставщиков, без Tour Builder
Professional	Средняя (сотни $)	Расширенные квоты, без жёсткого верхнего предела	Динамическое ценообразование	Полный партнёрский интерфейс, Tour Builder API, аналитика, расширенный SLA
Enterprise	Высокая (от тысяч $/договорная)	Гарантированная мощность	Индивидуальная договорная	Полный набор, выделенная инфраструктура (фаза 4), revenue share возможен

Точные цифры — открытая развилка (см. развилки ниже). Здесь — порядки величин, согласованные с архитектурой.

Каноничная формула overage

При превышении квоты тарифа применяется формула:

overage_cost =
    (search_calls_above_quota × unit_price_search × complexity_multiplier × supplier_load_multiplier)
  + (quote_creations_above_quota × unit_price_quote)
  + (booking_commits × unit_price_booking)
  + (webhook_deliveries × unit_price_webhook)
  + (ml_inference_calls × unit_price_ml)
  + (storage_usage_gb × unit_price_storage_per_gb)
  + (analytics_api_calls × unit_price_analytics)

Каждый компонент имеет свой PricingComponent с конкретной ценой и множителями.

Множители

complexity_multiplier — для поисковых запросов (см. Поиск и обнаружение, complexity_score). Простой запрос — множитель 1; сложный — до 5–10.
supplier_load_multiplier — для запросов к «дорогим» поставщикам (см. Платформа как продукт).
peak_hour_multiplier — может применяться в фазе 3+ для пиковых часов нагрузки.
region_multiplier — может применяться при региональных особенностях (например, дорогие платежи в стране).

Скидка за объём

Выше определённых порогов нагрузки — снижение цены за единицу:

1М вызовов в месяц — 10% скидка.
10М вызовов в месяц — 25% скидка.
100М вызовов в месяц — индивидуальный контракт.

Это поощряет рост на платформе.

Запрет на отрицательную маржу

Каноничная цена компонента не может быть ниже его marginal cost (пограничной стоимости — стоимость одного дополнительного вызова). Иначе при росте платформы маржа становится отрицательной.

Исключение: тариф Free — намеренно с отрицательной маржой как акция привлечения, ограниченный объём.

Динамическое ценообразование платформенных услуг

Прозрачность тарификации для партнёра

Раздел добавлен после внешнего архитектурного ревью 30.04.2026, в котором отмечен риск: «Поймёт ли рынок плату за сложность запроса? Большинство B2B привыкло к комиссии. Вам понадобится очень прозрачный Usage Dashboard, чтобы партнёр не чувствовал, что его грабят за тяжёлые фильтры».

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

Что уточняется по сравнению с разделом «Динамическое ценообразование»

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

точное определение — что конкретно считается этим объектом;
явную ставку на единицу — публичная цена в тарифной сетке партнёрского уровня;
видимый счётчик в реальном времени — партнёр видит свой usage в partner console;
детализированный invoice — каждый платный объект отдельной строкой с количеством и ставкой.

Никаких «коэффициентов сложности», «штрафов за тяжёлые фильтры» или скрытых правил. Если партнёр сделал N запросов одного типа — он платит N × rate. Точка.

Каноничные платные объекты

Объект	Что считается	Когда начисляется
search_executed	Каждый успешный search request, обработанный платформой и вернувший results	После возврата результатов пользователю
quote_generated	Каждый Quote с уникальным `quote_id`, созданный для партнёра	При создании Quote (не каждый просмотр Quote)
booking_committed	Каждый успешный booking commit, перешедший в `confirmed`	При переходе booking в `confirmed`
supplier_call_initiated	Каждый исходящий вызов к supplier'у в рамках обслуживания партнёра	По факту отправки запроса в supplier
notification_delivered	Каждое webhook/email/SMS уведомление, успешно доставленное	После confirmation доставки
storage_gb_month	Гигабайты storage'а партнёрских данных в месяц	Снапшот в конце месяца
ml_inference_call	Каждый вызов ML-модели от имени партнёра (recommendation, ranking)	По факту inference
partner_data_export	Каждый export операционных данных партнёра	По факту запроса export

Перечень объектов — закрытый и зафиксированный. Новые платные объекты добавляются только через major version тарифной сетки с минимум 90 дней advance notice партнёрам.

Что НЕ является платным объектом

Чтобы избежать неправильных ожиданий:

Не платится за просмотр уже созданного Quote или booking (read-операции на существующих сущностях).
Не платится за фильтры на стороне платформы. Search с одним параметром и search с десятью параметрами — один search_executed.
Не платится за объём ответа (количество returned properties). Search возвращающий 100 results = search возвращающий 10 results.
Не платится за повторные попытки при transient failures (платформа сама handles retries для idempotent операций — см. reference/eventing-and-queue-baseline.md).
Не платится за webhook delivery attempts — только за доставленные notifications.
Не платится за технические operations платформы (ingestion, governance review, infrastructure).

Каноничные профили потребления — примеры

Профиль 1: Стартующее агентство (Free tier)

Маленькое travel-агентство, начинающее с платформой. Месячный объём:

5 000 search_executed
500 quote_generated
50 booking_committed
1 GB storage
100 notifications

При Free tier (бесплатный для первых 6 месяцев или до достижения lower threshold) — 0 USD в месяц. Партнёр платит 0, видит полные счётчики в partner console.

Профиль 2: Активный B2B (Professional tier)

Среднее агентство с регулярным потоком. Месячный объём:

200 000 search_executed × 0.001 USD = 200 USD
30 000 quote_generated × 0.005 USD = 150 USD
1 500 booking_committed × 0.50 USD = 750 USD
50 000 supplier_call_initiated × 0.0005 USD = 25 USD
10 GB storage × 1 USD = 10 USD
5 000 notifications × 0.001 USD = 5 USD
Total: ~1 140 USD/месяц

Партнёр видит детализированный invoice с точными числами по каждой строке. Каждое число объяснимо: «вот столько search'ей, по такой ставке, итого столько».

Профиль 3: Enterprise (Enterprise tier)

Крупный заказчик с custom contract. Месячный объём:

5 000 000 search_executed
800 000 quote_generated
50 000 booking_committed
ML inference calls для personalized ranking
500 GB storage
Multi-region inference

Тариф зависит от negotiated contract, обычно с volume discount'ами и custom SLA. Базовая структура та же — usage × rate, но rates персонализированы.

Профиль 4: API-only intеграторов (white-label)

White-label партнёр строит собственную витрину. Месячный объём:

1 000 000 search_executed
200 000 quote_generated
10 000 booking_committed
200 000 supplier_call_initiated
50 GB storage
100 000 notifications
Private supplier pool (extra fee for dedicated supplier capacity)

Тариф включает dedicated capacity premium — партнёр платит больше за гарантированную выделенную нагрузку, в обмен — высокий SLA и priority при rate limits.

Partner Usage Dashboard — каноничные требования

Каждый партнёр имеет dashboard в partner console со следующими свойствами:

Реальное время

Все usage-метрики обновляются с задержкой не более 30 секунд от факта события.
Текущий месячный usage всегда виден.
Прогноз до конца месяца на основе текущей runrate.

Детализация

Breakdown по каждому платному объекту.
Breakdown по каждому surface (если партнёр использует несколько).
Breakdown по дню/часу для оперативного мониторинга.
Top 10 запросов с наибольшим вкладом (для понимания, что генерирует usage).

Сравнения

Сравнение с прошлым месяцем (delta в %).
Сравнение со средним по партнёрам того же tier (с anonymization для confidentiality).
Прогноз счёта в конце месяца с confidence interval.

Алерты

Партнёр настраивает custom alerts (например, «notify me if monthly usage exceeds 1000 USD»).
Платформа автоматически notifies при превышении 80%, 100% от usual baseline (ML-driven).

API доступ

Partner Usage Dashboard данные доступны через API — партнёр может intеgrate в свой собственный billing/analytics.
Endpoint: GET /partner/usage с фильтрами по period, surface, object type.

Mockup пример (текстовый)

═══════════════════════════════════════════════════════════════════
PARTNER USAGE DASHBOARD              Period: 2026-04 (30 days)
Tier: Professional                   Currency: USD
═══════════════════════════════════════════════════════════════════
                                                  Used  /  Avg/Day  /  Cost
Search executions             ▓▓▓▓▓▓▓▓▓░░  198 432  /     6 614  /  $198.43
Quotes generated              ▓▓▓▓▓▓▓░░░░   28 105  /       937  /  $140.53
Bookings committed            ▓▓▓▓▓▓▓▓▓▓▓    1 482  /        49  /  $741.00
Supplier calls                ▓▓▓▓▓▓▓░░░░   48 312  /     1 610  /   $24.16
Storage (GB-month)                            10.20  /         -  /   $10.20
Notifications delivered       ▓▓▓▓▓▓▓░░░░    4 921  /       164  /    $4.92
─────────────────────────────────────────────────────────────────
TOTAL USAGE                                                       $1 119.24
─────────────────────────────────────────────────────────────────
Forecast to month-end (linear trend):                             $1 165.00
vs Previous month:                                                +5.4%
vs Tier average (anonymous):                                      -12.0%

⚠ Alert: notification budget approaching configured threshold
  ($5.00 / $4.92 used)
═══════════════════════════════════════════════════════════════════

Stage-aware развёртывание dashboard'а

Stage 1: базовый dashboard с real-time счётчиками и monthly invoice. Без forecast'ов и комparisons.
Stage 2: добавляются alerts, форкасты, сравнения по периодам.
Stage 3: добавляются ML-driven anomaly alerts, top-contributors analysis, comparisons с anonymized peer data.
Stage 4: добавляются дополнительные intelligence layers (cost optimization recommendations, predictive billing).

Связь с тезисами тарификации

Этот раздел дополняет, не заменяет общий принцип динамического ценообразования (см. раздел Динамическое ценообразование платформенных услуг выше). Главный принцип — usage-based, не commission-based — остаётся в силе. Этот раздел делает его прозрачным и предсказуемым для партнёра.

Обоснование (тезисы)

Тезис 1. Тарификация — счётчик ресурсов, не оценщик сложности.

Альтернативы: (а) variable pricing на основе complexity/load коэффициентов; (б) fixed rate per defined object.

Trade-off: вариант (а) — opaque, создаёт ощущение «вас грабят» (точное опасение ревьюера); вариант (б) — каноничный, прозрачный, предсказуемый.

Тезис 2. Real-time dashboard обязательны с Stage 1.

Альтернативы: (а) только monthly invoices; (б) real-time dashboard с самого начала.

Trade-off: вариант (а) приводит к bill shock в конце месяца; вариант (б) — каноничный для usage-based pricing моделей (Stripe, Twilio, AWS).

Тезис 3. Закрытый перечень платных объектов.

Альтернативы: (а) платформа может добавлять новые платные объекты по своему усмотрению; (б) перечень фиксированный, расширения только через major version с advance notice.

Trade-off: вариант (а) подрывает доверие партнёров и создаёт billing surprise; вариант (б) — каноничный, обеспечивает контрактную предсказуемость.

Тезис 4. API доступ к usage data — first-class.

Альтернативы: (а) partner usage только через console UI; (б) usage data через API в дополнение к UI.

Trade-off: вариант (а) препятствует enterprise-партнёрам интегрировать billing platformы в свои internal системы; вариант (б) — каноничный для Stripe-like моделей.

Структура динамического тарифа

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

monthly_dynamic_cost =
    base_subscription
  + Σ (metric_consumption × unit_price × all_applicable_multipliers)
  + (peak_capacity_bonus  if reserved_capacity_used)
  - volume_discount

Применение по тарифам

Starter — фиксированная подписка + простой overage без множителей сложности.
Professional — подписка + полное динамическое с множителями.
Enterprise — индивидуальная договорная (с гарантированной capacity) или revenue share.

Прозрачность

Партнёр в любой момент видит:

Свои фактические метрики потребления.
Разбивку расхода по компонентам.
Прогноз счёта на конец месяца на основе текущей траектории.
Применённые множители с обоснованием.

См. Программный интерфейс как продукт — раздел про прозрачность.

ML-оптимизация в фазе 3+

В фазе 3 — возможна ML-оптимизация ценообразования:

Модель прогнозирует оптимальные цены для максимизации выручки при сохранении конкурентоспособности.
Эксперименты A/B над тарифами (см. Платформа экспериментов и A/B-тестирования).
Bandit-алгоритмы для динамической оптимизации (фаза 4).

Экономика переходов между фазами

Фаза Bootstrap (0–6 месяцев)

Состояние: платформа в инвестиционной фазе. Расходы доминируют над доходами.

Главные расходы:

Инфраструктура минимальна (Tier 0 ~$60–80 в месяц, см. Дорожная карта инфраструктурного масштабирования).
Инжиниринг — главная статья.

Главные доходы:

vitrip.store как существующий канал.

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

Фаза 2 — Production launch (6–18 месяцев)

Состояние: запуск партнёрского доступа как продукта.

Главные новые расходы:

Расширенная инфраструктура (Tier 1 — несколько сотен $ в месяц).
Управляемые сервисы (PostgreSQL, Kafka, OpenSearch).
Продажи и маркетинг для партнёрского привлечения.

Главные новые доходы:

Первые партнёры на тарифах Starter и Professional.

Цель: получить ~10–30 платных партнёров для проверки модели.

Фаза 3 — Production scale (18–30 месяцев)

Состояние: масштабирование. Цель — точка безубыточности.

Главные расходы:

Multi-region инфраструктура.
Расширенная команда.
ML-инфраструктура.

Главные доходы:

Десятки партнёров Professional, первые Enterprise.

Цель: достижение точки безубыточности на месячной основе.

Фаза 4 — Production maturity (30+ месяцев)

Состояние: прибыльная фаза.

Главные новые расходы:

Глобальная инфраструктура.
Выделенные ресурсы для Enterprise-партнёров.

Главные новые доходы:

Корпоративные партнёры с большим объёмом.
Расширение в новые географии.
Сетевые эффекты от роста партнёрской экосистемы.

Цель: устойчивая прибыль с растущей маржой.

Регуляторные следствия

Налог на добавленную стоимость (НДС)

В Европейском Союзе:

Услуги программного интерфейса партнёру в EU — стандартный НДС (по ставке страны партнёра, через VAT MOSS / OSS).
Услуги программного интерфейса партнёру вне EU — обычно без НДС (правило места поставки).
Бронирования через vitrip.store — НДС по правилам страны клиента.

В Украине и Казахстане — отдельные налоговые режимы. Каждое расширение страны требует регуляторного анализа в рамках 7-шагового процесса (см. Интернационализация и локализация).

Маржинальный режим Tour Operators (TOMS)

Для пакетных туров в EU применяется маржинальный режим — платформа платит НДС только с маржи, не с полной стоимости.

Журнал доходов для аудита

Все доходы детализируются по RevenueStream с привязкой к конкретным тенантам, бронированиям, периодам. Журнал доступен:

Для внутренней finance-команды.
Для аудитора.
Для регулятора при запросе.

Срок хранения — 7 лет (tx_audit retention class из Платформа данных и захват событий).

Защита от ценовых аномалий

Аномалии в потреблении

Платформа отслеживает:

Внезапный всплеск потребления партнёра — возможно, ошибка интеграции или DOS-атака. Активирует алерт и предложение партнёру связаться с поддержкой.
Аномалия в расходах на инфраструктуру — внезапный рост стоимости конкретного компонента. Активирует расследование.
Аномалия в марже на тенанта — внезапное падение маржи. Активирует анализ причин (рост стоимости поставщика? Изменение паттернов использования?).

Защита партнёра от пиков

При обнаружении аномального всплеска у партнёра — платформа автоматически связывается с партнёром до выставления крупного счёта. Это:

Защищает партнёра от шока счёта при ошибке.
Защищает платформу от disputes и chargebacks.
Сохраняет долгосрочные отношения.

Для тарифов Professional и Enterprise — настраиваемые потолки месячных расходов (monthly_spending_cap).

Защита платформы от убыточных тенантов

Регулярный анализ TenantEconomicProfile:

Тенанты с устойчиво отрицательной маржой более 6 месяцев — кандидаты на пересмотр условий или эскалацию.
Корпоративные партнёры с особыми условиями — пересмотр контракта в установленные сроки.

События экономического слоя

Событие	Когда	Главные потребители
`pricing.policy.version_published`	Публикация новой версии тарифной политики	Партнёрская консоль, контур уведомлений, аудит
`pricing.policy.version_superseded`	Замена версии новой	Аудит
`tenant.subscription.activated`	Активация подписки тенанта	Контур уведомлений, контур finance
`tenant.subscription.upgraded`	Повышение тарифа	Контур уведомлений, аналитика
`tenant.subscription.downgraded`	Понижение тарифа	Контур уведомлений, расследование оттока
`tenant.economic_profile.recalculated`	Пересчёт профиля	Витрина экономики тенантов
`tenant.churn_risk.elevated`	Повышение риска оттока	Команда успеха клиентов
`tenant.upsell_opportunity.detected`	Обнаружение возможности повышения тарифа	Команда продаж
`pricing.spending_cap.threshold_reached`	Достижение порога ежемесячных расходов	Партнёр (через уведомления)
`pricing.anomaly.detected`	Обнаружение аномалии в потреблении	Команда поддержки, партнёр
`revenue.monthly_close.completed`	Закрытие месячного финансового периода	Контур finance, аналитика
`cost.category.threshold_exceeded`	Превышение порога расходов в категории	Контур наблюдаемости расходов

Полная таксономия — в Первоначальная таксономия событий.

Фазы развёртывания финансового слоя

Фаза Bootstrap (0–6 месяцев)

Что разворачивается:

Каноничная модель (RevenueStream, CostCategory, TenantEconomicProfile, PricingPlan, PricingComponent, PricingPolicyVersion) зафиксирована.
Простой расчёт ежемесячных расходов через табличку.
Простой расчёт доходов от vitrip.store.
Базовый прогноз break-even.

Триггер выхода:

Готовность к запуску партнёрского доступа — нужны строгие правила тарификации.

Фаза 2 — Production economic layer (6–18 месяцев)

Что разворачивается:

Полный реестр RevenueStream и CostCategory.
Активные PricingPlan для всех 4 тарифов.
Расчёт TenantEconomicProfile ежемесячно.
Витрина tenant_economics_mart (см. Аналитика и бизнес-аналитика).
Партнёрский интерфейс отображения текущего потребления и прогноза счёта.
Защита от ценовых аномалий.
Регулярный анализ unit-economics.

Триггер выхода:

Появление спроса на ML-оптимизацию ценообразования.
Появление крупных корпоративных партнёров с особыми условиями.

Фаза 3 — Smart pricing (18–30 месяцев)

Что разворачивается:

ML-модели прогнозирования оттока.
ML-модели обнаружения upsell-возможностей.
A/B-эксперименты над тарифами.
Расширенная аналитика unit-economics.
Динамическое ценообразование с множителями всех типов.

Фаза 4 — Mature pricing (30+ месяцев)

Что разворачивается:

Bandit-алгоритмы для динамической оптимизации.
Кастомные тарифы для крупных корпоративных партнёров.
Revenue share модели.
Multi-region pricing с учётом региональных особенностей.

Архитектурные решения с тезисным обоснованием

Решение 1. Экономика — отдельный архитектурный слой, не «просто финансы»

Цель: связать продуктовые решения с финансовыми последствиями.

Тезисы:

Без структурированной модели экономика остаётся в Excel-таблицах команды finance, оторванная от продуктовых решений. Это приводит к запуску продуктов без проверки unit-economics.
Каноничная модель сущностей с привязкой к RevenueStream и CostCategory обеспечивает единый язык для продукта, инжиниринга и finance.
Современные SaaS-платформы (Stripe, Twilio, Datadog) — все строят детальную unit-economics модель как часть продуктовой инфраструктуры. Это база.

Решение 2. Три каноничных источника, не ad-hoc монетизация

Цель: обеспечить долгосрочную предсказуемость и защиту от деградации модели.

Тезисы:

Без зафиксированных каноничных источников возникает соблазн ad-hoc монетизации — комиссии с поставщиков, скрытые сборы, захватные соглашения. Это разрушает доверие и создаёт регуляторные риски.
Три источника покрывают полный спектр сценариев из бизнес-модели.
Защита через правило 00000 — платформа не получает доход от поставщиков, только от своих клиентов.

Решение 3. Версионирование тарифной политики (`PricingPolicyVersion`)

Цель: обеспечить контрактную стабильность для партнёров и аудит для регулятора.

Тезисы:

Корпоративные партнёры подписывают контракты на годовой горизонт. Изменение тарифа не может быть мгновенным.
Регулятор требует доказательную базу применённых ставок в момент сделки.
Откат при ошибке — единственный надёжный способ через версионирование.

Решение 4. Динамическое ценообразование как формула с множителями, не «договорные цены»

Цель: обеспечить справедливую тарификацию по реальной нагрузке партнёра.

Тезисы:

Без формулы каждый запрос обрабатывается по одной цене — это субсидирование «дорогих» партнёров «дешёвыми».
Множители (сложность, supplier load, время суток) делают тариф отражающим реальную стоимость.
Прозрачность множителей — единственный способ объяснить партнёру, почему его счёт такой.

Решение 5. Защита от убыточных тенантов через регулярный анализ

Цель: предотвратить накопление убыточных отношений.

Тезисы:

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

Открытые развилки

Развилка 1. Точные цифры тарифной сетки

Структура тарифов — Free / Starter / Professional / Enterprise — зафиксирована. Точные цифры (базовая подписка, цена за единицу) — открытая развилка фазы 2.

Эскалируется: к владельцу платформы при подготовке к запуску партнёрского доступа (фаза 2). Цифры зависят от:

Реальной стоимости инфраструктуры на момент запуска.
Конкурентной разведки (что предлагают аналогичные платформы).
Целевых параметров unit-economics (LTV/CAC, payback period).

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

Развилка 2. Революнюшейр для Enterprise — модель и пороги

Модель revenue share для крупных Enterprise-партнёров (платформа получает % от выручки партнёра вместо подписки) — концептуально допустима, но конкретные пороги и проценты — открыты.

Эскалируется: при появлении первого корпоративного партнёра с подходящим объёмом.

Развилка 3. Маркетплейсная модель для распределения выручки между поставщиками

В фазе 4 возможна модель, где поставщики конкурируют за позицию в выдаче и платформа получает плату от поставщиков (как Booking.com). Это существенное изменение правила 00000 (платформа не получает дохода от поставщиков) и требует отдельного решения владельца.

Эскалируется: при стратегическом пересмотре в фазе 4.

Развилка 4. ML-driven dynamic pricing — глубина

В фазе 3 — ML над ценообразованием. Глубина (от простого прогнозирования до автоматических корректировок цен в реальном времени) — открыто.

Эскалируется: при создании ML-стратегии в Платформа машинного обучения.

Развилка 5. Точная стоимость привлечения партнёра (CAC)

CAC сильно зависит от каналов привлечения (входящий маркетинг, прямые продажи, партнёрские программы). На фазе 2 — оценочные значения; фактические будут получены через витрину tenant_economics_mart.

Эскалируется: при ежеквартальном анализе unit-economics после первых 6 месяцев фазы 2.

Связанная документация

Корневые архитектурные документы

Архитектурный якорь и бизнес-модель — тарифные уровни концептуально, динамическая тарификация.
Манифест переосмысления § 1.4 — три источника монетизации.
Платформа как продукт — атрибуты платформенного продукта.
Поверхности взаимодействия — поверхности и их экономика.
Каноничная доменная ось — контур учёта потребления и тарификации.
Связь с реализацией — текущее состояние vitrip.store как существующего канала.

Связанные доменные документы

Программный интерфейс как продукт — детальная тарифная структура партнёрского доступа.
Платёжный домен — операции взаиморасчёта, комиссии провайдеров платёжных услуг.
Партнёрские взаиморасчёты — расчётные периоды.
Учёт потребления и квоты — каноничные метрики тарификации.
Аналитика и бизнес-аналитика — витрина экономики тенантов.
Платформа данных и захват событий — DWH как источник данных для расчёта unit-economics.
Платформа машинного обучения — ML-применения для прогнозирования оттока, обнаружения upsell.
Платформа экспериментов и A/B-тестирования — эксперименты над тарифами.
Уведомления и коммуникации — каналы доставки уведомлений о тарифах и счетах.
Соответствие требованиям регуляторов — НДС, маржинальный режим Tour Operators, налоговые обязательства.
Тенантная настройка — конфигурация тарифа тенанта.
Интернационализация и локализация — multi-currency для тарификации.
Поиск и обнаружение — complexity_score как множитель тарификации.

Документы развития

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

Операционная сторона

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

Архитектурные правила

Закон 00000 — платформа главенствует над поставщиками — платформа не получает дохода от поставщиков, только от своих клиентов.
Современные лучшие практики верхнеуровневых платформ — Stripe, Twilio, Datadog как ориентиры экономической модели.
Развитие без деградации — экономическая модель без захватных соглашений и скрытой монетизации.
Эластичное масштабирование и упаковка по фазам — экономика переходов между фазами.
Тезисное обоснование архитектурных решений — формат принятия решений.

Уточнение под Фазы 5–6 (28.04.2026) — связь с операционной зрелостью

Документ опубликован 26.04.2026 в Фазе 4. После Фаз 5–6 (caнoничные углубления и операционная зрелость, 25–27.04.2026) появились связи, которые должны быть явно зафиксированы для интерпретации экономических решений.

Связь с уровнями тенантной изоляции

В этом документе используется revenue stream dedicated_infrastructure_fee как класс источника дохода (Enterprise tier, фаза 4). Каноничная модель уровней изоляции определяется в reference/multi-tenant-isolation-strength.md (Фаза 5):

Уровень изоляции	Связанный revenue stream	Тарифный уровень
`logical`	partner_api_subscription, partner_api_usage	Free / Starter / Professional
`dedicated_compute`	partner_api_subscription с надбавкой	Professional (опционально), Enterprise
`dedicated_infrastructure`	dedicated_infrastructure_fee + indvidual contract	Enterprise (mandatory для regulated)

dedicated_infrastructure_fee имеет смысл только для tenants с уровнем изоляции dedicated_infrastructure — это операционная база для тарификации.

Связь со SLA-моделью и service credits

В этом документе зафиксированы revenue streams и unit-economics, но service credits как financial correction не упоминается. Каноничная модель SLA и service credits — в operations/sla-and-on-call-model.md (Фаза 6).

Service credits — это revenue-side correction (платформа возвращает часть подписки tenant при нарушении SLA):

5% / 10% / 25% / 50% от месячной подписки в зависимости от глубины нарушения;
автоматическая выплата через self-service tenant dashboard;
учитываются в tenant_economics_mart как revenue_correction per period;
влияют на расчёт фактической маржи каждого tier.

Unit-economics на тарифе Professional / Enterprise обязан учитывать expected service credits как probabilistic cost (например, для 99% SLA Professional — 1% downtime → ~5% credits в месяце нарушения).

Связь с операционной ёмкостью и DR

В этом документе категория infrastructure_compute зафиксирована как cost class. После Фазы 6 каноничная модель ёмкости и DR — в operations/disaster-recovery-and-capacity.md:

4 класса данных (Tier 1 / Tier 2 / Tier 3 / Tier 4) — каждый со своей retention и DR cost;
DR drills — каноничные расходы (4–8 человеко-часов на каждое полное учение каждые 90 дней);
Capacity headroom 30–40% — operational cost, который должен быть включён в infrastructure_compute cost forecasts.

Cost driver для infrastructure_compute для Enterprise tier с dedicated_infrastructure — значительно выше baseline (фактически 1.5–3x от shared compute), что меняет unit-economics на Enterprise. Это должно быть явно учтено в tenant_economic_profile.expected_margin.

Связь с операционной моделью runbooks и инцидентов

Стоимость инцидентов (incident operational cost) не зафиксирована как отдельная категория в этом документе. Согласно operations/runbooks-incident-playbooks.md (Фаза 6):

8 каноничных incident classes;
среднее MTTR — 4 часа для critical;
on-call burden ограничен правилами burnout protection.

Стоимость on-call rotation (включая premium pay для on-call hours) — это операционный cost, относящийся к категории payroll (или новой oncall_premium), которая должна быть отслежена для расчёта истинной cost-per-Enterprise-tenant.

Связь с Tour Builder operational model

Метрика tour_builder_paid_access (revenue stream класс) использует данные о Tour Builder operations. Каноничная операционная модель — в reference/tour-builder-operational-model.md (Фаза 5):

saga-координация добавляет operational cost (saga execution, drift detection, compensation);
DriftEvent — каждое появление требует repricing operations (additional metering для tariffication);
CompensationEvent — saga rollback может стоить значительные ресурсы (cancel propagation к нескольким поставщикам).

Cost-per-Tour-Builder-operation в unit-economics должен учитывать saga overhead, не только наивную оценку «один HTTP request = одна operation».

Связь со статусной машиной бронирования

Booking метрика booking_volume в этом документе используется для unit-economics. Каноничная state machine — в reference/booking-state-machine.md (Фаза 5).

Особое внимание:

состояние unknown_external_state (8-е каноничное) — не «финал», требует ручного восстановления; cost per such booking в 5–10x выше baseline;
target SLI: менее 1% unknown_external_state (см. sla-and-on-call-model.md);
expected operational cost на этот класс booking должен быть зафиксирован в cost_per_booking_breakdown отдельным компонентом.

Связь с compliance-и-legal cost

Compliance-расходы (audit fees, legal counsel, DPA management, KYC/AML, GDPR DSR processing, EU TOMS VAT compliance) — должны быть в категории расходов. Согласно reference/compliance-and-legal.md, эти расходы растут по фазам:

Фаза 1: GDPR baseline (минимальный);
Фаза 2: + PSD2 + PCI DSS (через PSP, минимальный);
Фаза 3: + EU TOMS + Package Travel Directive (значительный — insurance, bond, aud);
Фаза 4: + AML/KYC + SOC 2 Type 1 (значительный — audit costs);
Фаза 5: + SOC 2 Type 2 (continuous audit);
Фаза 6: + ISO 27001 + DPO (mandatory above 250 employees + GDPR thresholds).

Категория compliance_legal должна быть зафиксирована отдельно, не растворяться в external_services.

Связь с security architecture cost

Security-расходы (penetration testing, bug bounty, vulnerability scanning subscriptions, SIEM, secrets management) — также отдельная категория. См. reference/security-architecture.md:

Фаза 3: первый external pentest (~$10–30K);
Фаза 4: SOC 2 Type 1 audit + private bug bounty;
Фаза 5: continuous penetration testing + public bug bounty + SIEM managed;
Фаза 6: ISO 27001 audit + CISO compensation.

Каноничный итог уточнения

Этот документ остаётся финальным синтезирующим слоем экономики платформы. Расширения по фазам 5–6:

Уровни изоляции → multi-tenant-isolation-strength.md;
Service credits → sla-and-on-call-model.md;
Capacity и DR cost → disaster-recovery-and-capacity.md;
Incident operational cost → runbooks-incident-playbooks.md;
Tour Builder saga overhead → tour-builder-operational-model.md;
Booking unknown_external_state cost → booking-state-machine.md;
Compliance cost growth → compliance-and-legal.md;
Security cost growth → security-architecture.md.

Эти связи обязательны для расчёта истинной unit-economics каждого tier — особенно Enterprise, где cost базы значительно превышают shared shared baseline. При следующем major review этого документа эти costs должны быть явно учтены в cost_per_tenant_breakdown.

Уточнение выполнено через no-destruction.

Назначение документа
Главное решение
Каноничная модель экономики
- Главные сущности
- Связь с другими каноничными сущностями
Три каноничных источника доходов
Структура расходов
- Категории расходов
- Соотношение постоянных и переменных расходов
Unit-economics
- Главные единицы анализа
- Точка безубыточности (break-even)
Тарифная сетка партнёрского доступа
Динамическое ценообразование платформенных услуг
Прозрачность тарификации для партнёра
Экономика переходов между фазами
Регуляторные следствия
Защита от ценовых аномалий
События экономического слоя
Фазы развёртывания финансового слоя
Архитектурные решения с тезисным обоснованием
Открытые развилки
Связанная документация
Уточнение под Фазы 5–6 (28.04.2026) — связь с операционной зрелостью

Назначение документа​

Главное решение​

Каноничная модель экономики​

Главные сущности​

RevenueStream — источник дохода​

CostCategory — категория расходов​

TenantEconomicProfile — экономический профиль тенанта​

PricingPlan — тарифный план​

PricingComponent — компонент тарификации​

PricingPolicyVersion — версия тарифной политики​

Связь с другими каноничными сущностями​

Три каноничных источника доходов​

Источник 1. Собственный канал — vitrip.store​

Источник 2. Партнёры с платным программным интерфейсом​

Источник 3. Агентства​

Запрет на ad-hoc монетизацию​

Структура расходов​

Категории расходов​

Инфраструктура (variable)​

Платёжная обработка (variable)​

Внешние сервисы (variable)​

Compliance и юридические расходы (mostly fixed)​

Поддержка клиентов (semi-variable)​

Инжиниринг (mostly fixed)​

Продажи и маркетинг (variable)​

Общие административные (mostly fixed)​

Соотношение постоянных и переменных расходов​

Unit-economics​

Главные единицы анализа​

Единица 1. На тенанта (per-tenant)​

Единица 2. На бронирование (per-booking)​

Единица 3. На вызов программного интерфейса (per-API-call)​

Единица 4. На поверхность взаимодействия (per-surface)​

Точка безубыточности (break-even)​

Тарифная сетка партнёрского доступа​

Структура​

Каноничная формула overage​

Множители​

Скидка за объём​

Запрет на отрицательную маржу​

Динамическое ценообразование платформенных услуг​

Прозрачность тарификации для партнёра​

Что уточняется по сравнению с разделом «Динамическое ценообразование»​

Каноничные платные объекты​

Что НЕ является платным объектом​

Каноничные профили потребления — примеры​

Профиль 1: Стартующее агентство (Free tier)​

Профиль 2: Активный B2B (Professional tier)​

Профиль 3: Enterprise (Enterprise tier)​

Профиль 4: API-only intеграторов (white-label)​

Partner Usage Dashboard — каноничные требования​

Реальное время​

Детализация​

Сравнения​

Алерты​

API доступ​

Mockup пример (текстовый)​

Stage-aware развёртывание dashboard'а​

Связь с тезисами тарификации​

Обоснование (тезисы)​

Структура динамического тарифа​

Применение по тарифам​

Прозрачность​

ML-оптимизация в фазе 3+​

Экономика переходов между фазами​

Фаза Bootstrap (0–6 месяцев)​

Фаза 2 — Production launch (6–18 месяцев)​

Фаза 3 — Production scale (18–30 месяцев)​

Фаза 4 — Production maturity (30+ месяцев)​

Регуляторные следствия​

Налог на добавленную стоимость (НДС)​

Маржинальный режим Tour Operators (TOMS)​

Журнал доходов для аудита​

Защита от ценовых аномалий​

Аномалии в потреблении​

Защита партнёра от пиков​

Защита платформы от убыточных тенантов​

События экономического слоя​

Фазы развёртывания финансового слоя​

Фаза Bootstrap (0–6 месяцев)​

Назначение документа

Главное решение

Каноничная модель экономики

Главные сущности

`RevenueStream` — источник дохода

`CostCategory` — категория расходов

`TenantEconomicProfile` — экономический профиль тенанта

`PricingPlan` — тарифный план

`PricingComponent` — компонент тарификации

`PricingPolicyVersion` — версия тарифной политики

Связь с другими каноничными сущностями

Три каноничных источника доходов

Источник 1. Собственный канал — vitrip.store

Источник 2. Партнёры с платным программным интерфейсом

Источник 3. Агентства

Запрет на ad-hoc монетизацию

Структура расходов

Категории расходов

Инфраструктура (variable)

Платёжная обработка (variable)

Внешние сервисы (variable)

Compliance и юридические расходы (mostly fixed)

Поддержка клиентов (semi-variable)

Инжиниринг (mostly fixed)

Продажи и маркетинг (variable)

Общие административные (mostly fixed)

Соотношение постоянных и переменных расходов

Unit-economics

Главные единицы анализа

Единица 1. На тенанта (per-tenant)

Единица 2. На бронирование (per-booking)

Единица 3. На вызов программного интерфейса (per-API-call)

Единица 4. На поверхность взаимодействия (per-surface)

Точка безубыточности (break-even)

Тарифная сетка партнёрского доступа

Структура

Каноничная формула overage

Множители

Скидка за объём

Запрет на отрицательную маржу

Динамическое ценообразование платформенных услуг

Прозрачность тарификации для партнёра

Что уточняется по сравнению с разделом «Динамическое ценообразование»

Каноничные платные объекты

Что НЕ является платным объектом

Каноничные профили потребления — примеры

Профиль 1: Стартующее агентство (Free tier)

Профиль 2: Активный B2B (Professional tier)

Профиль 3: Enterprise (Enterprise tier)

Профиль 4: API-only intеграторов (white-label)

Partner Usage Dashboard — каноничные требования

Реальное время

Детализация

Сравнения

Алерты

API доступ

Mockup пример (текстовый)

Stage-aware развёртывание dashboard'а

Связь с тезисами тарификации

Обоснование (тезисы)

Структура динамического тарифа

Применение по тарифам

Прозрачность

ML-оптимизация в фазе 3+

Экономика переходов между фазами

Фаза Bootstrap (0–6 месяцев)

Фаза 2 — Production launch (6–18 месяцев)

Фаза 3 — Production scale (18–30 месяцев)

Фаза 4 — Production maturity (30+ месяцев)

Регуляторные следствия

Налог на добавленную стоимость (НДС)

Маржинальный режим Tour Operators (TOMS)

Журнал доходов для аудита

Защита от ценовых аномалий

Аномалии в потреблении

Защита партнёра от пиков

Защита платформы от убыточных тенантов

События экономического слоя

Фазы развёртывания финансового слоя

Фаза Bootstrap (0–6 месяцев)