Чому медичний чат-бот зривається на потоці звернень
Медичний чат-бот зривається не на розпізнаванні мовлення і не на моделі — на потоці.
Ранок понеділка: реєстратура одночасно приймає дзвінки, оформлює тих, хто прийшов, і відповідає в месенджері, а звернення в чаті чекає на оператора саме в той момент, коли найшвидше мало б отримати відповідь.
Пікове навантаження на реєстратуру — перше місце відмови. Коли звернень утричі більше за звичайне, черга зростає, частина пацієнтів закриває діалог і записується в іншу клініку.
Втрата звернення пацієнта при цьому не видна у звітах: покинутий чат не залишає заявки, і вранці наступного дня ніхто не розуміє, скільки людей пішло.
Друге — передача лікарю. Бот зібрав скаргу та підібрав спеціальність, але далі звернення зависає: вільний час уже зайнятий, лікар не підтверджує прийом, діалог залишається в невизначеному статусі. Пацієнт упевнений, що записаний, клініка впевнена, що запит не дійшов.
Повторні питання пацієнтів — третє вузьке місце.
Адреса, графік, підготовка до аналізу, чи потрібна довідка, як потрапити до вузького спеціаліста: на такий набір фактів припадає основна частина діалогів, а бот відповідає «уточню в адміністратора» — і автоматизація перетворюється на ще один канал навантаження.
Четверте — розрив між записом без оператора та правилами прийому. Правила живуть у регламентах і головах адміністраторів: де прийом за направленням, де окреме вікно для повторних, де потрібна попередня підготовка.
Бот, який просто віддає вільний час, регулярно записує не туди, а розбір помилок знову лягає на реєстратуру.
Усі чотири місця — не проблема моделі, а проблема стикування даних, правил і відповідальності за звернення. Далі розбираємо, як це закривається.
Що дає автоматизація прийому звернень пацієнтів
Ефект впровадження вважається не за кількістю сценаріїв, а за зсувом в операційних метриках. Пацієнти пишуть у Telegram, месенджери та веб-віджет на сайті клініки — єдина точка входу дозволяє порівнювати ці потоки та бачити, де саме бот знімає навантаження з реєстратури.
Частка звернень без оператора
Бот закриває запис, перенесення, скасування, підготовку до прийому та типові питання щодо документів і підготовки. Решту він збирає та передає оператору з готовим контекстом: хто пише, до якого лікаря, що вже уточнено.
Частка повністю автоматичних діалогів зазвичай тримається на 55–75% і зростає в міру розширення бази відповідей.
Час до запису
Пацієнт бачить вільні слоти в реальному часі та обирає відповідний у тому ж діалозі, без очікування відповіді й передзвону. Шлях від першого повідомлення до зафіксованого талона скорочується до 2–4 хвилин проти годин очікування під час роботи через кол-центр у пікові години.
Відмови на піку та рівномірне навантаження
Пік звернень — ранок понеділка та перші години відкриття запису: черга зростає, частина пацієнтів не додзвонюється і йде до інших клінік.
Бот тримає паралельні діалоги без черги, тому відмови на піку зникають, а навантаження за годинами вирівнюється — вечірні та обідні звернення обслуговуються тією ж якістю, що й ранкові.
Розвантаження кол-центру
Оператори перестають бути першим контактом і переключаються на складні випадки: спірні записи, питання щодо страховки, координація кількох спеціалістів.
Кількість ручних дотиків на один діалог падає, а вивільнений час іде туди, де людина незамінна, — не на типовий сценарій запису.
Сценарії автоматизації: порівняння підходів і режимів
Вибір режиму діалогу визначає не «розумність» бота, а те, що станеться при запиті поза сценарієм. Дерево кнопок передбачуване, але ламається на живій мові; модель на мовних даних розуміє вільне формулювання, але потребує обмеження тем.
Гібридний режим поєднує обидва: критичні гілки — запис, перенесення, скасування прийому — тримає сценарій, вільну частину закриває модель.
Порівняння режимів діалогу
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Жорсткий сценарій | Запис, години роботи, маршрутизація за відділеннями: набір дій відомий заздалегідь | Не розуміє вільного формулювання, крок убік веде в глухий кут |
| Сценарний діалог із підказками | Різні формулювання одного запиту при жорстких гілках | Словники й правила зростають із кожним нетиповим зверненням |
| Модель на мовних даних | Вільні питання про підготовку до прийому | Відповіді обмежують темами й перевіряють на точність |
| Гібридний режим | Змішаний потік: типові операції та вільні питання | Складніше налаштування, потрібна розмітка меж між сценарієм і моделлю |
Обмеження підходів видно не на презентації, а на довгій дистанції: словники розширюють після кожного нетипового формулювання, модель обмежують списком тем. У правилах фіксують межі — де бот зобов’язаний уточнити, де відповідає своїми словами і де одразу передає діалог.
Правила ескалації — частина цієї схеми, а не окреме налаштування. Передаємо адміністратору при питаннях про діагноз і призначення, при повторному нерозумінні, явному негативі та прямому проханні з’єднати з людиною. Кожна передана нитка показує, які гілки сценарію варто доопрацювати.
Впровадження медичного чат-бота: етапи інженерної роботи
Аудит звернень потрібен до першого рядка сценарію: без нього бот переказує те, що й так лежить на сайті, і не знімає з реєстратури основне навантаження.
Ми вивантажуємо історію дзвінків і листувань за період, розмічаємо за темами та рахуємо частку повторюваних питань — вона задає пріоритет гілок і обсяг робіт. Далі послідовність така.
- Аудит звернень: кластеризація запитів, частота за темами, частка діалогів, які закриваються без лікаря. На виході — перелік сценаріїв за спаданням попиту та список тем, які бот чіпати не повинен.
- Схема діалогових гілок: кожна гілка описується як набір станів з обов’язковими даними. Окремо фіксуємо точки зупинки — де розмова обов’язково переходить до оператора, а де її закриває лікар.
- Налаштування інтеграцій: підключення до інформаційної системи закладу — розклад, запис, перенесення та скасування, довідник послуг і підготовка до досліджень. Боту видається вузький набір дозволених операцій, кожна дія фіксується в журналі.
- Перевірка на реальних зверненнях: прогін на історичних діалогах, потім робота в закритому контурі, де відповіді бота звіряють із рішеннями оператора. Рахуємо частку правильних маршрутизацій і правимо межі гілок.
- Навчання персоналу: оператори отримують чергу діалогів, правила передачі та регламент на випадок збою; адміністратори вчаться змінювати години роботи та тексти відповідей без розробника.
- Передача рішення та супровід: конфігурації, схема інтеграції, інструкції та доступи залишаються в закладу. Далі — період супроводу зі строками реакції на інциденти та розбором спірних діалогів.
Що передаємо клініці: конфігурації, схеми та регламенти
Проєкт закривається не демонстрацією працюючого сценарію, а комплектом, за яким клініка експлуатує бота без нас.
Ми передаємо документацію в тому вигляді, у якому самі її читаємо при поверненні на проєкт: опис моделі діалогів, точки прийняття рішень, зони відповідальності співробітників і порядок дій при спірній відповіді.
- Опис структури діалогів: дерево сценаріїв із точками виходу на оператора, перелік обов’язкових уточнень і правила обробки гілок, де запит виходить за межі бази знань.
- Правила маршрутизації: за якими ознаками діалог переходить до реєстратури, до профільного спеціаліста або на термінову лінію, з яким пріоритетом і за якою схемою ескалації за відсутності відповіді.
- Інструкція для операторів: як підхопити діалог, що видно в історії звернення, які поля обов’язкові для заповнення і де фіксується причина передачі.
- Документація щодо доступів: ролі співробітників, обсяг видимих даних, порядок надання та відкликання прав, правила зберігання знеособлених журналів звернень.
- Регламент оновлення бази знань: власник розділу, періодичність перегляду матеріалів, обов’язкова перевірка правок профільним спеціалістом до публікації.
- Порядок розбору спірних відповідей: як діалог потрапляє на розбір, хто ухвалює рішення, як виправлення доходить до бази знань і перевіряється на повторних зверненнях.
Список не декоративний: за ним видно, хто в клініці відповідає за кожну правку, а отже, бот продовжує коректно відповідати й після того, як ми вийшли з проєкту.
Кейс: як мережа клінік зняла навантаження з реєстратури
Вихідна точка
У мережі клінік МедЛайн чотирнадцять філій і єдина реєстратура на всі майданчики. У ранкові години пік — з 8 до 11 — частка пропущених діалогів сягала 18–20%: адміністратори фізично не встигали вести месенджери й телефон паралельно, а перша відповідь у чаті займала 9–14 хвилин.
Кожен пропущений діалог означав незроблений запис, і в завантажені дні майже чверть звернень закривалася без призначення.
Що змінили
Чат-бот узяв на себе типові сценарії: запис і перенесення прийому, уточнення розкладу лікаря та вільних вікон, нагадування, питання щодо підготовки до аналізів, видача результатів.
Діалог ішов за розгалуженим сценарієм із перевіркою введення на кожному кроці, а на будь-якій нештатній репліці управління передавалося оператору разом з історією листування — людина не ставила ті самі питання заново.
Метрики до та після
Частка звернень, закритих без оператора, вийшла на 68–72%. Перша відповідь у години пік скоротилася до 4–6 секунд, пропущені діалоги — менше 1%, через бота проходить близько половини всіх записів, і потік розподіляється рівномірно, а не піками.
Що залишилося на людях
Спірні скарги, друга думка щодо складних діагнозів, узгодження за полісами та розбір конфліктних ситуацій, як і раніше, переходять до живого адміністратора.
Ці гілки ми навмисно не автоматизуємо: там ціна помилки вища за вигоду від прискорення, а формулювання потребують людського такту. Завдання чат-бота — зняти рутину, а не замінити собою всю реєстратуру.
Чим відрізняється сценарний діалог від мовної моделі
Режими різняться тим, хто формулює відповідь. Сценарій обирає репліку з затверджених варіантів: бот розпізнає намір і веде за гілкою — запис, нагадування, підготовка до процедури. Модель складає відповідь сама за базою знань клініки та історією діалогу.
Передбачуваність відповіді — головна розбіжність. Сценарій видає одну й ту саму репліку на одне й те саме питання: її погоджує лікар до запуску, і вона відтворювана при розборі діалогу.
Модель відповідає гнучкіше, але формулювання змінюється від діалогу до діалогу — затвердити її раз і назавжди не можна.
| Критерій | Сценарний діалог | Мовна модель |
|---|---|---|
| Передбачуваність відповіді | Одне питання — одна затверджена відповідь | Формулювання змінюється |
| Ризик невірної відповіді | Низький: лише погоджені репліки | Потрібні правила та перевірка за джерелами |
| Контроль лікаря | Правки в тексті гілки | Заборонені теми, межі, ескалація |
| Вартість володіння | Нові теми — ручна робота | Теми закриваються без переписування гілок, вище навантаження на контроль якості |
Ризик невірної відповіді визначається тим, хто відповідає за зміст. У сценарії — лікар, який затвердив формулювання, тому сторонніх реплік у діалозі не з’явиться.
Для моделі потрібен шар обмежень: відповідь будується лише за затвердженою базою знань, заборонені діагнози та призначення, а вихід за межі теми передає діалог лікарю.
Вибір режиму діалогу на практиці гібридний: запис, перенесення візиту та нагадування — сценарію, питання щодо підготовки та правил клініки — моделі, їх занадто багато для ручних гілок. Якість вимірюється часткою звернень, закритих без людини, і кількістю ескалацій до лікаря.
Часті технічні сумніви та відповіді на них
Перед стартом клініки ставлять один і той самий набір питань: хто відповідає за формулювання, як бот стикується з чинними системами, що відбувається при збої. Коротко відповідаємо на кожне.
Хто відповідає за відповіді пацієнтам?
Бот веде організаційну частину: запис, нагадування, документи, години прийому. Клінічні теми — діагнози, призначення, оцінка симптомів — поза його зоною: базу відповідей затверджує лікар.
Як складне звернення потрапляє до лікаря?
Діалог оцінюється за ознаками, які задає клініка: скарги на самопочуття, погіршення, питання про препарат. Таке звернення переходить до адміністратора або чергового спеціаліста з повним контекстом листування.
Підключитеся до нашої медичної системи?
Запис, розклад і картотека синхронізуються з чинною медичною інформаційною системою — за стандартом HL7 FHIR або через програмний інтерфейс вендора. Якщо система закрита, ставимо проміжний шар.
Як захищені дані пацієнтів?
Обробка відбувається в контурі замовника або в ізольованій хмарі, права розмежовані за ролями. Звернення до картки журналюються, діалоги для доопрацювання моделі беруться знеособленими.
Що буде при збої зовнішнього сервісу?
Бот не видає помилку, а переводить діалог на резервний маршрут: приймає контакт, ставить звернення в чергу до оператора, дає альтернативний спосіб зв’язку. Після відновлення історія потрапляє до загальної стрічки.
Обговоримо задачу: з чого починається налаштування
Налаштування починається не з коду, а з опису того, як клініка приймає пацієнтів. Поки немає переліку звернень і правил запису, сценарій залишається здогадкою, а приймання — спором про смаки. Ось що потрібно з боку клініки до старту проєкту.
- Перелік частих питань: вивантаження журналу реєстратури та кол-центру за кілька місяців, згруповане за темами — запис, перенесення, аналізи, підготовка до процедури. Так видно реальний розподіл звернень.
- Правила прийому та запису: спеціальності й філії, горизонт запису, дії при відмовах, кому передається складний випадок. Це основа гілок діалогу та передачі адміністратору.
- Доступи до систем: тестовий контур медичної інформаційної системи, довідник послуг, розклад лікарів, обмін із зовнішніми сервісами. Без тестового контуру бота нічим перевірити на реальних даних.
- Відповідальний з боку клініки: одна людина з правом вирішувати — вона зводить питання лікарів і адміністраторів і підтверджує формулювання. Без неї узгодження розповзається.
- Порядок узгодження сценаріїв: хто перевіряє тексти відповідей, чи потрібна медична вичитка, за який строк повертаються правки. Фіксуємо заздалегідь, щоб ітерації йшли одним маршрутом.
- Знеособлені приклади діалогів: кілька десятків звернень із відповідями адміністратора — на них налаштовуємо тон, довжину та межі, за які бот не виходить.
Першу версію сценаріїв збираємо одразу після отримання матеріалів, далі — ітераціями: показуємо діалоги, забираємо правки, фіксуємо наступну версію. Строки стають передбачуваними, а результат перевіряється на тестовому контурі до запуску.
