mobile-app-prototip/MEETING_2026-04-23.md

# Приоритеты развития мобильного приложения — встреча 23 апр 2026

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

## 1. Контекст и критерии приоритизации

**Текущие функции:** список врачей, запись на приём, ближайший приём, чат с оператором, профиль, семейный профиль, контакты.

### Ключевые факты о потоке

- **2 из 3 пациентов клиники — повторные.** Значительная доля — **повторные внутри одного лечения**: после первого визита (острое заболевание или обострение хронического) ещё 1–3+ приёма, процедуры, контроль.
- **Бизнес-сегментация (из аналитики клиники)** — 10 сегментов, лидеры по выручке: амбулаторный поток (~120 млн), взрослая хирургия «заблокированный нос» (~30 млн), детская аденоидная хирургия (~20–30 млн), сурдология (~20 млн).

### Продуктовая логика: что делает приложение

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

Это совпадает с фактом «2 из 3 — повторные» и означает, что:
- **Первичные сценарии в приложении** закрываются универсальным минимумом (запись + контакты + цены + AI-помощник, который знает услуги). Нет смысла строить специализированные первичные потоки для каждого из 10 сегментов.
- **Повторные сценарии** — специфичны по сегменту и требуют отдельных модулей (бегунок, аудиограмма, АСИТ-дневник и т.п.).
- **Исключения** — сегменты, где «первичный в приложении» ≠ «первый визит»: после первого визита пациент уходит, и вернуть его в клинику может только приложение.
  - **Сурдология** — после визита и демо пациент уходит думать 2–3 месяца о покупке аппарата.
  - **Хирургия (FESS, детские аденоиды, вазотомия)** — после пред-операционного приёма у хирурга пациент часто уходит **думать, решаться ли на операцию вообще**. Эти «сомневающиеся» — отдельная работа по возврату. Вторая часть — те, кто решился, уходят в 6-недельную подготовку (бегунок).
  - **АСИТ** — после назначения впереди 3–5-летний курс, есть сценарии «не начал» и «бросил в первые месяцы».

### Три слоя работы

1. **Фаза 1 · Транзакционная база** — детерминированные функции для любого пациента: запись, ближайший приём, чат с оператором, **план лечения, результаты/медкарта, заказ справок**. Без LLM и прямого чата с врачом. Минимум рисков, быстрый запуск.
2. **Фаза 1.5 · Коммуникационная надстройка** — чат с медицинским консьержем (дежурным врачом/фельдшером) и AI-помощник в shadow-mode. Отделено от Фазы 1, чтобы регламенты и безопасность не задерживали релиз базы.
3. **Фаза 2 · Сегментные модули** — углубление по приоритетным группам сегментов (A → C → B → D).

### Критерии приоритета

| Критерий | Что меряем |
|---|---|
| **Охват** | Сколько пациентов клиники затронуто (в абсолюте) |
| **Глубина пользы** | Насколько закрывает реальную боль (есть ли альтернатива без нас) |
| **Частота касаний** | Как часто функция возвращает пользователя в приложение |
| **Бизнес-эффект** | Влияние на возвратность, средний чек, удержание, вклад в выручку |
| **Сложность** | Вторичная ось: усилия (вкл. зависимости от МИС и контента) |

---

## 2. Текущие функции — утилита и приоритет

### 🟢 Высокий приоритет (ядро ценности)

**Запись на приём** — главный транзакционный поток. Экономит 3–8 минут разговора, 24/7, ближайшие окна. Единственная функция, которая приводит новых пациентов через приложение. Усилить: запись из плана лечения в 1 клик (§3), запись из маршрутной карты пред-опа (§4).

**Ближайший приём** — «что со мной сейчас». Снимает тревогу «когда, куда, к кому». Перед визитом открывается 3–10 раз. Усилить: чек-лист подготовки, маршрут до кабинета, тригеры 24ч/2ч/15мин.

### 🟡 Средний приоритет (поддержка)

**Список врачей / карточка врача** — инструмент выбора при первом визите. Повторный пациент почти не открывает. Усилить: соцдоказательства, фильтр «по моему диагнозу».

**Чат с оператором** — замена звонка в регистратуру. Ограничен одним собеседником. Основное развитие — в §3.

**Профиль** — точка идентификации. Редко открывается, но критичен для персонализации.

### 🔴 Низкий приоритет (ниша)

**Семейный профиль** — высокая польза для 20–30% (родители с детьми, взрослые с пожилыми), становится критичным для сегмента «дети с аденоидами» и «сложные хроники — ЧБД».

**Контакты** — функция «галочка», 1–2 открытия за всё время.

### Вывод

Ядро «Запись + Ближайший приём» работает. Слабое место — **нет причины открывать приложение между визитами**. Это и закрывает джентльменский набор.

---

## 3. Джентльменский набор — базовые функции для всех пациентов

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

Набор сознательно разделён на две подфазы по риску и зависимостям: **транзакционная база** (детерминированные функции с понятным MVP) и **коммуникационная надстройка** (LLM и асинхронные каналы, требующие регламентов и безопасности). Это позволяет выпустить базу быстро и безопасно, а надстройку строить поверх уже стабильного фундамента.

### Фаза 1 · Транзакционная база

Функции, где пациент **что-то получает или делает** — без LLM и без диалога. Минимизируют риски, быстрее в запуск, дают те самые «не удалю это приложение»-причины.

| Функция | Статус | Что в ней |
|---|---|---|
| Запись на приём | ✅ есть | Запись 24/7, ближайшие окна. |
| Ближайший приём | ✅ есть | Что, где, когда — снимает тревогу перед визитом. |
| Чат с оператором | ✅ есть | Справки, переносы, счета, расписание (человеческий канал). |
| Статьи / база знаний | ✅ есть (Спринт 1) | Уже есть. Источник правды для будущего RAG. |
| **План лечения с приёма** | ❌ нет — фундамент | После каждого приёма структурированный чеклист: диагноз, назначения (препарат + доза + курс + календарь), ссылки на процедуры самопомощи (Группа A), контрольный приём, запись на следующий визит в 1 клик. Живой объект с напоминаниями. Источник правды для всех следующих надстроек. |
| **Результаты обследований и медкарта** | ❌ нет | Пациент видит свои анализы, аудиограммы, снимки, заключения **без звонка в клинику**. Статус каждого результата: готов / в работе / годен до [дата]. Критично для Группы C (пред-оп): срок годности анализов виден в одном месте. |
| **Заказ справок и финансовых документов** | ❌ нет | Справка для налогового вычета (13%), справки работодателю, копии заключений, счета. Заказ в 1 клик, готовая в приложении или с самовывозом. Снимает нагрузку с администраторов и даёт сильный retention-якорь даже у разовых пациентов. |

### Фаза 1.5 · Коммуникационная надстройка

Функции, где идёт **живой или AI-диалог** по поводу лечения. Строятся поверх уже работающей базы (плана лечения, медкарты, статей) и требуют отдельных регламентов — по ответственности, SLA, проверке качества.

| Функция | Статус | Что в ней | Ключевой риск |
|---|---|---|---|
| **Чат с медицинским консьержем** | ❌ нет | **Не прямой чат с лечащим врачом.** Дежурный врач / фельдшер / медсестра отвечает по протоколам на 80% рутины («можно ли совмещать с X», «нормально ли, что третий день болит», «когда повторно сдать анализ»), эскалирует клинически значимое лечащему. Асинхронно, SLA — X часов в рабочее время. | Перегрузка врачей и SLA-хаос, если пустить пациентов напрямую к хирургу. Консьерж-слой — основной буфер. Нужен регламент тарификации/компенсации врачам за эскалированные вопросы. |
| **AI-помощник (RAG 24/7)** | ❌ нет | Знает базу знаний клиники, статьи, план лечения пациента, историю приёмов. Объясняет назначение, ищет ответ в статьях, оценивает «норма или срочно» и эскалирует к консьержу/врачу при тревожных признаках. | Галлюцинация LLM в медицинском контексте = юридический и репутационный риск. **Запускаем в shadow-mode**: ответы сначала идут через консьержа для валидации, метрики точности собираются, и только после набора статистики — переход в прямой режим для безопасных категорий вопросов. |

### Почему это ядро, а не сегмент

- **Работает на 100% пациентов** — без разделения по сегменту.
- **Усиливает любое сегментное направление**: бегунок, слухопротезирование, АСИТ — всё опирается на план лечения, медкарту и тот же чат-канал.
- **Закрывает главный пробел транзакционной модели** — «что делать между визитами».
- **Частично закрывает самый массовый сегмент** (амбулаторный + хроники). Полностью закрыть их может только отдельный модуль «Процедуры самопомощи» (Группа A, §4.3) — это первый сегментный модуль после Фазы 1.5.

### Порядок работ внутри набора

**Фаза 1:**
1. **План лечения с приёма** — фундамент. Без структурированных назначений не работает ничего поверх (ни AI, ни напоминания, ни процедуры самопомощи).
2. **Результаты / медкарта** — следующий retention-якорь.
3. **Заказ справок** — быстрый win для большой части пациентов, снимает нагрузку с администраторов.

**Фаза 1.5** (после стабилизации Фазы 1):
4. **Чат с медицинским консьержем** — инфраструктура канала + регламент ответов.
5. **AI-помощник на RAG (shadow-mode)** — сначала ответы валидируются консьержем, потом постепенный переход в прямой режим для безопасных категорий.

### Критическая зависимость от МИС

«План лечения» — это структурированные данные (препарат, доза, частота, курс, процедура). Два сценария:
- **МИС отдаёт назначения по API структурированно** — план лечения собирается автоматически из данных приёма. Предпочтительно.
- **МИС отдаёт только PDF-заключение** — план лечения MVP стартует с **ручного ввода врачом в виджет** (шаблоны по нозологиям + чеклисты + автоподстановка из предыдущего приёма). Интеграция с МИС — отдельной задачей позже.

Ответ на этот вопрос определяет сроки и стоимость Фазы 1. Добавлен в §6 как первоочередной.

---

## 4. Сегменты пациентов через призму приложения

### 4.1. Фундаментальное деление: первичный vs повторный

| Линза | Первичный в приложении | Повторный в приложении |
|---|---|---|
| **Главный job** | «Куда мне обратиться и как записаться» | «Что мне делать сейчас по моему лечению» |
| **Источник** | Попадает через сайт/рекламу/сарафан | Приложение уже установлено, уведомление/сам открывает |
| **Частота открытия** | 1–3 раза до визита | Ежедневно в активном эпизоде |
| **Что нужно в приложении** | Базовый минимум (запись, цены, контакты, врачи) | Специализированный модуль сегмента |
| **Приоритет развития** | Низкий (веб и реклама работают лучше) | ● Высокий (2/3 потока) |

**Ключевое следствие.** Специализированных «первичных» модулей под каждый сегмент строить не нужно. Исключения — сегменты, где «после первого визита» начинается длинный путь: сурдология, хирургия, АСИТ. Там «первичный» в терминах клиники ≠ «первичный» в терминах приложения.

### 4.2. Матрица 10 сегментов × первичный / повторный

Из 10 сегментов бизнес-аналитики выделяем: объём × чек × что нужно в приложении для первичного × что нужно для повторного × итоговый приоритет приложения.

| # | Сегмент (из аналитики) | Объём / Вклад | Первичный в приложении | Повторный в приложении (главная работа) | Приоритет в App |
|---|---|---|---|---|:-:|
| 1 | **Взрослые «заблокированный нос»** (полипы, перегородка, FESS) | 300 оп/год · 100т · 30 млн | Джентльменский + материалы о методах (FESS/лазер), кейсы пациентов, калькулятор, **возвратные push для сомневающихся после пред-оп приёма** | Пред-оп бегунок (6 нед) → восстановление → контроль 3/6/12 мес | ● **Высокий** (Группа C) |
| 2 | **Амбулаторный поток** (острые и хроники ЛОР) | Тысячи/мес · 120 млн | Джентльменский | План лечения + эпизод лечения + дневник симптомов (§3) **+ модуль процедур самопомощи: библиотека техник (промывание носа физраствором, полоскание горла, ингаляции), напоминания, трекер комплаенса** | ● **Высший** (Группа A — отдельный модуль) |
| 3 | **Родители детей с аденоидами** | 400–500 оп/год · 60т · 20–30 млн | Джентльменский + семейный профиль + подготовка ребёнка + **материалы «нужна ли операция» и возврат сомневающихся родителей** | Пред-оп бегунок (детская версия) → восстановление. Далее — редко. | ● **Высокий** (Группа C) |
| 4 | **Потеря слуха (сурдология)** | 20 млн/год | **Нестандартный первичный:** аудиограмма в профиле, аудио-демо, каталог моделей, калькулятор, шеринг близкому, возвратные push | Паспорт аппарата, сервисный календарь, расходники, калибровка раз в год, дневник адаптации | ● **Высокий** (Группа B — уникальный модуль) |
| 5 | **Сложные хроники** (иммунология/аллергология, ЧБД) | Высокий, часть 120 млн · длинный LTV | Джентльменский + семейный (ЧБД) + запись на консилиум | Модуль процедур самопомощи (Группа A): промывания, полоскания, ингаляции у ЧБД. Плюс специализация: **АСИТ-трекер** (дневник симптомов + пыльцевой календарь + навигатор побочки) | ● **Высокий** (Группа A + Группа D) |
| 6 | **Зависимость от капель (вазотомия)** | Высокий объём · входной в хирургию | Джентльменский + материалы «как слезть с капель» + **возврат сомневающихся после пред-оп приёма** | Пред-оп бегунок (компактная версия) → восстановление | ● **Высокий** (Группа C) |
| 7 | **Пульмонология** (кашель/астма) | Средний · сезонный | Джентльменский | Дневник астмы, напоминания об ингаляторах, контроль триггеров (пересекается с АСИТ) | ◐ **Средний** (частично Группа D) |
| 8 | **Социально активные храпуны** | Низкий · высокая платёжеспособность | Джентльменский + образовательный контент о сомнологии | Сомнологический чек-up, СИПАП-трекер (если назначен) | ○ **Низкий** |
| 9 | **Фониатрия** (голос) | Очень низкий · срочный | Джентльменский + срочная запись | Короткое окно, низкая повторность | ○ **Низкий** |
| 10 | **Check-up и Второе мнение** | Единичный · высокая маржа | Джентльменский + позиционирование бренда Оленевой | Разовая услуга, минимальная повторность | ○ **Низкий** |

### 4.3. Четыре группы сегментов для повторных

**Группа A. Амбулаторный поток + хроники — процедуры самопомощи** — сегменты 2 + 5 (повторная часть). Самый массовый сегмент × ежедневная повторность.

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

**Что нужно в модуле:**
- **Библиотека техник** — короткие видео и пошаговые инструкции «как правильно». Ошибки в технике (сильный напор при промывании, не тот раствор) — частая причина, почему «не помогает».
- **Напоминания** — утро/вечер по схеме, привязаны к плану лечения.
- **Трекер комплаенса** — ежедневные отметки, стрики, сводка «сколько дней подряд».
- **Дневник симптомов в связке** — «промываю 5 дней, насморк уменьшился с 4 до 2» — главный мотиватор продолжать.
- **Сводка для врача** — перед контрольным приёмом врач видит, что пациент делал, как часто, с какой динамикой симптомов.

**Это отдельный модуль, не продолжение Фазы 1.** Он опирается на план лечения как на источник назначений, но требует собственного контента (библиотека техник) и UX (трекер).

**Группа B. Сурдология** — сегмент 4. Уникальный набор функций (аудиограмма, аудио-демо, каталог, паспорт аппарата). Пожизненная повторность. Высокий чек. **Отдельный модуль, не пересекается с другими.**

**Группа C. Пред-операционная подготовка + восстановление** — сегменты 1 + 3 + 6 (одна механика для трёх сегментов). **Две фазы, как у Группы B:**
- **Кандидаты на операцию** — после пред-оп приёма ушли «думать». Возврат через материалы, кейсы пациентов, чат с хирургом, возвратные push-триггеры (3/7/21 день), прозрачность по цене/рассрочке.
- **Решившиеся** — бегунок → чек-лист дня операции → операция → восстановление. Окно 6–12 недель.

**Один модуль закрывает три сегмента бизнес-аналитики** (FESS, детские аденоиды, вазотомия).

**Группа D. АСИТ + контроль астмы** — часть сегмента 5 + сегмент 7. Ежедневный трекер, дневник симптомов, навигатор побочки. **Самый сложный, требует верификации врачом.**

### 4.4. Что остаётся за кадром

Сегменты 8 (храпуны), 9 (фониатрия), 10 (check-up) — низкая повторность и/или низкий охват. Закрываются базовым джентльменским набором, специализированных модулей в ближайшем горизонте не требуют.

---

## 5. Порядок внедрения

### Фаза 1. Транзакционная база (§3)

План лечения → Результаты / медкарта → Заказ справок.

**Эффект:** пациент видит свои назначения, результаты и может получить документы без звонка в клинику. Это и есть базовые retention-якоря: «не удалю это приложение». Массовый амбулаторный + хроники покрыты в части информирования и документов.

**Критический параметр сроков** — структурированность назначений в МИС (см. §6 вопрос 1). От этого зависит, собирается ли план лечения автоматически или врач заполняет его вручную в виджете.

### Фаза 1.5. Коммуникационная надстройка (§3)

Чат с медицинским консьержем → AI-помощник (shadow-mode).

**Зачем отдельная подфаза:** эти функции несут организационные и юридические риски (SLA, выгорание врачей, галлюцинации LLM) и могут надолго задержать релиз, если класть в Фазу 1. Выделение в 1.5 позволяет: собрать транзакционную базу быстро и безопасно, отработать регламент консьержа отдельно, запустить AI сначала под валидацией человека.

### Фаза 2. Сегментные модули — порядок

Рекомендуемая последовательность:

**1. Группа A (Процедуры самопомощи хроников) — первым**
- **Самый массовый охват** — тысячи пациентов в месяц (сегмент 2 + 5).
- Напрямую опирается на план лечения из Фазы 1 — продолжение той же инфраструктуры.
- Средняя сложность: контент (видео-инструкции, 10–15 техник) + простой трекер + дневник симптомов.
- Бизнес-эффект: рост комплаенса → меньше обострений → меньше экстренных приёмов и операций, на которые хроники срываются, когда дома не помогает.
- Эффект заметен пациенту сразу — ежедневная польза.

**2. Группа C (Пред-операционная подготовка) — вторым**
- Закрывает 3 сегмента (1, 3, 6) одним модулем.
- Быстрый MVP — маршрутная карта с чекбоксами, сроки годности, автозапись. Восстановление уже есть в прототипе.
- Прямой измеримый бизнес-эффект: снижение переносов операций из-за просроченных анализов + возврат сомневающихся кандидатов на операцию.
- Вклад сегментов в выручку: ~50–60 млн (хирургия), плюс косвенно вазотомия как конвертер в большую хирургию.

**3. Группа B (Сурдология) — третьим**
- Изолированный сегмент с уникальными функциями.
- Пожизненное удержание × высокий чек × растущий рынок (старение).
- Две половины: возврат кандидатов после демо (высокая конверсия в деньги) + обслуживание после покупки (лояльность и LTV).
- Можно запускать параллельно с C после Фазы 1, если есть ресурс.

**4. Группа D (АСИТ + астма) — четвёртым**
- Самая высокая глубина пользы (влияет на медисход), но самая высокая ответственность.
- Требует верификации контента аллергологом/пульмонологом клиники.
- Можно начать готовить контент и интеграции параллельно с A/C/B, выпустить позже.

### Что не берём в план сейчас

- Храпуны (8), фониатрия (9), check-up (10) — специализированных модулей в горизонте планирования не делаем.
- Отдельные «первичные» модули под сегменты — не делаем. Первичный путь = джентльменский набор + базовые функции (запись, врачи, цены, контакты), которые уже есть.

### Что нужно сделать вне Фаз, уже сейчас

- **Добавить аллерголога-иммунолога в список врачей** (есть специализация, нет конкретного врача в данных). Предусловие для Группы D.

---

## 6. Вопросы к обсуждению на встрече

**Первоочередной (определяет сроки Фазы 1):**

1. **МИС и структурированные назначения.** Отдаёт ли МИС по API назначения структурированно (препарат, доза, частота, курс) или только PDF-заключением? От этого зависит: план лечения собирается автоматически или врач заполняет вручную в виджете. Там же: API для результатов анализов, сроков годности, расписания.

**По процессам клиники:**

2. **Медицинский консьерж — кто в роли?** Дежурный врач / фельдшер / медсестра? Кто держит SLA? Как компенсируется эскалация вопроса лечащему врачу?
3. **SLA чата** — целевое время ответа в рабочее время (1ч / 4ч / день)?
4. **Справки и финдокументы** — текущий процесс заказа через администратора; что готовы автоматизировать в первую очередь (ФНС-справка, выписки, счета)?

**По метрикам (для оценки эффекта):**

5. Подтвердить **«2 из 3 — повторные»** — уникальные пациенты в год или визиты? Меняет оценку охвата Группы A.
6. **Процент повторных, не доходящих до контроля** — метрика успеха Фазы 1.
7. **Сурдология** — кандидатов/мес, % возврата за аппаратом. От этого зависит приоритет Группы B.
8. **Переносы операций** — частая причина просроченные анализы? Усиливает Группу C.

**По ресурсам Фазы 1.5 и 2:**

9. Готов ли **аллерголог** верифицировать контент для АСИТ-трекера? Без этого D не запускаем.
10. База знаний / статьи — достаточно ли материала для RAG или формировать отдельно?
11. Политика по **AI shadow-mode**: кто утверждает категории вопросов для постепенного перевода в прямой режим?

---

## Приложение. Короткая сводка для слайда

**Что предлагаем:**
1. **Фаза 1** — транзакционная база для всех: план лечения, результаты/медкарта, заказ справок + уже существующие запись, ближайший приём, чат с оператором, статьи. Быстрый MVP, минимум рисков.
2. **Фаза 1.5** — коммуникационная надстройка: чат с медицинским консьержем (не прямой с врачом) и AI-помощник в shadow-mode. Запускается после стабилизации базы.
3. **Фаза 2** — четыре сегментных модуля в порядке: A (процедуры самопомощи хроников — массовый) → C (пред-оп подготовка — 3 сегмента разом) → B (сурдология — высокий чек) → D (АСИТ + астма — с верификацией врачом).
4. **Первичные в приложении** = базовый минимум, который уже есть. Новых первичных модулей не строим — они приходят через веб. Исключения — сегменты, где после первого визита пациент «уходит думать»: сурдология, хирургия, АСИТ.