Лучи: AI-система принятия решений в сервисе ДМС

За перепиской в ДМС прячется маршрут решения

Сервисный процесс ДМС легко недооценить, если смотреть на него как на переписку пациента с оператором. Переписка здесь только внешний интерфейс. Внутри каждого обращения лежит маршрут решения: что именно хочет пациент, подходит ли услуга под программу, можно ли записать в конкретную клинику, нужно ли согласование, нужно ли гарантийное письмо и какое действие вообще допустимо в CRM.

В сервисном процессе ДМС обращение редко живёт как один короткий вопрос. Пациент может неделями переписываться в одном глобальном чате: сначала спрашивал про консультацию, потом отменял запись, потом вернулся с новым запросом. Оператору мало “понять текст”. Ему нужно собрать решение из живого состояния процесса.

Из-за этого заявка может растягиваться почти на два часа. Скорость ответов тут роли не играет — сам процесс размазан во времени: пациент уточняет удобное окно, оператор ищет клинику, клиника отвечает по слотам, потом приходится перепроверять программу, потом оформлять гарантийное письмо, потом всё повторяется заново, если слот уже ушёл или пациент передумал.

Что делает систему сложной

1. Новый запрос нужно отделить от старого.
Вся переписка пациента хранится в одном общем чате на все обращения. Система должна найти первый новый смысловой запрос после даты обращения и не спутать его с продолжением старой темы. То есть ей нужно понимать не только текст, но и хронологию разговора внутри живого процесса.

2. Время здесь является частью смысла.
Фразы вроде “давайте завтра после обеда” или “могу в пятницу утром” нужно превращать не в красивый текст, а в конкретные окна времени, привязанные ко времени сообщения. Расплывчатые формулировки вроде “в ближайшие дни” вообще нельзя считать конкретным временем записи.

3. Решение собирается не из одного текста, а из состояния нескольких систем сразу.
На одно обращение приходится сшивать историю визитов, претензии, жалобы, предупреждения, согласования, историю гарантийных писем, полисы пациента, программу, клиники, ограничения по обязательному телемед-маршруту и текущий чат. То, что оператор делает глазами и опытом, системе пришлось разложить на отдельные источники и отдельные шаги.

4. Ошибка здесь бьёт по бизнес-действию.
Если AI ошибся в чат-боте поддержки, это неприятно. Если AI в сервисном процессе ДМС самостоятельно сделал запись не туда, выбрал клинику вне программы или отправил гарантийное письмо по неверному маршруту, ошибка уходит в рабочую систему и тянет за собой разбор, претензионку и пересборку процесса. Откат такого действия обходится компании на порядок дороже, чем если бы система просто остановилась и передала обращение оператору.

5. Время ответа задаёт бюджет архитектуры.
У обращения есть собственное окно по SLA: и на ответ пациенту, и на закрытие тикета. Бюджет вызовов модели на одно обращение в нём жёсткий — счёт идёт буквально на единицы. Длинные цепочки рассуждений с многократным переспросом сюда не помещаются. Каждый узел системы должен приносить пользу больше своей стоимости в этом бюджете, иначе в нём нет смысла.

Почему здесь не хватает готового инструмента

Со стороны задача кажется проще, чем есть на самом деле.

Именно поэтому здесь не сработал бы обычный сценарий “берём готовый инструмент, немного настраиваем и подключаем к внутренним системам”. Как только система начинает приносить пользу на одном участке, она сразу упирается в следующий слой операционных зависимостей. В таких процессах «умная надстройка» быстро дорастает до полноценной системы, которая сама готовит и проверяет действия.

Как устроена система

1. Понять, что именно пациент хочет сейчас

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

Рядом идут отдельные модули по претензиям и заметкам. Система устроена как набор узких агентов, у каждого своя задача и свой критерий качества, на котором его потом проверяют отдельно. Одной большой модели, которая понимает всё, в такой системе не получается: чем шире её зона ответственности, тем хуже она справляется с конкретным шагом. Поэтому система лучше держит границы и легче отлаживается на реальных кейсах.

2. Решить, ведём ли мы это обращение сами

После понимания запроса самый дорогой вопрос звучит так: имеем ли мы право это делать самостоятельно. На этом шаге система собирает все формализованные ограничения: доступна ли услуга, входит ли клиника в программу, нужно ли согласование, не упёрлись ли в лимит, действует ли обязательный телемед-маршрут, не было ли уже такого визита или гарантийного письма за последние тридцать дней.

Здесь проходит граница между AI и правилами: AI работает там, где есть смысловая неоднозначность, а всё, что связано с дорогой ошибкой, переезжает в явные проверки кодом. В крупных сервисных процессах это обязательное условие.

Дальше включается отдельный механизм оценки уверенности. На каждом узле система сверяет, насколько текущий разбор похож на эталонные кейсы. Если хоть в одной точке уверенность проседает, обращение целиком уходит оператору вместе с уже собранным контекстом. Этот шаг кажется техническим, но именно он определяет, окупится проект или нет: ошибочное самостоятельное действие в CRM обходится компании на порядок дороже, чем плановая передача в ручной режим.

3. Пройти по CRM так, чтобы оператор мог подхватить

Если оценка уверенности зелёная, система не останавливается на подсказке. Она проходит ровно тот же путь по CRM, что прошёл бы оператор: открывает те же сущности, заполняет те же поля, делает те же проверки в том же порядке. Визит, рекомендации по клиникам, гарантийное письмо, в некоторых сценариях — отмена записи. Каждый шаг оставляет следы в тех же местах, где их оставил бы человек.

Это сделано не из стилистических соображений: архитектура запасной линии совпадает с архитектурой основной. На любом шаге, где система упёрлась — в неуверенность, в редкий контекст, в нестандартную просьбу пациента — оператор просто открывает обращение и продолжает с того состояния, в котором система остановилась. Отдельного “режима ручного разбора” не существует, потому что ручной разбор и есть штатный режим CRM. Система работает внутри него на тех участках, на которых может справиться, и оставляет процесс в живом состоянии на тех, где справиться не может.

Со стороны оператора это выглядит просто: то же обращение, тот же CRM, часть полей уже заполнена.

Под “автоматически записывает пациента” внутри этого скрывается отдельная мини-система. Учитываются предпочтительная клиника, последняя клиника из истории, согласования, география, служебные исключения в списке клиник, онлайн-доступность и актуальные окна записи. Для части услуг система сначала отправляет запрос на расписание, ждёт ответ, отбирает подходящие окна и возвращает варианты оператору. Это уже ближе к координации записи, чем к генерации текста.

4. Датасеты — это и есть проект

Самым недооценённым оказался слой проверки качества. Воспринимается он обычно как “что-то поверх готовой системы”, но в реальности всё устроено наоборот. Сначала появляются наборы реальных кейсов с разметкой бизнеса — образцы того, как должны выглядеть правильно разобранный чат, сопоставленная услуга, заметка и гарантийное письмо. Только после этого можно осмысленно проектировать узлы системы, потому что у каждого узла появляется свой критерий “хорошо”.

Всё, что в таких проектах делается до датасетов, в основном выкидывается. Поэтому и сама работа сдвинута на этот слой: настройка промтов и архитектуры — это уже следствие того, как выглядят эталонные примеры на каждом узле.

После запуска эта же машинерия превращается в постоянный контур контроля. Каждую неделю эталонный датасет прокатывается по всей цепочке заново. Это нужно, потому что в живой системе постоянно дрейфуют входные данные, накапливаются новые правила и заметки, меняются программы и тарифы клиник. Без регулярного регресса в какой-то момент обнаруживается, что модель уже отвечает на старые кейсы не так, как отвечала на запуске, и это пропускается мимо.

Основная стоимость таких AI-систем сидит в умении доказать, что решение стабильно работает на реальных обращениях. Сама модель в этом бюджете обходится дешевле всего.

Где у этого процесса есть ROI

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

Слишком узкая зона действий агента не оправдывает инфраструктуры поддержки и проверок, и они начинают съедать экономию быстрее, чем она появляется. Слишком широкая зона тащит за собой ошибочные действия в CRM, и каждое такое действие стоит компании в разы больше, чем плановая остановка. Чем шире автономия, тем дороже отдельная ошибка.

Между этими краями есть узкая полоса ответственности, в которой автоматизация окупается. Весь проект — про её нахождение и про её удержание. Внедрение ступенями отсюда вытекает естественно: каждая ступень расширяет полосу настолько, насколько слой оценки уверенности успевает закрыть новые риски. Сначала система собирает контекст и подсказывает оператору, потом начинает предзаполнять сущности в CRM, потом берёт на себя обновление визита, работу с гарантийными письмами и отмены записей.

Для бизнеса это и есть главный вывод кейса. Перед тем, как считать ROI от AI-внедрения в сложном операционном процессе, имеет смысл сначала понять, есть ли у него вообще такая полоса. У многих процессов её нет: контекста слишком много, а граница допустимой автономии слишком тонкая, чтобы оценка уверенности могла её надёжно держать.

Что изменилось в процессе

В пилоте оператор перестал вручную сшивать чат, программу, историю, клиники, слоты и документы — его задача сузилась до проверки готового решения и подтверждения действия.

Там, где раньше заявка могла растягиваться почти на два часа из-за перепроверок, переписки с клиникой и подготовки документов, процесс сократился примерно до получаса. Но скорость здесь второстепенна. Проект врос в рабочий процесс настолько, что отделить его от CRM уже нельзя.

Этот кейс показывает, как сложный операционный процесс с дорогими ошибками можно безопасно отдавать AI ступенями. Каждая ступень начинается тогда, когда система научилась честно говорить, что находится за её границей. Это и есть рабочая форма AI в enterprise — система, которая знает свой край и не пытается его обходить.