Я хочу поделиться с вами особенностями внедрения и работы автоматизированного обзвона роботом на примере мониторинга здоровья пациентов, еще расскажу о том, что нужно учесть при выборе провайдера звонков, анализе и мониторинге системы.
Суть работы сервиса дистанционного мониторинга заключается в получении показателей здоровья пациентов при помощи обзвона роботом или устройств, обработке информации, внесении её в электронный дневник здоровья и передаче лечащему врачу. Врач видит все данные в динамике и, если замечает отклонения, то связывается с пациентом и консультирует его онлайн, рекомендует обратиться очно или вызвать врача на дом.
На нашем сервисе метрики здоровья собираются разными способами: через веб-версию, носимые устройства, звонки и приложение. Пациент сам выбирает, как ему удобнее вносить показания, но автообзвон всегда назначает врач. Сбор данных через звонок – один из наиболее удобных «продуктов» для пациентов: робот автоматически звонит в назначенные врачом дни, спрашивает о самочувствии и вносит показания в его «дневник здоровья».
Поговорим о провайдере
В нашем проекте нет своей телефонии – мы арендуем ресурсы у двух провайдеров и при необходимости можем переключать провайдера у одного или сразу нескольких пациентов.
Провайдер также должен предоставлять качественные услуги – обработка речи человека в режиме реального времени для нас крайне важна при его выборе. Система сбора и обработки должна уметь выделять существенную информацию при разговоре. Например, могут быть следующие реплики:
«Ой-ой, подождите, я сейчас найду, у меня записано. А! Вот - 36,6».
«Да, в последний раз было 180 на 90, если не ошибаюсь».
Если робот не сумеет распознать речь, то невозможно будет сообщить лечащему врачу о состоянии и занести замеры в дневник пациента. При большом количестве неудачных звонков бизнес может потерять солидную сумму денег.
Однако есть проблемы, которые не связаны с провайдером и решить их невозможно, если они вдруг возникнут: обрыв связи, номер недоступен, отвечает автоответчик или блокировка со стороны оператора связи. Пользователь мог сбросить звонок, потому что ему было неудобно отвечать. Мобильный оператор может принять это как не желательный звонок и номер помечается как АОН, и робот уже не может дозвониться пациенту, значит наблюдение прервется. Даже если сменить номер, с которого идёт звонок, то нет гарантии, что такая ситуация не повторится. Чтобы наблюдения не прерывать и продолжать собирать показания, мы внедрили перезвоны пациентам и определение статуса ответа роботом или человеком. К примеру, если разговор был очень короткий, мы помечаем как ответ робота, тогда перезвоним пациенту чуть позже. Или если наш робот не успел задать все вопросы и связь оборвалась, мы перезвоним.
Приоритеты очередей звонков
Наши ресурсы и провайдера не бесконечны, и мы не можем за одну минуту инициировать сразу несколько тысяч звонков. Точнее, можем, но тогда это становится неэффективным экономически. Но самое главное, нам это не нужно и не имеет никакого смысла. К тому же нужно учитывать, что между перезвонами пациенту должно пройти определенное количество времени. Это время не должно быть слишком коротким, чтобы не забить канал и не должно быть слишком большим, чтобы успеть позвонить в соответствующем часовом поясе.
Для этого провайдеры выделяют своим клиентам лимиты – каналы, которые можно использовать при запуске обзвона. Для грамотного распределения ресурсов мы внедрили метрику «Контактный пациент».
Эта метрика помечает человека, который всегда отвечает на звонок, или отвечает, но редко или совсем не отвечает. Чтобы нам расходовать свои лимиты эффективно – сначала звоним тем, кто отвечает на звонки всегда и далее тем, кто ответит 50/50 или вообще не возьмет трубку. Метрика у пациента может измениться: если он перестанет отвечать, то уйдет на последнюю очередь – и так по кругу. За счет такого подхода, у нас получилось уменьшить количество «пустых звонков, и расходов на инфраструктуру.
У очередей звонков в нашей реализации есть одна болезнь, которую мы сейчас «лечим». Отбор пациентов на звонок идет только в текущем часовом поясе. Пока время не вышло, мы должны успеть прозвонить не только контактным пациентам, но и тем кто просто не взял трубку. У нашей системы есть бизнес-правило – в день перезваниваем четыре раза. Больше и меньше смысла нет, т.к. пациент может быть занят и сейчас не может говорить или он совсем не хочет разговаривать. Получается, что мы просто позвонили в неудобное время, либо будем надоедать звонками. И случаются такие ситуации, что мы не выполняем наше правило по перезвонам. Под конец часового пояса мы звоним пациенту, пациент не берет трубку и наступает следующий часовой пояс, и выполнить перезвон пациенту еще раз мы не успеваем. Все потому, что в новом часовом поясе будут новые пациенты, которым нужно успеть перезвонить и одновременно не забить канал.
Мониторинг звонков
Несмотря на то, что код продукта уже давно отлажен, покрыт тестами и работает без перебоев, всё равно могут возникнуть инфраструктурные проблемы. Вся кухня инициализации и обработки работает через Cron, который отбирает нужных абонентов и отправляет пул номеров нашему провайдеру, для мониторинга Cron используется healthchecks.io. Можно настроить отправку уведомлений на удобный мессенджер. Тогда команда DevOps или разработчики смогут быстро починить поломку.
Использование Cron задач в этом случае – не самый удачный инструмент. Когда происходит запуск задач на парсинг, у нас запускается процесс, который может завершаться очень долго или не завершаться вовсе. Для управления этими процессами лучше подходит Supervisord, который мы планируем внедрить в работу. Его можно настроить на исполнение по времени или по памяти. Но это уже тема для новой статьи.
Аналитика звонков
В работе системы и звонков мы используем аналитику в реальном времени, настроенную через дашборд в Grafana. Там отслеживаем несколько важных метрик: количество пациентов, которым позвонили, количество обрабатываемых звонков в текущий момент времени, ошибок при парсинге, среднее время продолжительности звонка. Метрики помогают принять решение, как чувствует себя наш сервис, все ли стабильно работает.
Аналитика звонков тесно связана с днем недели и часовым поясом. Со временем выработались определенные нормы, за которыми мы следим.
Если какая-то из метрик не сходится или ведет себя странно, вероятно есть проблема в общей цепочке процесса обзвона и необходимо анализировать проблему детальнее. Например, одна из таких метрик, «среднее время звонка» (правый снизу квадрат 29.8). По будням эта метрика должна находиться в районе 30 секунд. Если в будний день она находится в районе 10 секунд, но при этом у нас прозвонили хотя бы 300-400 человек, у нас проблемы. Тогда нужно идти к провайдеру с этой проблемой.
У нас есть «день звонков», когда мы звоним всем активным пациентам, которые находятся на мониторинге в системе. Это вторая важная метрика. В этот день мы должны прозвонить большинство пациентов в первой половине дня. Не стоит забывать о пациентах, которых отключают от мониторинга. Врач может сам снять с автообзвона и выписать человека. Соответственно количество пациентов, которым звоним уменьшится. Это следует учитывать при анализе проблем.
Часовые пояса тоже нельзя игнорировать: звонки не должны застать пациента ночью или рано утром, когда он еще не измерил свой пульс или уровень сахара в крови. Иначе от такой автоматизации будет больше вреда, чем пользы.