WhatsApp-бот для стоматологии: −40% звонков на ресепшн за 5 дней

Зачем стоматологии бот

Клиент — две стоматологические клиники в городе-миллионнике, общая команда 12 врачей (терапия, хирургия, ортодонтия, детская стоматология). Входящий поток пациентов распределён между двумя каналами: звонки по городскому номеру и сообщения в WhatsApp. До нашего внедрения оба канала обрабатывали два администратора в смену, и оба канала были перегружены.

Проблема была измеримая:

• Пиковые часы — 18:00–21:00 и суббота до обеда. В эти окна администратор не поднимает трубку 30–40% звонков.
• Типовые вопросы занимали 80% времени администратора: «сколько стоит чистка», «когда ближайшее окно у терапевта», «как доехать», «нужны ли анализы перед имплантацией».
• Половина потенциальных пациентов отсеивалась на этапе «не дозвонился». По внутренним подсчётам клиента — это минус 15–20 первичных записей в неделю.

Задача была сформулирована довольно кратко: «Сделайте так, чтобы типовые вопросы не ели время администратора, и чтобы никто не уходил просто потому, что мы не ответили за пять минут».

Почему не встроенный чат на сайте

Первое, что предлагают разработчики — встроить чат-виджет на сайт. Мы сознательно отказались от этого варианта и вот почему.

Месяц перед проектом клиент поставил на сайт обычный чат (без AI, просто оператор). Метрика — 3 обращения за месяц. Три. При том, что на сайте за тот же месяц было около 8 000 уникальных посетителей.

Человек не хочет писать в непонятный виджет на сайте. Он хочет либо позвонить (привычно, быстро, понятно), либо написать в мессенджер, которым уже пользуется. WhatsApp — это 95% взрослого населения города клиента, Telegram — ещё 40% сверху (с пересечением). Поэтому решение было очевидным: идти туда, где пациенты уже есть, а не пытаться перетащить их на сайт.

Подключили два канала через провайдера WhatsApp Business API и Telegram Bot API. Единый номер WhatsApp совпадает с городским телефоном клиники — это важный штрих: человек сохраняет номер в контакты и одновременно получает и «позвонить», и «написать».

Как устроен бот внутри

Архитектурно бот — это три слоя: классификатор сообщений, база знаний, экшены.

Сообщение пациента
       │
       ▼
┌────────────────────┐
│  Классификатор      │   → INFO (инфо о клинике)
│  (Haiku 4.5)        │   → PRICE (цены)
│                     │   → BOOKING (запись)
│                     │   → COMPLAINT (жалоба)
│                     │   → FREE (всё остальное)
└─────────┬──────────┘
          │
          ▼
┌────────────────────┐
│  Router             │
└─────────┬──────────┘
          │
 ┌────────┼──────────┬──────────┐
 ▼        ▼          ▼          ▼
RAG      Prices      Booking    Human
KB       Module      Module     handoff
 │        │          │          │
 ▼        ▼          ▼          │
 └────────┴──────────┴──────────┘
                │
                ▼
        Ответ пациенту

Классификатор — первый шаг любого сообщения. Haiku 4.5 за ~300 мс определяет тип обращения по 5 категориям. Это дешёвый и быстрый шаг, и он сильно экономит: дальше по ветке работают разные модули, каждый с своим промптом и своими данными.

RAG (База знаний). В Postgres + pgvector лежат чанки с информацией: адреса, время работы, парковка, список услуг, описание врачей, подготовка к приёму. Индексация обновляется через админку: администратор редактирует справочник, жмёт «Обновить» — эмбеддинги пересчитываются за минуту. Это принципиально: база знаний не должна быть в коде, иначе бот устаревает быстрее, чем успеваешь его поддерживать.

Prices Module. Цены лежат в отдельной таблице, синхронизируются с МИС клиента раз в сутки. Если пациент спрашивает «сколько стоит пломба» — модуль возвращает актуальную цену с учётом филиала. Важно: цены никогда не берутся из LLM, только из структурированных данных. Галлюцинация «2 500 рублей вместо 4 500» в мед-тематике — это скандал и штраф.

Booking Module. Подключён к МИС клиента через их API. Бот видит расписание врачей, свободные окна, длительность приёмов. Когда пациент просит записаться — модуль предлагает 3 ближайших окна у подходящего врача, спрашивает подтверждение, создаёт черновик записи в МИС. Окончательное подтверждение утром делает администратор (подробнее — в FAQ выше).

Human handoff. Если классификатор видит жалобу, агрессию или нетипичный вопрос — бот пишет «передаю администратору, вам ответят в течение получаса», и отправляет уведомление в рабочий чат клиники. Администратор подключается только в этих случаях, не на каждом сообщении.

Системный промпт: что можно и что нельзя

Медицинская тематика — YMYL, поэтому системный промпт у бота довольно строгий. Ключевые правила:

• Никогда не ставить диагноз. Симптомы обсуждаются только на очном приёме.
• Никогда не назначать лечение. Даже если пациент настаивает и говорит «просто скажите, что принимать».
• Никогда не обещать результат. Никаких «после имплантации зубы будут как новые».
• Не придумывать цены. Только из Prices Module.
• Не придумывать врачей. Только из базы знаний.
• Всегда предлагать очный приём. Финал любого не-тривиального разговора — CTA на запись.

Запуск за 5 дней

Клиент не верил, что это можно сделать за 5 дней. Честно: в первый день тоже не верил я. Но если есть готовый шаблон архитектуры (классификатор + RAG + actions), а клиент готов быстро отвечать на вопросы по базе знаний и по интеграции с МИС — 5 дней хватает.

День 1    Подключение WhatsApp Business API и Telegram
          Выгрузка справочника из МИС (услуги, цены, врачи)
          Первая сборка RAG-индекса

День 2    Классификатор + роутинг
          Интеграция Prices Module
          Первое тестирование на dev-номере

День 3    Booking Module: API МИС, расписание, слоты
          Системный промпт, ограничения YMYL
          Ручной тест 30 типовых сценариев

День 4    Human handoff, уведомления в чат клиники
          Фикс багов первого дня использования сотрудниками
          Запуск на 10% входящих сообщений (A/B)

День 5    Полный запуск: 100% сообщений WhatsApp + Telegram
          Мониторинг, правки промпта по живым диалогам

Результаты через месяц

Минус 40% звонков — это не абсолютный минус входящего потока. Общий объём обращений вырос (потому что люди стали писать в WhatsApp чаще, видя быстрый отклик), но доля обращений, которые требуют живого администратора, упала в 3–4 раза.

Отдельный эффект, который не попал в таблицу: администратор перестал выгорать. До внедрения — жалобы на пиковые часы, уставший голос, претензии от пациентов, которые «ждали 10 минут». После внедрения — у администратора появилось время на входящих живьём, кассу и качество обслуживания. Это не измеряется в цифрах, но именно это и определяет возвращаемость пациентов.

Что забрать из кейса

Бот для клиники — это не про «заменить человека», а про перераспределение нагрузки: типовые вопросы снимаются автоматически, а живой администратор занимается тем, ради чего его и нанимали — работа с реальными людьми в нестандартных ситуациях.

И да: WhatsApp важнее, чем чат на сайте. Если клиент выбирает между «сделать красивый чат на сайте» и «подключить бота в WhatsApp» — всегда второе. Люди не хотят менять мессенджер ради того, чтобы написать в клинику. Идите туда, где они уже есть.