Коммерческое предложение: SberCare Voice Agent
Голосовой AI-оператор записи к врачу — подтверждённая запись с первого звонка, в вашем контуре
Версия: 1.0 Дата: 24.05.2026 Клиент: СберЗдоровье Подготовил: AiDevTeam
Содержание
Обзор для собственника
Часть I: Коммерческое предложение
- О проекте
- Текущие процессы и боли
- Архитектура решения
- Пакеты услуг
- Сравнение пакетов
- Ядро системы
- Дополнительные опции
- Конфигурации и сроки
- Наша рекомендация
- Бизнес-выгоды (ROI)
Часть II: Техническое задание
- Границы MVP
- Компоненты системы
- Модель данных
- API-спецификация
- Пользовательские сценарии
- Команда проекта
- Дорожная карта и план спринтов
- Предварительные исследования
- Стратегия тестирования
- Развёртывание и инфраструктура
- Критерии приёмки
- Нефункциональные требования
Часть III: Коммерческие условия
- Как мы работаем
- Условия оплаты
- Ежемесячные расходы
- Риски и митигация
- Гарантии
- Требования к клиенту
- Что не входит
- Открытые вопросы и наши допущения
- Перспективы развития
- Глоссарий
- Следующие шаги
Главное
Допущение об источнике. Это предложение подготовлено по итогам встречи 12.05.2026. Часть параметров (объёмы звонков, телефонная платформа, аппаратные ресурсы) ещё не подтверждена — мы отметили их как наши допущения в разделе 30 и рассчитали решение по инженерным дефолтам. После подтверждения цифры калибруются без пересмотра архитектуры.
Ситуация
В СберЗдоровье значительная доля записей идёт через колл-центр. В пиковые часы человеческий ресурс ограничен — звонки уходят в очередь или теряются. Отдельная сложность, которую видно даже в публичных отзывах пациентов: звонок часто заканчивается не записью, а заявкой — после чего администратор клиники перезванивает повторно, и пациент диктует свои данные дважды. Это удлиняет путь, роняет конверсию в запись и нагружает линию.
Что вы получите
| # | Результат | Эффект |
|---|---|---|
| 1 | Голосовой оператор перехватывает перелив звонков в пик и записывает пациента сам | Линия перестаёт терять звонки в часы нагрузки |
| 2 | Подтверждённая запись с первого звонка, без повторного перезвона | Короче путь пациента, выше конверсия в фактическую запись |
| 3 | Всё работает в вашем контуре на открытых моделях | Данные пациентов не покидают периметр, нет внешних зависимостей |
| 4 | Сбор CSI и полный журнал каждого диалога | Видно качество и точки роста с первого дня |
Структура предложения
Мы предлагаем MVP по вашему ТЗ — голосовой оператор, который сам записывает пациента в подходящую клинику в основных сценариях, — и два пакета расширения для тех, кто хочет сразу заложить контроль качества, краевые сценарии и масштабирование. Каждый пакет — законченный работающий продукт: можно остановиться на любом уровне.
Почему AiDevTeam
- Глубокая проработка под on-premise и открытые модели. Мы спроектировали решение под жёсткое требование «всё в вашем контуре, только открытые модели, задержка меньше секунды» — это не адаптация облачного бота, а архитектура под ваши ограничения.
- Реалистичная инженерия задержки. Голосовой диалог «живой» только при ответе быстрее секунды. Мы используем связку из быстрой основной модели для онлайн-реплик и тяжёлой модели для сложных случаев — это позволяет держать скорость без потери качества.
- Прозрачная экономика. Расчёт по ролям и часам, без «средней ставки». Вы видите, за что платите, и можете обсуждать состав команды.
- Совместимость с вашей экосистемой. Решение спокойно живёт рядом с вашими речевыми и языковыми сервисами и при необходимости интегрируется с ними (доступно как опция).
Для открытого тендера мы рекомендуем стартовать с пакета MVP и подготовить рабочий демо-стенд — детали в разделе 9.
Как читать этот документ
| Кому | Разделы | Что узнаете |
|---|---|---|
| Собственнику / руководителю | «Что вы получаете на каждом тарифе», 1, 4, 9, 10 | Что меняется, сколько стоит, что рекомендуем |
| Техническому руководителю | 3, 11–22 | Архитектура, компоненты, API, тестирование, развёртывание |
| Закупкам / юристам | 23–33 | Оплата, риски, гарантии, требования, согласия |
Что вы получаете на каждом тарифе
Обзор для руководителя. Без технических терминов — только то, что меняется в работе колл-центра и что вы получаете взамен.
MVP «Запись с первого звонка» • 10–12 недель ⭐ Рекомендуем для тендера
Что меняется в работе: в часы пиковой нагрузки звонки, которые сейчас уходят в очередь, перехватывает голосовой оператор и доводит пациента до подтверждённой записи сам.
| Сейчас | После (MVP) |
|---|---|
| В пик часть звонков теряется или ждёт в очереди дольше нормы | Перелив перехватывается, пациент не висит в очереди |
| Звонок часто завершается «заявкой», клиника перезванивает повторно | Запись подтверждается голосом в этом же звонке |
| Оператор тратит ~5–7 минут на типовую запись | Типовая запись проходит за время разговора, без участия человека |
Что получаете: автоматическую обработку основных сценариев записи (подбор врача/клиники, время, локация), мягкую передачу сложных случаев на живого оператора, сбор CSI и журнал каждого диалога. Всё — в вашем контуре, на открытых моделях, с ответом быстрее секунды.
Чего ещё нет: автоматической отмены и переноса записи, проговаривания подготовки к визиту, дашборда аналитики, масштабирования на сотни параллельных линий — это пакеты 2 и 3.
Когда брать: когда нужно закрыть основной сценарий записи и выйти на тендер с рабочим решением. Это ваш базовый объём по ТЗ.
Окупаемость: на снижении нагрузки на колл-центр в пик и росте доли доведённых до записи звонков.
Пакет 2 «Контроль качества и краевые сценарии» • +4–5 недель к MVP
Что меняется в работе: оператор не только записывает, но и закрывает отмену/перенос, проговаривает подготовку к визиту и даёт руководителю видимость качества.
| До (MVP) | После (Пакет 2) |
|---|---|
| Отмена и перенос — только через живого оператора | Оператор сам отменяет и переносит запись |
| Пациент не всегда знает о подготовке к визиту (анализы до приёма) | Оператор проговаривает обязательную подготовку |
| Качество диалогов видно только выборочно | Дашборд CSI и аналитика по всем диалогам, A/B-тест формулировок |
Что получаете: закрытие краевых сценариев, дашборд качества, фреймворк улучшения диалогов, подтверждение статуса записи и направлений. Для сложных диалогов подключается тяжёлая модель — выше точность на нестандартных обращениях.
Чего ещё нет: масштабирования на сотни линий с отказоустойчивостью, дообучения на ваших диалогах, готовности к подключению ГосСОПКА — это пакет 3.
Когда брать: когда после MVP хотите снять с операторов ещё и отмены/переносы и получить управляемое качество.
Окупаемость: на дополнительном снятии нагрузки (отмены/переносы — заметная доля обращений) и на росте явок за счёт проговаривания подготовки.
Пакет 3 «Масштаб и автономность» • +5–6 недель к Пакету 2
Что меняется в работе: решение готово держать сотни параллельных линий, учится на ваших диалогах и соответствует повышенной дисциплине информационной безопасности.
| До (Пакет 2) | После (Пакет 3) |
|---|---|
| Контур рассчитан на десятки параллельных линий | Сотни параллельных линий, отказоустойчивость с резервированием |
| Качество растёт за счёт ручной настройки формулировок | Решение дообучается на обезличенных диалогах, качество растёт само |
| Базовое журналирование | Расширенный мониторинг, алертинг, готовность к подключению ГосСОПКА |
Что получаете: масштаб до сотен сессий, отказоустойчивость, дообучение на собственных диалогах, расширенный мониторинг, готовность к КИИ-дисциплине, мультиголосовые профили.
Чего ещё нет: это полная конфигурация под основной сценарий записи. Дальнейшее развитие — отдельные опции (раздел 7) и новые направления.
Когда брать: когда решение прошло пилот и вы выводите его на весь объём колл-центра.
Окупаемость: на полном переводе пиковой нагрузки в автономный режим без расширения штата операторов.
Сравнительная сводка по эффекту
| Метрика | Сейчас | MVP | Пакет 2 | Пакет 3 |
|---|---|---|---|---|
| Перехват переливных звонков в пик | нет | да | да | да |
| Подтверждённая запись с первого звонка | частично | да | да | да |
| Отмена / перенос записи без оператора | нет | нет | да | да |
| Проговаривание подготовки к визиту | нет | нет | да | да |
| Дашборд качества и аналитика диалогов | нет | базовый CSI | полный | полный |
| Параллельных голосовых линий | — | десятки | десятки | сотни |
| Дообучение на ваших диалогах | нет | нет | нет | да |
| Готовность к КИИ-дисциплине / ГосСОПКА | — | базовая | базовая | расширенная |
1. О проекте
СберЗдоровье — одна из крупнейших цифровых медицинских платформ страны: более 20 млн пользователей, свыше 100 тыс. врачей в каталоге, тысячи клиник-партнёров. Значимая доля записей проходит через колл-центр, и именно эта линия в пиковые часы упирается в предел человеческого ресурса.
Задача проекта — голосовой AI-оператор, который в моменты высокой нагрузки перехватывает входящий звонок, собирает первичный запрос пациента (направление, причина обращения, удобные время и локация), по вашей базе подбирает подходящего врача или клинику, оформляет запись и подтверждает её голосом в том же звонке. Там, где автоматическая обработка невозможна, оператор мягко передаёт диалог живому сотруднику.
Ключевые ограничения, заданные вами, — это фундамент архитектуры:
- Только в вашем контуре (on-premise), без внешних API-вызовов;
- Только открытые модели, разворачиваемые на ваших серверах;
- Задержка ответа меньше секунды (цель — около полусекунды);
- Поддержка перебивания — пациент может прервать оператора в любой момент;
- Естественный женский голос;
- Только голосовой канал — без мессенджеров и SMS.
MVP сознательно ограничен основными сценариями записи. Отмена, перенос и другие краевые случаи вынесены в пакеты расширения — это соответствует вашему видению поэтапного развития.
2. Текущие процессы и боли
Мы опираемся на ваше описание задачи и на публично наблюдаемый опыт пациентов. Ниже — сопоставление проблем и того, как их закрывает голосовой оператор.
| Проблема | Решение |
|---|---|
| В пиковые часы колл-центр перегружен, часть звонков уходит в очередь или теряется | Оператор перехватывает переливной звонок и обрабатывает его без ожидания |
| Звонок часто заканчивается «заявкой», а не записью — клиника перезванивает повторно | Оператор оформляет и подтверждает запись голосом в том же звонке |
| Пациент диктует свои данные дважды (оператору и затем клинике) | Данные собираются один раз, запись уходит в систему сразу |
| Типовая запись занимает время живого оператора | Типовые сценарии полностью автоматизированы, оператор подключается только к сложным |
| Нагрузка на линию растёт быстрее, чем штат | Автономная обработка пиков без расширения штата |
Голосовой канал выбран как основной осознанно: именно через звонок идёт значимая доля записей, и именно он сильнее всего страдает в пик.
3. Архитектура решения
Решение — это конвейер реального времени, полностью разворачиваемый в вашем контуре. Входящий звонок по телефонной линии попадает к голосовому оператору; речь распознаётся потоково, языковая модель ведёт диалог и обращается к вашей базе через программный интерфейс, ответ озвучивается естественным голосом. При необходимости звонок мягко передаётся живому оператору.
flowchart TB
subgraph Phone["Телефония"]
SIP["Входящий звонок"]
OP["Живой оператор"]
end
subgraph Core["Контур СберЗдоровья (on-premise)"]
ORCH["Оркестратор диалога"]
STT["Распознавание речи"]
LLM["Языковая модель"]
TTS["Синтез речи"]
TOOL["Доступ к базе по API"]
LOG["Журнал и запись"]
end
subgraph Data["Ваши системы"]
DB["База врачей и услуг"]
MIS["Система записи клиник"]
end
SIP --> ORCH
ORCH --> STT
STT --> LLM
LLM --> TTS
TTS --> ORCH
LLM --> TOOL
TOOL --> DB
TOOL --> MIS
ORCH --> LOG
ORCH -->|"сложный случай"| OP
style Phone fill:#172554,stroke:#3b82f6
style Core fill:#14532d,stroke:#22c55e
style Data fill:#78350f,stroke:#f59e0b
Принципы архитектуры:
- Скорость через гибрид моделей. Основную массу реплик ведёт быстрая компактная модель — она укладывается в субсекундный ответ. Сложные и неоднозначные обращения обрабатывает более тяжёлая модель (подключается в пакете 2). Это даёт «живой» диалог без потери качества на нестандартных случаях.
- Прямой доступ к базе без избыточного усложнения. Оператор обращается к вашей структурированной базе напрямую по программному интерфейсу — без тяжёлого семантического поискового слоя, который удорожил бы и замедлил решение. Это соответствует вашему требованию.
- Потоковая обработка для перебивания. Речь распознаётся и озвучивается потоково — пациент может прервать оператора в любой момент, и диалог продолжится с места остановки.
- Всё в периметре. Распознавание, языковая модель, синтез — открытые модели на ваших серверах. Данные пациентов не покидают контур.
4. Пакеты услуг
Каждый пакет включает Ядро системы (раздел 6) и всё из предыдущих пакетов. Цены указаны за разработку и запуск; серверные мощности (GPU) предоставляет клиент — это ваш CAPEX, в стоимость не входит.
4.1. Пакет «MVP» — Запись с первого звонка
Модули и критерии приёмки:
| Модуль | Критерий приёмки |
|---|---|
| Перехват переливного звонка по телефонной линии | Звонок при заданном условии перенаправляется на оператора за ≤ 2 сек |
| Сбор первичного запроса (направление, причина, время, локация) | Оператор корректно извлекает 4 ключевых параметра в ≥ 90% тестовых диалогов |
| Подбор врача/клиники по базе через API | По запросу возвращается релевантный врач/слот с учётом времени и локации |
| Оформление и подтверждение записи голосом | Запись уходит в систему и подтверждается голосом в том же звонке |
| Передача сложного случая живому оператору | При невозможности обработки звонок передаётся за ≤ 5 сек с сохранением контекста |
| Поддержка перебивания | Оператор останавливается при перебивании и продолжает ветку с места остановки |
| Сбор CSI | По завершении звонка фиксируется оценка удовлетворённости |
| Журнал и запись разговоров с согласием | Каждый диалог записан, есть транскрипт и журнал решений; в начале звонка — уведомление о записи |
Бизнес-выгоды:
- Перехват пиковой нагрузки без расширения штата операторов
- Рост доли звонков, доведённых до фактической записи
- Сокращение пути пациента — без повторного перезвона
- Прозрачное качество с первого дня (CSI + журнал)
Стоимость: 5 300 000 руб · Срок: 10–12 недель
4.2. Пакет «Контроль качества и краевые сценарии»
Включает всё из MVP +
Дополнительные модули:
| Модуль | Критерий приёмки |
|---|---|
| Отмена записи голосом | Оператор находит активную запись пациента и отменяет её с подтверждением |
| Перенос записи голосом | Оператор предлагает доступные слоты и переносит запись |
| Проговаривание подготовки к визиту | Перед записью на приём, требующий подготовки, оператор озвучивает требования |
| Дашборд качества и аналитики диалогов | Руководитель видит CSI, доли автоматизации, типовые сценарии, проблемные диалоги |
| A/B-тестирование формулировок | Возможность сравнить две версии скрипта по конверсии и CSI |
| Подтверждение статуса записи и направлений | Оператор отвечает на вопрос «я записан?» и проговаривает статус |
| Тяжёлая модель для сложных диалогов | Нестандартные обращения обрабатываются с повышенной точностью |
Что вы НЕ получаете в этом пакете:
| Без этого | Цена бездействия |
|---|---|
| Нет масштабирования на сотни линий с резервированием | При росте объёма пик снова упрётся в потолок мощности |
| Нет дообучения на ваших диалогах | Качество растёт только вручную, медленнее |
| Нет расширенной ИБ-готовности (ГосСОПКА) | При категорировании объекта КИИ потребуется доработка |
Бонусы (бесплатно):
- Перенос и нормализация тестового каталога услуг для пилота (обычно ~120 000 руб)
- 1 кастомный отчёт по дизайну вашей аналитики (обычно ~90 000 руб)
Общая ценность бонусов: ~210 000 руб (бонусы ~210 000 руб) + скидка 5%.
Стоимость: 6 920 000 руб 7 280 000 руб (скидка 5%) · Срок: +4–5 недель к MVP
4.3. Пакет «Масштаб и автономность»
Включает всё из пакета 2 +
Дополнительные модули:
| Модуль | Критерий приёмки |
|---|---|
| Масштабирование до сотен параллельных сессий | Контур стабильно держит целевое число одновременных линий под нагрузочным тестом |
| Отказоустойчивость с резервированием (N+1) | При отказе узла сервис продолжает работу без потери активных звонков |
| Дообучение на обезличенных диалогах | Подготовлен корпус и процесс дообучения, качество измеримо растёт между итерациями |
| Расширенный мониторинг и алертинг | Дашборд состояния контура, оповещения о деградации задержки/качества |
| Готовность к подключению ГосСОПКА | Журналирование и форматы готовы к требованиям значимого объекта КИИ |
| Мультиголосовые профили | Возможность нескольких голосовых профилей оператора |
Бонусы (бесплатно):
- Все бонусы пакета 2
- Нагрузочное тестирование на целевой объём (обычно ~180 000 руб)
- Обучение вашей команды эксплуатации и сопровождению (обычно ~150 000 руб)
- Бонус на будущую разработку: 400 000 руб на новые модули и интеграции (12 месяцев, покрывает до 50% нового заказа)
Общая ценность бонусов: ~730 000 руб + скидка 10%.
Стоимость: 8 620 000 руб 9 570 000 руб (скидка 10%) · Срок: +5–6 недель к Пакету 2
5. Сравнение пакетов
| Возможность | MVP | Пакет 2 | Пакет 3 |
|---|---|---|---|
| Перехват переливных звонков | ✅ | ✅ | ✅ |
| Сбор запроса и подбор врача/клиники | ✅ | ✅ | ✅ |
| Запись и подтверждение голосом | ✅ | ✅ | ✅ |
| Передача на живого оператора | ✅ | ✅ | ✅ |
| Поддержка перебивания | ✅ | ✅ | ✅ |
| Сбор CSI | базовый | ✅ | ✅ |
| Журнал и запись разговоров | ✅ | ✅ | ✅ |
| Отмена / перенос записи | — | ✅ | ✅ |
| Проговаривание подготовки к визиту | — | ✅ | ✅ |
| Дашборд аналитики диалогов | — | ✅ | ✅ |
| A/B-тест формулировок | — | ✅ | ✅ |
| Тяжёлая модель для сложных диалогов | — | ✅ | ✅ |
| Масштаб до сотен сессий | — | — | ✅ |
| Отказоустойчивость N+1 | — | — | ✅ |
| Дообучение на ваших диалогах | — | — | ✅ |
| Расширенный мониторинг / ГосСОПКА-готовность | — | — | ✅ |
| Бонус на будущую разработку | — | — | 400 000 ₽ |
| Стоимость | 5 300 000 ₽ | 6 920 000 ₽ | 8 620 000 ₽ |
6. Ядро системы
Ядро — это фундамент, который входит в каждый пакет. Без него система не работает.
| # | Компонент | Описание |
|---|---|---|
| Я1 | Контурная инфраструктура | Развёртывание в вашем периметре, контейнеризация, изоляция, журналирование |
| Я2 | Подключение к телефонии | Приём входящего звонка по телефонной линии, перехват перелива, медиасессия |
| Я3 | Распознавание речи (потоковое) | Русскоязычное потоковое распознавание под телефонию, с поддержкой перебивания |
| Я4 | Языковое ядро диалога | Открытая модель + логика ведения диалога, обращение к базе по программному интерфейсу |
| Я5 | Синтез речи | Естественный женский голос, потоковый синтез |
| Я6 | Доступ к базе и запись | Подбор по базе врачей/услуг, оформление записи, передача в систему клиник |
| Я7 | Журнал, запись и согласие | Запись разговоров, транскрипты, журнал решений, уведомление о записи |
Ядро спроектировано под ваши требования: всё в контуре, открытые модели, субсекундная задержка, перебивание.
7. Дополнительные опции
Независимые модули — можно добавить к любому пакету. Это возможности, которые выведут проект на новый уровень.
| # | Опция | Что даёт | Часы | Стоимость | Срок | Wow |
|---|---|---|---|---|---|---|
| О1 | Совместимость с речевыми и языковыми сервисами вашей экосистемы | Возможность использовать ваши корпоративные модели как движок — путь миграции с открытых моделей | 180 ч | 530 000 ₽ | 2–3 нед | Open-source для пилота, ваша экосистема — в проде, без переписывания |
| О2 | Исходящий голосовой робот (напоминания и подтверждения) | Обзвон пациентов: напоминание о записи, подтверждение, перенос | 200 ч | 580 000 ₽ | 3 нед | Меньше неявок — по рынку до 2 раз |
| О3 | Интеграция с несколькими системами записи клиник | Единый оператор поверх разных МИС клиник-партнёров | 240 ч | 700 000 ₽ | 3–4 нед | Один оператор — вся сеть клиник, без ручной маршрутизации |
| О4 | Голосовая идентификация пациента | Узнавание пациента по голосу с защитой от подделки | 180 ч | 620 000 ₽ | 3 нед | Пациент не диктует данные заново — система узнаёт его |
Как считаются опции. Каждая опция — это мини-проект (2–4 недели), а не «быстрая доработка». Часы декомпозированы по подзадачам, применены те же ставки, что и в пакетах, добавлены буфер на интеграцию с внешними сервисами и контингенция. Пример декомпозиции для О1 (совместимость с вашей экосистемой):
| Подзадача | Часы |
|---|---|
| Адаптер к корпоративному языковому сервису (контракт API, аутентификация) | 50 |
| Адаптер к речевым сервисам (распознавание + синтез) | 50 |
| Слой маршрутизации (переключение открытая ↔ корпоративная модель) | 30 |
| Совместимость форматов обращения к функциям | 20 |
| Тестирование на паритет качества (слепое сравнение) | 30 |
| Итого | 180 |
8. Конфигурации и сроки
| Конфигурация | Состав | Срок | Стоимость |
|---|---|---|---|
| MVP | Ядро + основной сценарий записи | 10–12 нед | 5 300 000 ₽ |
| MVP + О1 | + совместимость с экосистемой | 12–14 нед | 5 830 000 ₽ |
| Пакет 2 | MVP + качество + краевые сценарии | 14–17 нед | 6 920 000 ₽ |
| Пакет 2 + О2 | + исходящий робот напоминаний | 16–19 нед | 7 500 000 ₽ |
| Пакет 3 | Всё + масштаб + автономность | 19–23 нед | 8 620 000 ₽ |
| Пакет 3 + О1 + О3 | Полная конфигурация с экосистемой и мультиклиниками | 24–28 нед | 9 850 000 ₽ |
Сроки указаны от старта разработки. Для тендера отдельно готовится демо-стенд (раздел 9) — его срок короче, 3–4 недели.
9. Наша рекомендация
Тендер объявлен по MVP, поэтому базовая рекомендация — стартовать с пакета MVP:
- Это ровно ваш объём по ТЗ: основной сценарий записи, on-premise, открытые модели, субсекундная задержка, перебивание.
- Под тендер мы готовим рабочий демо-стенд (3–4 недели) — реальный звонок на тестовый номер с прохождением сценария записи на обезличенном каталоге. Это сильнее видеопрезентации и снимает вопрос «а оно вообще работает».
- После пилота естественный следующий шаг — Пакет 2: он закрывает отмены/переносы (заметная доля обращений) и даёт руководителю видимость качества.
Если приоритет — сразу заложить максимум и не возвращаться к доработкам, оптимальна связка Пакет 2 + опция О1 (совместимость с вашей экосистемой): она снимает основной вопрос закупочного комитета о стеке.
10. Бизнес-выгоды (ROI)
| # | Выгода | Описание |
|---|---|---|
| 1 | Перехват пиковой нагрузки | Переливные звонки обрабатываются автономно, без расширения штата операторов |
| 2 | Рост конверсии в фактическую запись | Подтверждение в первом звонке убирает потери на этапе «заявка → перезвон» |
| 3 | Сокращение пути пациента | Нет двойного перезвона и повторного диктования данных |
| 4 | Снижение неявок (с опцией О2) | Исходящие напоминания и подтверждения — по рынку до 2 раз меньше неявок |
| 5 | Управляемое качество | CSI и аналитика диалогов с первого дня; в пакете 2 — полный дашборд |
| 6 | Контроль данных | Всё в вашем периметре, открытые модели, нет внешних зависимостей |
Точная окупаемость считается по вашим данным (объём звонков, стоимость минуты оператора, текущая конверсия). Мы готовы построить расчёт после подтверждения метрик из раздела 30.
Часть II: Техническое задание
11. Границы MVP
MVP покрывает основной сценарий записи и сознательно не включает краевые случаи — это соответствует вашему видению поэтапного развития.
Входит в MVP:
| ID | Компонент | Зависимости |
|---|---|---|
| M1 | Перехват переливного звонка по телефонной линии | Я2 |
| M2 | Потоковое распознавание речи пациента | Я3 |
| M3 | Диалог сбора запроса (направление, причина, время, локация) | Я4, M2 |
| M4 | Подбор врача/клиники по базе через API | Я6, M3 |
| M5 | Оформление и подтверждение записи голосом | Я6, Я5, M4 |
| M6 | Передача сложного случая живому оператору | Я2, M3 |
| M7 | Поддержка перебивания | Я3, Я5 |
| M8 | Сбор CSI | Я7, M5 |
| M9 | Журнал, запись разговоров, согласие | Я7 |
Не входит в MVP (пакеты расширения / опции):
- Отмена и перенос записи (Пакет 2)
- Проговаривание подготовки к визиту (Пакет 2)
- Дашборд аналитики, A/B-тест (Пакет 2)
- Масштабирование на сотни сессий, отказоустойчивость, дообучение (Пакет 3)
- Исходящие звонки, мультиклиники, голосовая биометрия (опции)
12. Компоненты системы
12.1. Подключение к телефонии и перехват
Назначение: принять входящий звонок и при заданном условии (перегрузка, отсутствие свободного оператора, нерабочие часы) перенаправить его на голосового оператора; уметь мягко передать звонок обратно живому сотруднику.
flowchart LR
CALL["Входящий звонок"] --> ACD["Маршрутизация колл-центра"]
ACD -->|"перелив"| AGENT["Голосовой оператор"]
ACD -->|"норма"| HUMAN["Живой оператор"]
AGENT -->|"сложный случай"| HUMAN
style CALL fill:#172554,stroke:#3b82f6
style AGENT fill:#14532d,stroke:#22c55e
style HUMAN fill:#78350f,stroke:#f59e0b
Технологии: стандартное подключение по телефонному протоколу (SIP), приём медиапотока, передача звонка (тёплая — с сохранением контекста, и холодная — мгновенная). Поддержка тонального набора, шумоподавление, эхоподавление.
Пример: в 18:40 (вечерний пик) свободных операторов нет, звонок уходит на голосового оператора за ≤ 2 сек.
12.2. Потоковое распознавание речи
Назначение: распознавать речь пациента в реальном времени, кусками по доли секунды, чтобы оператор мог реагировать быстро и корректно обрабатывать перебивание.
Технологии: русскоязычная потоковая модель распознавания, оптимизированная под телефонию (сжатый звук, шум линии). Обработка короткими окнами, выдача промежуточных гипотез.
Бенчмарк (ориентир): для русской телефонии целевая точность распознавания на уровне лучших открытых моделей; задержка распознавания — сотни миллисекунд, а не секунды.
12.3. Языковое ядро диалога
Назначение: вести диалог, извлекать параметры запроса, принимать решение об обращении к базе и формулировать ответ.
flowchart TB
IN["Реплика пациента"] --> FAST["Быстрая модель (онлайн)"]
FAST -->|"типовой случай"| ACT["Действие: запрос к базе / ответ"]
FAST -->|"сложный случай"| HEAVY["Тяжёлая модель"]
HEAVY --> ACT
style IN fill:#172554,stroke:#3b82f6
style FAST fill:#14532d,stroke:#22c55e
style HEAVY fill:#3b0764,stroke:#a855f7
Технологии: гибрид из быстрой компактной модели (ведёт основную массу реплик в субсекундном бюджете) и тяжёлой модели для сложных диалогов (подключается в Пакете 2). Обращение к базе — через прямой программный интерфейс, без семантического поискового слоя.
Почему так: одиночная тяжёлая модель не укладывается в задержку меньше секунды на онлайн-реплике. Гибрид даёт скорость на типовом потоке и качество на исключениях.
12.4. Синтез речи
Назначение: озвучивать ответы оператора естественным женским голосом, потоково, с возможностью мгновенной остановки при перебивании.
Технологии: открытая модель синтеза с женским голосом, потоковая выдача по фразам. Синтез не является узким местом по задержке (десятки миллисекунд на первую фразу) и может работать на CPU или недорогой линии GPU.
12.5. Доступ к базе и оформление записи
Назначение: по собранным параметрам найти подходящего врача/клинику и оформить запись в системе.
Технологии: программный интерфейс к вашей структурированной базе врачей и услуг (≈ 520 тыс. записей), правила подбора (локация, доступность слота, при необходимости — ДМС и рейтинг), передача записи в систему клиники. Целевая задержка запроса к базе — до 150–200 мс, чтобы уложиться в общий бюджет диалога.
12.6. Журнал, запись и согласие
Назначение: хранить аудиозапись, транскрипт и журнал решений каждого звонка в вашем периметре; в начале звонка проигрывать уведомление о записи и обработке данных.
Технологии: покомпонентная запись аудио в хранилище внутри контура, транскрипт и журнал tool-вызовов в транзакционной базе, аналитический слой для отчётности. Для дообучения (Пакет 3) формируется отдельный обезличенный корпус.
13. Модель данных
Контракт между распознаванием, диалогом и записью описывается структурой запроса пациента. Пример (упрощённо):
{
"call_id": "c-2026-0612-184011",
"intent": "booking",
"patient_request": {
"specialty": "гастроэнтеролог",
"reason_text": "боли в желудке вторую неделю",
"preferred_time": { "from": "2026-06-13T09:00", "to": "2026-06-15T20:00" },
"location": { "city": "Москва", "near": "м. Тульская", "radius_km": 5 }
},
"matched_slot": {
"doctor_id": "d-88123",
"clinic_id": "cl-4471",
"datetime": "2026-06-13T11:30",
"address": "Москва, ул. Тульская, 10"
},
"booking_status": "confirmed",
"escalation": null,
"csi": null
}
Поля matched_slot, booking_status заполняются после обращения к базе и оформления записи; escalation — при передаче живому оператору; csi — по завершении звонка.
14. API-спецификация
Минимальный контракт интеграции с вашими системами (точные форматы согласуются на старте):
| Метод | Назначение | Запрос → Ответ |
|---|---|---|
searchDoctors |
Подбор врача/клиники | параметры запроса → список слотов |
createBooking |
Оформление записи | слот + пациент → статус записи |
getBookingStatus |
Статус записи (Пакет 2) | идентификатор → статус |
cancelBooking |
Отмена (Пакет 2) | идентификатор → результат |
rescheduleBooking |
Перенос (Пакет 2) | идентификатор + новый слот → результат |
transferToOperator |
Передача живому оператору | контекст звонка → подтверждение |
Пример ответа searchDoctors:
{
"slots": [
{ "doctor_id": "d-88123", "clinic_id": "cl-4471", "datetime": "2026-06-13T11:30", "distance_km": 1.2 },
{ "doctor_id": "d-90011", "clinic_id": "cl-4480", "datetime": "2026-06-13T14:00", "distance_km": 3.8 }
]
}
Коды ошибок: 404 — нет подходящих слотов (оператор предлагает альтернативу), 409 — слот занят (повторный подбор), 503 — система записи недоступна (передача оператору).
15. Пользовательские сценарии
Сценарий 1 — Базовая запись. Как пациент, я хочу записаться к врачу по телефону, не дожидаясь оператора.
- Дано: колл-центр перегружен, звонок ушёл на голосового оператора.
- Когда: пациент называет направление, причину, удобное время и район.
- Тогда: оператор подбирает врача, оформляет запись и подтверждает её голосом в этом же звонке.
Сценарий 2 — Нет подходящего слота. Как пациент, я хочу узнать ближайшую альтернативу, если на нужное время мест нет.
- Дано: на запрошенное время слотов нет.
- Когда: оператор сообщает об этом.
- Тогда: предлагает ближайшие альтернативы по времени/локации.
Сценарий 3 — Перебивание. Как пациент, я хочу прервать оператора и уточнить запрос.
- Дано: оператор озвучивает варианты.
- Когда: пациент перебивает («лучше у метро Тульская»).
- Тогда: оператор останавливается, учитывает уточнение и продолжает ветку.
Сценарий 4 — Сложный случай. Как пациент со сложным запросом, я хочу попасть к живому оператору.
- Дано: запрос выходит за рамки автоматической обработки.
- Когда: оператор это определяет.
- Тогда: звонок передаётся живому сотруднику с сохранением контекста за ≤ 5 сек.
Сценарий 5 — Отмена записи (Пакет 2). Как пациент, я хочу отменить запись по телефону.
- Дано: у пациента есть активная запись.
- Когда: пациент просит отменить.
- Тогда: оператор находит запись, отменяет и подтверждает голосом.
Сценарий 6 — Подготовка к визиту (Пакет 2). Как пациент, я хочу знать, что нужно сделать до приёма.
- Дано: приём требует подготовки (анализы до визита).
- Когда: запись оформлена.
- Тогда: оператор проговаривает обязательную подготовку.
16. Команда проекта
Роли и ставки:
| Роль | Основные задачи | Ставка, ₽/ч |
|---|---|---|
| AI-архитектор / Tech Lead | Архитектура, гибрид моделей, контракт интеграции | 3 500 |
| AI/ML инженер | Диалоговая логика, распознавание/синтез, промпты, дообучение | 2 800 |
| Senior Backend | Интеграция с базой и системой записи, оркестрация, журнал | 2 450 |
| DevOps | On-premise развёртывание, контейнеризация, hardening, мониторинг | 2 450 |
| QA-инженер | Тестирование точности, нагрузки, сценариев | 2 100 |
| Project Manager | Коммуникация, демо-стенд, приёмка | 2 450 |
Калькуляция стоимости MVP:
| Статья | Часы | Ставка | Сумма |
|---|---|---|---|
| AI/ML инженер | 520 | 2 800 | 1 456 000 |
| Senior Backend | 650 | 2 450 | 1 592 500 |
| DevOps | 190 | 2 450 | 465 500 |
| QA-инженер | 142 | 2 100 | 298 200 |
| AI-архитектор / Tech Lead | 118 | 3 500 | 413 000 |
| Project Manager | 165 | 2 450 | 404 250 |
| Итого разработка | 1 785 | 4 629 450 | |
| Непредвиденные расходы (15%) | 694 418 | ||
| ИТОГО MVP (округлённо) | 5 300 000 |
Калькуляция расширений (нарастающим итогом):
| Пакет | Доп. часы | Доп. стоимость | Итого пакет |
|---|---|---|---|
| MVP | 1 785 | — | 5 300 000 |
| + Пакет 2 (качество, краевые сценарии) | ~660 | +1 620 000 | 6 920 000 |
| + Пакет 3 (масштаб, автономность) | ~770 | +1 700 000 | 8 620 000 |
Ставки указаны без выделения «средней» — вы видите вклад каждой роли. Цены расширений уже учитывают прогрессивные скидки (5% и 10%).
17. Дорожная карта и план спринтов
gantt
title Дорожная карта MVP
dateFormat YYYY-MM-DD
excludes weekends
section Подготовка
Архитектура и контур :a1, 2026-06-02, 7d
Демо-стенд для тендера :a2, after a1, 12d
section Ядро
Телефония и распознавание :b1, after a1, 12d
Языковое ядро и диалог :b2, after b1, 14d
Синтез речи и перебивание :b3, after b1, 10d
section Интеграции
Доступ к базе и запись :c1, after b2, 12d
Эскалация и журнал :c2, after c1, 8d
section Запуск
Тестирование и приёмка :d1, after c2, 10d
Развёртывание в контуре :d2, after d1, 6d
Ключевые вехи:
- Неделя 3–4: рабочий демо-стенд для тендера (реальный звонок на тестовый номер).
- Неделя 6: ядро — приём звонка, распознавание, диалог, синтез.
- Неделя 9: интеграция с базой и оформление записи.
- Неделя 10–12: тестирование, приёмка, развёртывание.
Срок «MVP в текущем квартале» технически достижим для демо-стенда; полный MVP реалистично завершить за 10–12 недель от старта разработки. Точные даты привяжем к дате подписания.
18. Предварительные исследования
К моменту подготовки предложения мы провели исследование рынка, технологий и регуляторной рамки:
| # | Тема | Ключевой результат |
|---|---|---|
| 1 | Открытые модели распознавания русской телефонной речи | Подобраны модели с задержкой в сотни мс и высокой точностью на телефонии |
| 2 | Бюджет задержки субсекундного диалога | Подтверждена достижимость < 1 сек на гибриде моделей; одиночная тяжёлая модель не укладывается |
| 3 | Открытый синтез женского голоса | Подобрана модель с естественным голосом и минимальной задержкой |
| 4 | Регуляторная рамка (ПДн, медтайна, КИИ) | Определены границы: организационная маршрутизация, не диагностика; контур закрывает локализацию данных |
| 5 | Ёмкость на узел и масштабирование | Рассчитано число параллельных сессий на узел для гибрида моделей |
Открытые вопросы для проверки на реальных данных — в разделе 30.
19. Стратегия тестирования
| Уровень | Что проверяем | Критерий |
|---|---|---|
| Модульное | Логика диалога, извлечение параметров, обращения к базе | Покрытие ключевой логики ≥ 70% |
| Интеграционное | Связка распознавание → диалог → база → синтез → запись | Сквозной сценарий записи проходит без ручного вмешательства |
| Точность | Извлечение параметров запроса на тестовых диалогах | ≥ 90% корректных извлечений на наборе из ≥ 100 диалогов |
| Задержка | Время от конца реплики до первого звука ответа | p95 ≤ 1 сек (best-effort, замеряется на стенде) |
| Перебивание | Остановка и продолжение ветки | ≥ 95% корректных обработок перебивания |
| Нагрузочное | Параллельные сессии (в Пакете 3 — на целевой объём) | Стабильная работа на заявленном числе линий |
| Безопасность | Изоляция данных, журналирование, доступы | Данные не покидают контур; все действия журналируются |
20. Развёртывание и инфраструктура
Решение разворачивается полностью в вашем контуре. Внешние API-вызовы отсутствуют.
| Аспект | Подход |
|---|---|
| Контейнеризация | Все сервисы в контейнерах, оркестрация внутри периметра |
| Серверные мощности | GPU-узлы предоставляет клиент (CAPEX клиента). Под MVP — оценочно 2–3 GPU-узла для языкового ядра + линия распознавания/синтеза |
| Сегментация | Изоляция сетевых сегментов, разграничение доступа по ролям |
| Журналирование | Полный журнал доступа и действий, готовность к форматам ГосСОПКА (Пакет 3) |
| Резервное копирование | Регулярные бэкапы базы диалогов и конфигураций |
| Мониторинг | Базовый в MVP; расширенный с алертингом — в Пакете 3 |
| Хранение записей | Аудио и транскрипты — в хранилище внутри контура, с управляемым сроком хранения |
Аппаратные ориентиры по масштабу (узлы предоставляет клиент):
| Целевой объём | Параллельных сессий | Оценка GPU-узлов |
|---|---|---|
| MVP / пилот | десятки | 2–3 |
| Пакет 2 | десятки | 3–4 |
| Пакет 3 | сотни | 6–9 |
Точная конфигурация уточняется после подтверждения объёмов звонков и доступного железа (раздел 30).
21. Критерии приёмки
| Модуль | Критерий приёмки |
|---|---|
| Перехват звонка | Перенаправление на оператора за ≤ 2 сек при заданном условии |
| Распознавание | Точность извлечения параметров ≥ 90% на тестовом наборе |
| Диалог и подбор | Релевантный слот по запросу с учётом времени и локации |
| Запись и подтверждение | Запись уходит в систему и подтверждается голосом в звонке |
| Перебивание | ≥ 95% корректных обработок перебивания |
| Эскалация | Передача оператору за ≤ 5 сек с сохранением контекста |
| Задержка | p95 ≤ 1 сек на стенде (best-effort) |
| Журнал и согласие | Каждый звонок записан, есть транскрипт и журнал; уведомление о записи проигрывается |
22. Нефункциональные требования
| # | Параметр | Порог |
|---|---|---|
| N1 | Задержка ответа (от конца реплики до первого звука), p95 | ≤ 1 сек (цель ~0.5 сек), best-effort |
| N2 | Точность извлечения параметров запроса | ≥ 90% |
| N3 | Корректная обработка перебивания | ≥ 95% |
| N4 | Доступность сервиса (production) | ≥ 99.9% в месяц |
| N5 | Локализация данных | Все данные — в контуре клиента на территории РФ |
| N6 | Покрытие тестами ключевой логики | ≥ 70% |
| N7 | Параллельные сессии | По целевому объёму пакета (десятки → сотни) |
Задержка < 1 сек фиксируется как измеряемый ориентир на стенде, а не как штрафуемое SLA-обязательство: фактическая задержка зависит от вашего железа и характеристик линии. Мы инструментально замеряем её на демо-стенде и в пилоте.
Часть III: Коммерческие условия
23. Как мы работаем
| Активность | Частота | Формат |
|---|---|---|
| Демо спринта | Каждые 2 недели | Видеозвонок + демонстрация на стенде |
| Еженедельный sync | 1 раз в неделю (30 мин) | Статус, блокеры, решения |
| Доступ к стенду | Постоянный | Демо-стенд в контролируемой среде |
| Канал связи | Постоянный | Выделенный чат проекта |
| Приёмка результатов | По завершении этапа | Демо + чеклист приёмки |
Управление изменениями: правки к ТЗ оформляются через запрос на изменение — команда оценивает влияние на сроки и бюджет, обе стороны согласуют.
24. Условия оплаты
Оплата привязана к результатам, а не ко времени. Стандартная схема: 30% предоплата → 50% по приёмке ключевого этапа → 20% по финальной приёмке.
MVP — 5 300 000 ₽
| # | Событие | Оплата | Нарастающим итогом |
|---|---|---|---|
| 1 | Предоплата (30%) | 1 590 000 | 1 590 000 |
| 2 | Приёмка ядра / демо (50%) | 2 650 000 | 4 240 000 |
| 3 | Финальная приёмка (20%) | 1 060 000 | 5 300 000 |
Пакет 2 — 6 920 000 ₽
| # | Событие | Оплата | Нарастающим итогом |
|---|---|---|---|
| 1 | Предоплата (30%) | 2 076 000 | 2 076 000 |
| 2 | Приёмка ключевого этапа (50%) | 3 460 000 | 5 536 000 |
| 3 | Финальная приёмка (20%) | 1 384 000 | 6 920 000 |
Пакет 3 — 8 620 000 ₽
| # | Событие | Оплата | Нарастающим итогом |
|---|---|---|---|
| 1 | Предоплата (30%) | 2 586 000 | 2 586 000 |
| 2 | Приёмка ключевого этапа (50%) | 4 310 000 | 6 896 000 |
| 3 | Финальная приёмка (20%) | 1 724 000 | 8 620 000 |
25. Ежемесячные расходы
После запуска решение требует сопровождения. Сами модели — открытые, лицензионных отчислений за них нет; основная стоимость — поддержка, мониторинг и донастройка.
| Статья | MVP / пилот | Промышленная эксплуатация |
|---|---|---|
| Сопровождение (L2/L3, мониторинг, донастройка сценариев) | от 300 000 ₽/мес | 600 000 – 1 200 000 ₽/мес |
| Инфраструктура (электричество, амортизация GPU) | на стороне клиента | на стороне клиента |
| Лицензии на модели | 0 ₽ (открытые модели) | 0 ₽ (открытые модели) |
Точный уровень сопровождения зависит от объёма трафика и требований к режиму (рабочие часы vs 24/7). Согласуется отдельным договором поддержки.
26. Риски и митигация
Карта рисков (вероятность × влияние)
| Низкая вероятность | Высокая вероятность | |
|---|---|---|
| Высокое влияние | R4 — Категорирование как значимый объект КИИ | R1 — Задержка < 1 сек на реальном железе R2 — Готовность API базы и системы записи |
| Низкое / среднее влияние | R5 — Зависимость от открытой модели | R3 — Качество распознавания на телефонии R6 — Объёмы звонков выше ожидаемых |
| Риск | Влияние | Митигация |
|---|---|---|
| R1 — Задержка < 1 сек на вашем железе | Высокое | Гибрид моделей, потоковая обработка, замер на демо-стенде до обязательств; задержка фиксируется как best-effort ориентир |
| R2 — Готовность API базы и системы записи | Высокое | Раннее согласование контракта интеграции; на время отсутствия API — работа на обезличенной копии каталога |
| R3 — Качество распознавания на телефонии | Среднее | Модель, оптимизированная под русскую телефонию; донастройка на ваших данных в пилоте |
| R4 — Категорирование как значимый объект КИИ | Высокое | Проектируем «как под КИИ-дисциплину» с первого дня: сегментация, журналирование, ГосСОПКА-готовность (Пакет 3) |
| R5 — Зависимость от открытой модели | Низкое | Мы фиксируем версию модели на проверенном состоянии и владеем своей сборкой; при необходимости модель заменяется без переписывания контура |
| R6 — Объёмы звонков выше ожидаемых | Среднее | Архитектура масштабируется добавлением узлов (Пакет 3); ёмкость пересчитывается под фактический пик |
27. Гарантии
- Гарантийный период: 3 месяца после финальной приёмки — исправление дефектов бесплатно.
- Воспроизводимость: решение разворачивается из исходного кода и конфигураций, которые передаются вам.
- Прозрачность: открытый код решения, открытые модели — нет «чёрного ящика» и внешних зависимостей.
- Приёмка по критериям: все результаты проверяются по измеримым критериям из разделов 21–22.
Мы отвечаем за работу программного обеспечения по согласованным критериям. Правовые, регуляторные и медицинские заключения (категорирование КИИ, формулировки согласий, медицинская тайна) — зона ответственности клиента и его профильных служб; мы предоставляем техническую реализацию и готовые артефакты (например, скрипт уведомления о записи).
28. Требования к клиенту
Для старта и работы нам понадобятся с вашей стороны:
- Доступ к телефонной линии (тестовый номер и условия перехвата перелива).
- Программный интерфейс к базе врачей и услуг (или согласованная обезличенная копия для пилота).
- Программный интерфейс к системе записи клиник (или описание процесса записи).
- GPU-серверы в вашем контуре под развёртывание.
- Доступ в контур для команды (по согласованным правилам ИБ).
- Тестовый каталог направлений/услуг для демо-стенда.
- Контактное лицо по техническим вопросам и приёмке.
- Решение по категорированию КИИ и требования ИБ к подрядчику.
29. Что не входит
- Поставка серверного оборудования (GPU предоставляет клиент).
- Интеграция с государственной системой ЕГИСЗ (поток в ЕГИСЗ — зона ответственности клиники).
- Медицинская диагностика, постановка диагноза, назначение лечения (оператор делает организационную маршрутизацию и запись, не консультацию).
- Юридические и регуляторные заключения, получение согласий пациентов (предоставляем технические артефакты).
- Каналы помимо голосового (мессенджеры, SMS, чат) — могут быть добавлены отдельно.
- Краевые сценарии, масштабирование, дообучение — в пакетах расширения и опциях.
30. Открытые вопросы и наши допущения
Предложение подготовлено по итогам встречи 12.05.2026. Ряд параметров пока не подтверждён — ниже наши рабочие допущения (инженерные дефолты). Архитектура от их уточнения не меняется; калибруются объёмы, сроки и конфигурация железа.
| # | Вопрос | Наше допущение | Что уточняем |
|---|---|---|---|
| 1 | Объём звонков и пик | Десятки тысяч звонков/день, перехват 15–40% в пик; MVP держит десятки параллельных линий | Точные цифры → число узлов и сессий |
| 2 | KPI MVP | Доля автономной обработки 60–75% на основных кейсах, CSI ≥ 4.2, точность подбора ≥ 90% | Целевые значения для приёмки |
| 3 | Телефонная платформа | Подключение по стандартному протоколу (SIP) | Конкретная платформа и условия перехвата |
| 4 | База врачей/услуг | Структурированная база (~520 тыс. записей), доступ по API, без семантического поиска | СУБД, готовность API, задержка под нагрузкой |
| 5 | Система записи клиник | Одна основная интеграция записи в MVP, задел под несколько | Одна МИС или несколько (влияет на опцию О3) |
| 6 | Аппаратные ресурсы | 2–3 GPU-узла под MVP в вашем контуре | Модель и число GPU, доступная память |
| 7 | Compliance | 152-ФЗ, врачебная тайна, КИИ-дисциплина; ЕГИСЗ вне scope | Категория объекта КИИ, требования ИБ к подрядчику |
| 8 | Направления MVP | Топ амбулаторных направлений (терапевт, узкие специалисты, диагностика) | Точный перечень и исключения |
| 9 | Правила подбора клиники | Локация → доступность слота → (опционально) ДМС, рейтинг | Обязателен ли ДМС-фильтр |
| 10 | Эскалация | Тёплая передача живому оператору с сохранением контекста | Канал и момент срабатывания |
| 11 | Запись разговоров | Хранение в контуре, уведомление в начале звонка | Срок хранения, формулировка согласия |
| 12 | Демо-стенд | Реальный звонок на тестовый номер на обезличенном каталоге | Сценарии и площадка тендера |
Каждый ответ позволяет уточнить расчёт без изменения архитектуры решения.
31. Перспективы развития
После MVP решение естественно развивается:
- Краевые сценарии (Пакет 2) — отмена, перенос, проговаривание подготовки к визиту.
- Масштаб и автономность (Пакет 3) — сотни линий, отказоустойчивость, дообучение на ваших диалогах.
- Исходящий контур (опция О2) — напоминания и подтверждения, снижение неявок.
- Единый оператор поверх сети клиник (опция О3) — интеграция с разными системами записи.
- Совместимость с вашей экосистемой (опция О1) — использование ваших корпоративных моделей как движка.
- Узнавание пациента по голосу (опция О4) — без повторного диктования данных.
32. Глоссарий
| Термин | Определение |
|---|---|
| On-premise (в контуре) | Развёртывание на серверах клиента, без внешних облаков и API |
| Открытая модель | Модель ИИ с открытыми весами, разворачиваемая локально |
| Распознавание речи | Перевод голоса пациента в текст |
| Синтез речи | Озвучивание ответа оператора голосом |
| Перебивание (barge-in) | Возможность прервать оператора в любой момент |
| Задержка ответа | Время от конца реплики пациента до первого звука ответа |
| Перехват перелива | Перенаправление звонка на оператора в момент перегрузки колл-центра |
| Эскалация | Передача звонка живому сотруднику |
| Тёплая передача | Передача звонка с сохранением контекста диалога |
| CSI | Индекс удовлетворённости клиента |
| Квантизация | Сжатие модели для ускорения без значимой потери качества |
| Гибрид моделей | Быстрая модель для онлайн-реплик + тяжёлая для сложных случаев |
| КИИ | Критическая информационная инфраструктура (187-ФЗ) |
| ГосСОПКА | Государственная система обнаружения и предупреждения компьютерных атак |
| ЕГИСЗ | Единая государственная информационная система в сфере здравоохранения |
33. Следующие шаги
| # | Шаг | Сторона | Срок |
|---|---|---|---|
| 1 | Подтверждение допущений из раздела 30 (хотя бы критичных: API базы, телефония, железо) | СберЗдоровье | при готовности |
| 2 | Выбор пакета и конфигурации для тендера | СберЗдоровье | до тендера |
| 3 | Подготовка демо-стенда | AiDevTeam | 3–4 недели |
| 4 | Согласование контракта интеграции и условий доступа в контур | Обе стороны | параллельно |
| 5 | Старт разработки MVP | Обе стороны | после выбора |
Все оценки являются предварительными и будут уточнены после детального ТЗ и подтверждения допущений из раздела 30.
Предложение действительно 30 дней. Разработка: AiDevTeam