Перейти к основному содержимому

Post-Booking Lifecycle — Изменения, отмены, инциденты и сопровождение после продажи

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

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

Этот документ фиксирует post-booking lifecycle как самостоятельный домен платформы.

Его задача — описать, что происходит после того, как booking уже создан:

  • cancellations;
  • amendments;
  • supplier-initiated changes;
  • forced re-accommodation and disruption;
  • support cases;
  • financial and operational consequences;
  • actor communication and responsibility.

Без этого платформа остаётся сильной до момента продажи, но недооформленной как реальная сервисная система.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

В индустрии travel платформа не заканчивается в момент BookingConfirmed.

После продажи возникают:

  • отмены по инициативе клиента;
  • отмены по инициативе партнёра;
  • supplier-side forced changes;
  • disputes;
  • возвраты;
  • штрафы;
  • ручные операционные сценарии;
  • переоткрытие cases после supposedly completed booking.

Если эти сценарии не имеют отдельной доменной модели, то платформа превращается в “путь до кнопки Купить”, а не в полнофункциональную продажную систему.

Главный Принцип Post-Booking Lifecycle​

Booking — это не финальная точка, а начало следующего operational and financial domain.

Из этого следует:

  • Booking нельзя мыслить как immutable happy-path record;
  • изменение booking не равно “перезаписать поля”;
  • cancellation не равна “сменить статус”;
  • supplier-initiated disruption не может жить только в support notes;
  • post-booking actions должны быть explainable, traceable and surface-aware.

Основные Классы Post-Booking Событий​

1. Customer-Initiated Cancellation​

Отмена, пришедшая через agency, partner or internal operator.

2. Supplier-Initiated Cancellation Or Disruption​

Сценарий, при котором поставщик:

  • отменяет бронирование;
  • меняет условия;
  • теряет доступность;
  • требует re-accommodation;
  • присылает позднюю критическую корректировку.

3. Amendment​

Изменение booking, которое создаёт новую operational and financial реальность:

  • изменение дат;
  • изменение состава гостей;
  • изменение room/product;
  • частичное изменение одного booking item.

4. Support / Dispute Case​

Operational case, который не обязательно сразу меняет booking status, но требует:

  • ownership;
  • timeline;
  • evidence trail;
  • supplier contact trace;
  • customer-facing explanation.

5. Post-Booking Financial Correction​

Возврат, штраф, reversal, adjustment or compensation, возникшие после booking confirmation.

Основные Сущности Домена​

На следующем уровне детализации этот домен должен удерживать как минимум:

  • BookingChangeRequest;
  • CancellationCase;
  • AmendmentCase;
  • SupplierDisruptionCase;
  • SupportCase;
  • PostBookingDecision;
  • RefundDecision;
  • CompensationDecision;
  • CommunicationRecord.

Основные Operational Questions​

Этот домен должен уметь отвечать на вопросы:

  • кто инициировал изменение;
  • может ли изменение быть self-service;
  • нужен ли supplier round-trip;
  • есть ли commercial or clearing consequences;
  • какой SLA и owner у case;
  • кто обязан уведомить клиента или партнёра;
  • считается ли issue resolved, pending, disputed или escalated.

Self-Service И Assisted Flows​

Платформа должна различать:

  • self-service cancellation;
  • assisted cancellation;
  • operator-only amendment;
  • supplier-driven forced case;
  • dispute-led manual resolution.

Нельзя считать, что весь post-booking lifecycle должен идти через один и тот же API path.

Surface Consequences​

Agency And Partner Surfaces​

Должны иметь ясную модель:

  • что они могут изменить сами;
  • какие изменения доступны только как request;
  • какие статусы case they can see;
  • какие financial consequences уже известны;
  • что pending supplier confirmation.

Internal Operational Surface​

Должен иметь:

  • full case state;
  • supplier traceability;
  • manual action tools;
  • escalation and override controls;
  • связь с settlement and clearing outcomes.

Supplier-Driven Problem Handling​

Промышленная платформа должна быть готова к тому, что supplier truth может деградировать post-booking.

Нужны явные сценарии:

  • hotel unavailable after confirmation;
  • changed occupancy or room assignment;
  • changed taxes or mandatory fees;
  • forced refund and rebooking;
  • undocumented supplier-side modification.

Эти случаи не должны растворяться между support и finance.

Связь С Финансами И Clearing​

Post-booking lifecycle должен явно влиять на:

  • settlement events;
  • refund logic;
  • partner balance;
  • holds and reversals;
  • compensations and penalties;
  • reconciliation queues.

Observability And Case Discipline​

Каждый серьёзный post-booking case должен быть:

  • observable;
  • owner-assigned;
  • SLA-tracked;
  • auditable;
  • linked to booking, quote, partner and supplier traces.

Что Должно Быть Сделано Дальше​

После фиксации этого домена нужно:

  • синхронизировать offer-pricing-booking-semantics, api-contracts, clients, settlement-and-reconciliation;
  • сформировать case taxonomy;
  • определить self-service vs assisted boundaries;
  • оформить persistent model для change/disruption/support cases.

Уточнение под Фазы 4–6 (28.04.2026) — связь с payment, booking states, security audit​

Документ опубликован 24.04.2026 (Фаза 3) — отдельный домен post-booking. После Фаз 4–6 каноничные связи требуют фиксации.

Связь с booking state machine​

reference/booking-state-machine.md (Фаза 5) — post-booking activities операционно работают в states:

  • Refund / cancellation — cancel_requested → cancel_in_progress_supplier → cancelled;
  • Amendment — amendment_in_progress → platform_confirmed (или amendment_in_progress → failed_amendment с откатом);
  • Supplier disruption case — может перевести booking в unknown_external_state (требует governance review);
  • Completion — platform_confirmed → completed после завершения путешествия.

Связь с платёжным доменом​

reference/payment-domain.md (Фаза 4) — post-booking financial operations:

  • Refund lifecycle — каноничный workflow в payment-domain;
  • Chargeback workflow — partial automation + manual review;
  • post-booking compensations (например, при supplier downgrade) — operational refund через payment-domain.

Связь с saga Tour Builder​

reference/tour-builder-operational-model.md (Фаза 5) — post-booking для multi-component tours:

  • partial cancellation (один компонент отменён, остальные сохраняются);
  • saga compensation events;
  • per-component refund propagation;
  • tour-level vs component-level cancellation policies.

Связь с notification-and-communication​

reference/notification-and-communication.md (Фаза 4) — каждое post-booking событие генерирует notification:

  • booking.cancellation.confirmed → email + SMS to customer + webhook to partner;
  • booking.amendment.applied → notification chain;
  • booking.disruption.detected → high-priority notification.

Связь с security audit​

reference/security-architecture.md (Фаза 10) — post-booking decisions audit:

  • каждый refund decision (особенно > €1000) → audit event;
  • chargeback dispute outcomes → 7 лет retention;
  • compensation decisions с financial impact → Tier 1 audit log.

Связь с compliance — Package Travel Directive​

reference/compliance-and-legal.md (Фаза 4) — post-booking для package travel:

  • Right to terminate — customer right на отмену при significant changes (price increase >8%);
  • Liability for performance — организатор несёт ответственность за performance services;
  • Insolvency protection — гарантия возврата при insolvency;
  • Standardized information при изменениях package.

Caнoнический workflow для package travel post-booking — отдельная extension этого документа.

Связь с SLA service credits​

operations/sla-and-on-call-model.md (Фаза 6) — для tenant Enterprise post-booking response time — dedicated SLI:

  • support response time < 1 час для Enterprise critical issues;
  • post-booking case resolution SLI (внутренняя метрика).

Связь с partner clearing​

reference/partner-finance-and-clearing.md — post-booking financial impact:

  • refund → reverse entry в partner balance;
  • amendment → adjustment entry;
  • chargeback → potential negative balance impact, holds могут активироваться.

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

Post-booking lifecycle остаётся отдельным доменом (не «хвост booking»). Реализация:

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