Пріоритетний сегмент клієнтів

Optional track — різна маршрутизація до оператора за ознакою VIP / пріоритетного сегменту. Можна додати до Use Case 13 як розширення capstone.

Необхідні права та доступ

Модуль / налаштування	Навіщо
Scenario Builder	Router за сегментом перед connect
Settings → Operator Panel	Дві теми з різними `subject_alias`
Registered Users або Custom Data	Джерело ознаки сегменту
Instance Settings (опційно)	Mock API token для `action_send_request`
Runs / Chat preview	Self-check сегмент A vs B

Бізнес-контекст

Пріоритетні клієнти (VIP, corporate, high LTV) мають потрапляти в іншу тему Operator Panel — з окремою чергою або skill group. Сценарій визначає сегмент і підставляє відповідний subject_alias до connect.

Очікуваний результат

Джерело ознаки: Registered Users / Custom Data / mock API
Router / switch з увагою до типу ('1' vs true, рядок vs число)
Порядок нод: спочатку перевірка сегменту, потім subject_alias у connect
Різні subject_alias для різних connect-блоків (або одного connect з Set)

Зв'язок з іншими налаштуваннями: кожен subject_alias — тема в Settings → Operator Panel. Налаштувати теми

Архітектура

Start → registered_users__get (або CD / API)
   ├─ success → Router (priority_segment)
   │     ├─ priority → Set subject_alias = training_vip
   │     └─ standard → Set subject_alias = training_support
   └─ error → Set subject_alias = training_support (default)

Set subject_alias → operator_panel__connect_to_operator_with_msg
   ├─ success / limit / error

Покрокова реалізація

Крок 0. Дві теми в Settings

Тема	Alias (приклад)	Призначення
Training Support	`training_support`	Звичайні клієнти
Training VIP	`training_vip`	Пріоритетний сегмент

Переконайтеся, що обидва alias існують до збірки сценарію.

Крок 1. Джерело ознаки сегменту

Оберіть один варіант для навчання:

Варіант	Як задати сегмент	Use Case база
Registered Users	Поле `priority_segment` = `1` або `vip`	Use Case 6
Custom Data	Запис клієнта з flag	Use Case 7
Mock API	JSON `{ "vip": true }`	Use Case 4

Для швидкого тесту: два Runs — один з VIP-ознакою, один без.

Крок 2. Отримання сегменту на старті

Приклад — Registered Users:

Нода	Action	Edges
1	`registered_users__get`	success → Router; error → default standard

У Runs перевірте фактичний тип значення: '1' (рядок) vs 1 (число) vs true (boolean).

Крок 3. Router — сегмент до connect

Нода: Router (action_router), режим first_match + default.

Правило	Дія
`priority_segment` equals `1` або `vip`	Set `subject_alias` = `training_vip`
Default	Set `subject_alias` = `training_support`

Критично: не задавайте subject_alias у connect до цієї перевірки.

Крок 4. Connect з динамічним alias

node_params	Значення
`subject_alias`	`{{subject_alias}}`
`auto_connect_operator`	`true`

Edges: success + limit + error (як у Use Case 3).

Крок 5. Self-check у Runs — два профілі

Run	Підготовка	Очікування в constants
A	VIP-ознака в Registered Users	`subject_alias` = `training_vip`
B	Без VIP	`subject_alias` = `training_support`

У trace connect перевірте, який alias передано в action.

Troubleshooting

Симптом	Що перевірити
Завжди standard	Тип змінної в Runs; `'1'` vs `1`
Завжди VIP	Умова Router занадто широка
Connect error	Alias існує в Settings для обох тем
Неправильна черга в OP	Skill groups тем — configure-subjects

→ Коли не сценарій — якщо оператори не в skill group, це налаштування OP, не сценарій.

Self-check

Runs: сегмент A і B ведуть у різні subject_alias
Порядок нод: сегмент → Set alias → connect
Edge limit і error мають повідомлення клієнту
Зафіксовано джерело сегменту в result template

Самостійне завдання

Додайте третій сегмент «corporate» з alias training_corporate і mock API, що повертає { "tier": "corporate" }.