Промпты веток (по docs/BRANCH_MAP_AND_PROMPTS_v1.md):
- reschedule.md — полная замена. Одношаговый сценарий из 6 пунктов:
action (cancel/reschedule), patient_name, patient_phone, original_time,
preferred_new_time. Слоты хранит вызывающая система, STATE_JSON не используется.
- price_question.md — добавлены 3 пункта: эндоскопия 1000₽ при первичном
ЛОР-приёме, лечебные процедуры доплачиваются, ОМС только сурдолог
(последний пункт работает только при подтверждении в базе).
- medical_question.md — расширена карта жалоб → специалист (ЛОР / сурдолог /
аллерголог / иммунолог / пульмонолог); добавлен пункт про беременность,
онкологию, психиатрию — мягко сказать «специализированная клиника»,
не предлагать запись.
- general_info.md — добавлены разделы «Отзывы и социальное доказательство»,
«Преимущества клиники», «Сокращения». Условия выхода расширены до 5 интентов.
escalate_human и new_booking не трогаем (escalate — карта говорит «не менять»;
new_booking — отдельный Спринт 7.6 по docs/OPTIMIZATION_CONVERSION_v1.md).
Применение в БД — вручную через UI «Настройки» (вариант A): оператор копирует
текст из .md, сохраняет как новую версию + активирует. Файлы — только seed.
Eval-каркас (заготовка под Спринт 8):
- eval/router_cases_booking.jsonl (875 кейсов new_booking) и
eval/router_cases_other.jsonl (698 кейсов: general_info 295, price 165,
escalate 139, medical 59, reschedule 40). CSV-исходники рядом.
- eval/README.md — формат, глоссарий, что это и зачем.
- routers/eval.py: GET /eval/router-cases?intent_code=...&limit=...
Lazy-кэш, сортировка по count desc, фильтр по expected_intent.
UI Настроек — выбор готового кейса в тест-блоке:
- Полоса «Готовый кейс:» с datalist (поиск по началу строки) + кнопка
«🎲 Случайный» + счётчик кейсов для активной ветки.
- При выборе — текст подставляется в textarea вопроса.
- Загружается при выборе ветки. Если кейсов 0 (для _router, _debug) — скрыто.
- Полная подсистема прогона (run.py, отчёты, baseline) — Спринт 8.
SPRINTS.md:
- Спринт 7 (мульти-RAG, часть A) → ✅ Закрыт (коммит 52b46bc).
- Заведён Спринт 7.5 «Обновление промптов 4 веток» (этот спринт).
- Заведён Спринт 7.6 «Оптимизация воронки new_booking до 4 шагов»
по OPTIMIZATION_CONVERSION_v1.md.
- В идеи на потом: сквозные правила всех веток (BRANCH_MAP §2),
отложенная документация Спринта 7 (docs.html карточка термина,
GRAPH_ARCHITECTURE_v5, README про мульти-RAG).
Также: docs/COMPETITOR_ALEXANDRA_top100.md — рабочие материалы пользователя
по конкурентному боту (NEXTBOT/Александра), используется как baseline для
оптимизации воронки в Спринте 7.6.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
14 KiB
Разбор конкурента «Александра» — первые 100 диалогов из 2691
Источник: dialogs-export-2026-04-27-09-45-07.xlsx (clinic-lor@mail.ru, ЛОР-клиника, Пермь, 2 филиала).
Дата экспорта: 27.04.2026. Дата анализа: 27.04.2026.
Метрики конкурента (по сводке файла)
- 2691 диалог за период.
- 6.1 сообщений на диалог в среднем.
- Каналы: Widget 87%, VK 13%, Max/Telegram единицы.
- 684 диалога с тегом
has_tool_calls= ~25% общая конверсия в передачу заявки администратору. В первых 100 — 32% (часть из них — повторные обращения тех же клиентов). - Расход $ после рестарта = 0 (т.е. они на Botcoin/локальной модели).
- Средний расход 2.76 Botcoin/диалог.
Архитектура их сценария (восстановлена по стенограммам)
Воронка из 3 шагов, не 4:
- Triage — бот сразу собирает причину обращения, не настаивая на имени, без отдельного intro.
- Pitch — называет цену первичного приёма (от 2500 ₽), упоминает что эндоскопия +1000 ₽ оплачивается отдельно, предлагает записать.
- Capture — просит только телефон. Имя — опционально, бот достаёт его из реплик сам. Дальше
save_user_dataи шаблонная плашка прощания.
Шаблон закрытия после tool_call (одинаковый везде, помечен [Шаблон]):
«Я отправила ваши данные администратору. Ожидайте звонка. Мне было приятно с вами общаться. Хорошего дня и спасибо за выбор нашей клиники!»
Структура tool_call (полезно подсмотреть для нашего):
{
"phone": 89922070601,
"source": "Сайт",
"context": "Пациентка переболела, был сильный кашель, сейчас дискомфорт при глотании",
"service": "Прием ЛОР-врача"
}
Контекст и услугу LLM формирует сам из истории — это даёт администратору готовое описание лида без необходимости перечитывать диалог.
«Догоняющее» сообщение при молчании клиента: системный триггер пишет ассистенту «Клиент не ответил отправь ему еще одно сообщение: "У вас остались еще какие-то вопросы?"», ассистент пересылает. Несколько раз в выборке именно это возвращало клиента в воронку и приводило к захвату телефона.
Темы пациентов (распределение по 100 диалогам)
В порядке убывания частотности:
- Запись по симптому (болит ухо, насморк, заложенность, выделения, шум, головокружение) — около половины обращений.
- Запись к конкретному врачу по фамилии — ~15%.
- Стоимость услуги/процедуры — ~10%.
- Справка для налогового вычета — повторяется 8+ раз в первой сотне с почти идентичным длинным ответом. Кандидат на отдельный intent с готовым шаблоном.
- Дети (с рождения, аденоиды, отиты, шунты) — ~10%.
- Перенос/отмена записи — ~5%.
- Доверенность для бабушки сопровождать ребёнка — есть готовый текстовый шаблон от руки.
- График работы / праздники, адреса, ОМС/ДМС, рассрочка, оплата по QR — короткие FAQ.
- Отсев по географии (Казахстан, Тула, Калуга, Златоуст, Кизел) — клиника только в Перми.
Что у них работает (можно перенять)
- Минимум полей в lead-форме: только phone. Имя/контекст бот собирает сам. Снимает фрикцию.
- Контекст и услуга в JSON автоматически — экономит время администратора.
- Шаблонные ответы для типовых FAQ (налоговая справка, доверенность) выдаются мгновенно и без LLM-творчества — стабильно и дёшево.
- Догоняющее сообщение через системный триггер при молчании.
- Конкретика в питче: цена + регалии врача (ФИО, к.м.н., стаж 32 года) повышает доверие и часто прямо в этом сообщении вытягивает телефон.
- Тёплый эмоциональный регистр: называют по имени, «Берегите себя», смайлики, «желаю здоровья» — но без перебора.
Где они проседают (наши потенциальные преимущества)
- Нет интеграции с расписанием врачей. Любой вопрос «когда есть свободное время к доктору X?» переадресуется администратору. Если у нас будет онлайн-расписание, мы можем закрывать запись прямо в чате — это огромный отрыв.
- Не интегрированы с CRM записей. Пациент пишет «я записан на завтра, во сколько?» — бот предлагает оставить телефон и ждать звонка. Унизительно для уже-клиента.
- Галлюцинации на простых вопросах. Диалог #49: сначала «стационар не предусмотрен», через 2 реплики «стационар есть, можно остаться». Противоречие в одном диалоге.
- Слабая фильтрация по гео. Длинный ответ про услуги выдаётся пациенту из Казахстана/Челябинска до того, как выясняется что приехать не сможет. Минута впустую и негатив.
- Не различает экстренные ситуации. Диалог #21: ребёнок 1.5 месяца, ночь, боль в ухе. Бот трижды предлагал «запишитесь на приём». Скорую упомянул только после третьей реплики «На улице ночь». Для нашего бота это потенциальный safety-incident, надо сразу: «вызывайте 03/112».
- Fuzzy-matching фамилий слабый. «Варанчихина» сначала не нашёл, со второй попытки нашёл «Ворончихину». Диалог #34. Простой word-distance fix.
- Лишний шаг intro. «Здравствуйте» → «Как я могу к вам обращаться?» → имя → «Чем могу помочь?». На каждом шаге часть пациентов отваливается. У нас по
OPTIMIZATION_CONVERSION_v1.mdуже сокращено до 4 шагов — стоит проверить, можем ли убрать ещё intro. - Защитная реакция на негатив: «Вы с такими ценами не ахренели?» → бот оправдывается «качество, оборудование». Не лучшая стратегия. Можно тестировать варианты с эмпатией + альтернативой («понимаю, цены немалые. Если бюджет ограничен, могу подсказать, на каких процедурах можно сэкономить?»).
- Дают развёрнутые медицинские рекомендации дома (диалог #57: 5 пунктов как лечить заложенность уха). Юридически рискованно для частной клиники. Нам нужно решить осознанно: даём советы или жёстко возвращаем к врачу.
- Не блокируют запросы про конкурирующие города. Пациент спросил «филиал в Туле?» — бот ответил, но мог бы сразу прислать ссылку на запись/адрес главной клиники.
Корпус реальных фраз пациентов (для evals/regression-тестов)
Готовые строки для генератора тест-кейсов нашего бота:
- «Болит ухо» / «Заложило ухо после ОРВИ» / «Из уха течёт жёлтая жидкость без запаха»
- «Жёлтые выделения из носа» / «Не проходит насморк» / «Опухла левая щека и из ноздри жёлтый гной»
- «Очень сильно храплю, иногда закладывает уши»
- «Записаться к лору» / «Запишите на повторный приём» / «Можно записаться к {фамилия}?»
- «Сколько стоит первичный приём Лора?» / «Цена септопластики» / «Стоимость продувания слуховых труб»
- «Принимаете по ОМС?» / «По ДМС работаете?» / «Даёте рассрочку?»
- «Справка для налогового вычета за 2024-2025»
- «Доверенность на бабушку» / «Можно ребёнку 15 лет прийти без родителей?»
- «Когда ближайшая запись к {фамилия}?» / «У вас есть свободное время сегодня?»
- «Я записан на завтра, во сколько?» / «Можно отменить приём?» / «Перенесите мою запись»
- «Принимаете детей 2 лет?» / «Чем закапать ухо ребёнку?» (опасный сценарий)
- «У меня рыбная косточка в гортани» (срочный)
- «Шум в ушах что делать» / «Сильное головокружение, лежала в неврологии не помогает»
- «А где вы находитесь?» / «Вы клиника возле Колизея?»
- «Вы с такими ценами не ахренели?» (негативный пользователь)
Идеи для нашего проекта
- Готовый шаблон ответа про налоговую справку — копируется без LLM, экономит токены. Аналогично для доверенности и графика работы.
- Гео-фильтр на ранних шагах: если в первых 2 сообщениях звучит другой город — короткий эмпатичный ответ, без длинного питча.
- Safety-классификатор на острые состояния (ребёнок до года + симптом, инородное тело, кровотечение, ночь+боль) → сначала «вызовите 03/112», потом запись.
- Fuzzy-matching фамилий врачей (Левенштейн или эмбеддинги) для исправления ошибок ввода.
- Догоняющий триггер при молчании через 5 минут — у Александры явно работает.
- Поле
contextв lead-payload генерируется LLM из истории — операторам очень удобно. Стоит включить в нашsave_user_data, если ещё нет.
Технические наблюдения
- VK-канал у них работает в основном через лид-форму, а не диалог: 30+ записей вида «Заявка из Vk → Имя/Телефон». Похоже, VK интегрирован отдельно от LLM-сценария.
- 169 сообщений оператора на 2691 диалог = ~6% диалогов потребовали ручного вмешательства. Хороший таргет для нас.
- 28 млн токенов суммарно (входящих 27.6 млн, исходящих 481 тыс). Соотношение 57:1 говорит о большом системном промпте + контексте — типично для RAG. Наш
OPTIMIZATION_CONVERSION_v1.mdкак раз про сжатие этого.