Собственное приложение выглядит признаком солидной клиники, но не всегда повышает выручку. Давайте разберемся.
Клиника хочет, чтобы приложение помогало клиентам и повышало выручку, а у пациента может быть и свой взгляд на приложения. Он оценивает, стоит ли ради нескольких записей в год устанавливать программу, создавать аккаунт, подтверждать телефон, разбираться в интерфейсе и доверять ей медицинские данные.
Из-за этой разницы клиника может несколько миллионов рублей потратить на разработку, интеграцию и поддержку продукта, который нужен сотне активных пользователей. Скачивания при этом будут выглядеть убедительно, особенно если администраторы просят каждого пациента установить приложение. Реальное использование окажется гораздо ниже.
Проблема приложения редко начинается в магазине приложений. Сначала клиника должна доказать, что у пациента есть регулярная задача, которую сайт, личный кабинет или сообщение решают хуже.
Пациенту невыгодно устанавливать приложение ради редкого действия
Для клиники запись, результаты, напоминания и повторные продажи образуют единую систему. Для пациента обращение в медицинский центр часто остаётся отдельным эпизодом.
Он может:
- один раз сделать МРТ;
- пройти операцию и больше не возвращаться несколько лет;
- выбрать другого врача для следующей консультации;
- записывать ребёнка или пожилого родственника со своего телефона;
- пользоваться несколькими лабораториями и клиниками;
- получать ссылку на результаты без установки программы;
- предпочитать звонок, сайт или привычный мессенджер.
Каждое дополнительное действие уменьшает долю пользователей: установка, регистрация, код из СМС, создание профиля пациента, согласия, поиск нужного раздела. Если после этого человек видит прайс, новости и обычную форму записи, ценность продукта для него заканчивается.
Приложение клиники конкурирует с телефоном, сайтом, мессенджером и привычкой пациента ничего лишнего не устанавливать.
Отдельная проблема медицинских приложений — связь аккаунта с пациентом. Запись может создавать жена для мужа, дочь для матери или родитель для ребёнка. Приложение, построенное по принципу «один телефон — один пациент», ломается уже на распространённом семейном сценарии.
Приложение должно приносить пользу и пациенту, и клинике
Приложение будет жить только при одновременной пользе для пациента и клиники.
| Польза для пациента | Польза для клиники |
|---|---|
| Быстрее выполнить регулярное действие | Снизить нагрузку на регистратуру |
| Получить результаты и документы в одном месте | Сократить количество ручных сообщений |
| Видеть следующий этап лечения | Уменьшить число пропущенных визитов |
| Перенести запись без звонка | Повысить вероятность повторного обращения |
| Пользоваться несколькими филиалами и врачами | Согласовать работу сети и расписаний |
| Управлять профилями членов семьи | Сократить ошибки при записи и идентификации |
Если выгода существует только для клиники, пациент устанавливает приложение по просьбе администратора и перестаёт открывать после визита. Если пользу получает только пациент, а сотрудники продолжают вручную переносить сведения между приложением и МИС, клиника финансирует дорогой дополнительный интерфейс.
Приложение оправдано, когда пациент регулярно повторяет одни и те же действия
Повторные исследования и история результатов делают приложение полезным для лабораторной сети
Пациент несколько раз в год сдаёт анализы, получает результаты, сравнивает показатели, выбирает ближайший филиал и повторяет исследования. История результатов и единая запись создают понятную причину вернуться в приложение.
Особенно полезны:
- результаты с динамикой показателей;
- повтор заказа по прежнему набору исследований;
- поиск филиала и свободного времени;
- подготовка к анализу или исследованию;
- управление профилями детей и родственников;
- оплата и получение документов.
Единое приложение помогает только при едином расписании сети
Приложение может объединить филиалы, врачей и историю организационных действий пациента. Польза появляется, если человек действительно обращается в разные подразделения, а данные обновляются автоматически.
Когда филиалы работают раздельно, расписание расходится с реальностью, цены не совпадают, а записи подтверждают вручную, приложение покажет пациенту внутренний беспорядок сети.
Длительное лечение создаёт регулярный сценарий использования
В репродуктивной медицине, ортодонтии, реабилитации и программах наблюдения пациент проходит несколько связанных этапов. Приложение может показывать план, подготовку, назначения, документы, следующий визит и канал связи с координатором.
Здесь несколько сотен активных пользователей способны создать больше пользы, чем несколько тысяч случайных установок. Цена пропущенного этапа и объём ручной координации намного выше.
Большой перечень услуг не заменяет возвращающуюся базу пациентов
Широкого перечня услуг недостаточно. Нужна заметная доля пациентов, которые пользуются несколькими направлениями, регулярно возвращаются и видят преимущество единого цифрового кабинета.
При редких обращениях приложение становится лишним расходом
Один филиал и редкие визиты не создают достаточной частоты использования
Если пациент легко записывается через мобильный сайт и возвращается раз в год, приложение добавляет мало ценности. Разработка не увеличит пропускную способность клиники, если расписание уже заполнено, не хватает врачей или кабинетов.
Для разового лечения часто достаточно защищённого веб-кабинета
Пациент может выбрать клинику для операции, консультации или короткого курса и больше не обратиться несколько лет. Для подготовки, документов и послеоперационного сопровождения может хватить защищённого веб-кабинета.
Приложение переносит проблемы неработающей записи в новый канал
Устаревшие цены, пропущенные звонки, неверное расписание и медленные ответы перейдут в новый канал. Приложение не исправляет процесс, который клиника не наладила внутри.
Каталог не даст установок без собственной активной аудитории
Размещение приложения в каталоге не создаёт автоматически поток установок. Клинике всё равно придётся объяснять пользу продукта на сайте, после визита, в филиалах и сообщениях.
Частота действий пациентов важнее размера клиники
| Ситуация | Потенциальная польза | Главный вопрос владельца |
|---|---|---|
| Один филиал, редкие повторные визиты | Обычно низкая | Какую задачу нельзя решить через сайт или сообщение? |
| Одна клиника с длительными программами | Возможна даже при небольшой аудитории | Сколько действий пациента и координатора повторяется каждый месяц? |
| Сеть из пяти клиник в одном городе | Может быть заметной | Пользуются ли пациенты разными филиалами и единым расписанием? |
| Сеть лабораторий | Часто высокая | Нужны ли пациентам история результатов и регулярные повторные заказы? |
| Узкопрофильная хирургическая клиника | Зависит от сопровождения | Нужен ли полноценный продукт после завершения лечения? |
| Многопрофильная сеть | Зависит от возвращаемости | Какая доля базы использует несколько направлений? |
Город влияет меньше, чем частота взаимодействия. В миллионнике приложение может помочь выбирать филиал и свободное время. В небольшом городе один диагностический центр с большой постоянной базой тоже может получить пользу. Размер населения сам по себе ничего не решает.
Размер пациентской базы не равен числу пользователей приложения
Владелец легко переоценивает аудиторию. В МИС может храниться 100 000 карт, но это не 100 000 будущих пользователей приложения.
Считать нужно последовательно:
- Активные пациенты — обращались за последние 12 месяцев.
- Подходящая аудитория — имеет регулярное действие, которое приложение упрощает.
- Установившие — скачали приложение.
- Активированные — зарегистрировались и впервые записались, оплатили услугу или получили результат.
- Сохранившиеся пользователи — продолжают пользоваться через 30, 90 и 180 дней.
- Экономически полезные пользователи — совершают действия, которые приносят доход, уменьшают пропуски или экономят время сотрудников.
Формула воронки:
Полезные пользователи = активные пациенты × доля пациентов с регулярным сценарием × доля установок × доля активаций × доля сохранившихся пользователей.
Отраслевой универсальной нормы здесь нет. Частота обращения, возраст аудитории, вид лечения, стоимость визита и устройство процессов дают слишком разные результаты. Клинике нужна собственная воронка по группам пациентов.
У сети из 30 000 пациентов регулярными пользователями могут стать 1 365
Сеть принимает 30 000 активных пациентов в год.
- 12 000 несколько раз в год получают результаты или повторяют исследования;
- 4 200 готовы установить приложение;
- 2 730 регистрируются и получают первый результат;
- 1 365 продолжают пользоваться приложением спустя три месяца;
- каждый из них совершает в среднем два полезных действия в месяц.
Получается около 2 730 самостоятельных действий ежемесячно. Дальше владелец проверяет, какие из них заменили звонок, помогли провести повторное исследование, уменьшили число пропусков или сэкономили время сотрудника.
Из 30 000 активных пациентов регулярными пользователями стали 1 365 — около 4,6%. Это не плохой и не хороший показатель сам по себе. Его нужно сопоставить с расходами и полученным эффектом.
У стоматологии из 3 000 пациентов может остаться 70 активных пользователей
Стоматология принимает 3 000 пациентов в год.
- регулярная цифровая функция нужна примерно 600 пациентам;
- приложение устанавливают 210;
- регистрацию и первое полезное действие завершают 137;
- через три месяца остаётся около 70 активных пользователей.
При такой аудитории мобильный сайт, ссылка на план лечения и автоматические напоминания могут решить задачу дешевле.
В программе ЭКО 280 пользователей могут оказаться ценнее 5 000 установок
В программе одновременно находятся 450 пациентов. Приложением регулярно пользуются 280. Число кажется небольшим по сравнению с лабораторной сетью, однако каждый пользователь проходит несколько этапов, получает назначения и взаимодействует с координатором.
Если продукт сокращает ручные напоминания, помогает не пропускать подготовку и снижает число организационных ошибок, 280 пользователей могут оправдать решение лучше, чем 5 000 человек, которые открывают приложение ради просмотра прайса.
Все проценты и числа в примерах условные. Они показывают метод расчёта, а не норматив для клиник.
Приложение окупается через конкретную экономию и дополнительную прибыль
Скачивания не окупают разработку. Экономический эффект складывается из конкретных изменений:
- меньше звонков и сообщений по типовым вопросам;
- меньше пропущенных визитов;
- больше завершённых записей;
- больше повторных обращений;
- меньше ручной работы координаторов;
- меньше ошибок в расписании и документах.
Из эффекта вычитают:
- проектирование и разработку;
- интеграцию с МИС, расписанием, оплатой и личным кабинетом;
- защиту и хранение данных;
- тестирование;
- поддержку пользователей;
- обновления операционных систем;
- публикацию и сопровождение версий в магазинах;
- продвижение приложения среди пациентов.
Базовая формула:
Годовой эффект = сэкономленные расходы + дополнительная маржинальная прибыль − полная стоимость владения приложением.
Минимально необходимое количество полезных пользователей можно оценить так:
Годовая стоимость владения ÷ годовой эффект от одного активного пользователя.
При эффекте 1 200 рублей на человека расходы 2,4 млн требуют 2 000 пользователей
Допустим, разработка уже выполнена, а интеграции, поддержка, обновления и аналитика обходятся клинике в 2,4 млн рублей в год. Один регулярный пользователь приносит или экономит в среднем 1 200 рублей в год.
Для покрытия расходов требуется около 2 000 экономически полезных пользователей:
2 400 000 ÷ 1 200 = 2 000.
Если реалистичная воронка даёт 500 пользователей, продукт в существующем виде не окупается. Возможны три решения: сократить стоимость владения, увеличить полезность для пациента или перейти на более простой инструмент.
Расчёт по общей выручке опасен. Повторная запись на 5 000 рублей не даёт клинике 5 000 рублей эффекта. Учитывать нужно маржинальную прибыль и только тот результат, который появился благодаря приложению.
Скачивания скрывают результат: считать нужно действия, сохранение и деньги
| Показатель | Что он показывает |
|---|---|
| Установки | Сколько человек скачали приложение |
| Завершённые регистрации | Смогли ли пациенты начать пользоваться продуктом |
| Активации | Совершили ли первое полезное действие |
| Активные пользователи за месяц | Возвращаются ли пациенты в приложение |
| Сохранение через 30, 90 и 180 дней | Не исчезает ли использование после первого визита |
| Целевые действия | Записи, оплаты, результаты, переносы, подтверждения |
| Доля успешно завершённых действий | Работает ли основной сценарий без ошибок |
| Повторные визиты пользователей | Связано ли использование с возвращаемостью |
| Снижение звонков и ручных операций | Экономит ли продукт время сотрудников |
| Стоимость активного пользователя | Во сколько клинике обходится реальное использование |
| Экономический эффект | Покрывает ли польза полную стоимость владения |
Открытие приложения не следует считать целевым действием. Пациент мог зайти, не найти нужную функцию и позвонить администратору.
Каждый провал в воронке требует своего решения
| Что происходит | Возможная причина | Что проверить и изменить |
|---|---|---|
| Пациенты не устанавливают приложение | Польза непонятна или слишком мала | Сформулировать одно сильное преимущество для конкретной группы пациентов |
| Устанавливают, но не регистрируются | Сложный вход, ошибки СМС, лишние поля | Сократить регистрацию и проверить её на реальных пациентах |
| Регистрируются и больше не возвращаются | Приложение решает разовую задачу | Найти повторяемый сценарий или отказаться от ожидания регулярного использования |
| Смотрят результаты, но звонки не уменьшаются | В приложении нет пояснений или следующего шага | Показать подготовку, дальнейшее действие и понятный канал связи |
| Записываются, но расписание неверное | Слабая интеграция с МИС | Исправить обмен данными до продвижения приложения |
| Много открытий, мало записей и оплат | Измеряется активность без бизнес-результата | Перестроить отчёт вокруг завершённых целевых действий |
| Уведомления отключают | Клиника отправляет слишком много рекламы | Разделить сервисные и рекламные сообщения, учитывать согласия и частоту |
| В разных магазинах разные версии | Нет управляемого процесса выпуска | Назначить ответственного и синхронизировать релизы |
До разработки клиника должна доказать регулярную потребность пациента
Владелец должен получить ответы до утверждения бюджета:
- Какое действие пациент повторяет регулярно?
- Сколько пациентов выполняет его в течение года?
- Как они решают задачу сейчас?
- Что приложение сделает быстрее, проще или надёжнее?
- Почему мобильного сайта или личного кабинета недостаточно?
- Готовы ли пациенты устанавливать программу ради этой функции?
- Как будут работать профили детей и родственников?
- Какие системы придётся интегрировать?
- Кто будет поддерживать сведения, пользователей и новые версии?
- Какой показатель станет основанием продолжить проект, изменить его или закрыть?
Фраза «у конкурентов уже есть приложение» не отвечает ни на один из этих вопросов.
Сайт и личный кабинет стоит проверить раньше полноценного приложения
Клинике не обязательно сразу создавать полноценное мобильное приложение. Возможна последовательная проверка:
- Адаптивная страница услуги и простая онлайн-запись.
- Ссылка на результаты и документы без сложной регистрации.
- Напоминания и подготовка к визиту в сообщении.
- Личный кабинет в браузере.
- Управление несколькими профилями пациента.
- PWA или мини-приложение для регулярного сценария.
- Полноценное приложение после подтверждения спроса.
Каждый следующий уровень требует больше денег и постоянной поддержки. Переход имеет смысл, когда предыдущий вариант уже не справляется с задачей.
RuStore расширяет распространение полезного приложения, но не создаёт спрос
RuStore решает задачу распространения Android-приложения. В официальной консоли разработчик может загрузить приложение, отправить его на модерацию, публиковать новые версии и смотреть статистику. Площадка поддерживает APK- и AAB-файлы.
Добавлять RuStore имеет смысл, если:
- приложение уже решает подтверждённую задачу пациента;
- среди аудитории есть пользователи, которым нужен этот способ установки;
- клиника готова сопровождать ещё одну официальную версию;
- релизы в разных магазинах выходят согласованно;
- пациент видит, что устанавливает официальное приложение клиники;
- клиника умеет приводить подходящих пользователей на страницу установки.
Большая аудитория магазина не равна аудитории конкретного медицинского приложения. Карточка в каталоге создаёт техническую доступность. Спрос формируют польза продукта, активная база клиники и понятное предложение пациенту.
Если приложения ещё нет, выбор магазина не должен становиться первым этапом проекта.
За результат приложения совместно отвечают руководитель и команда проекта
Решение нельзя полностью передать разработчику или маркетологу.
| Участник | Ответственность |
|---|---|
| Владелец или руководитель | Бизнес-задача, бюджет и критерий остановки |
| Руководитель клиентского сервиса | Реальные трудности пациентов и нагрузка на администраторов |
| Медицинский руководитель | Корректность медицинской информации и сценариев сопровождения |
| Специалист по МИС | Расписание, данные и интеграции |
| Разработчик | Работа продукта, обновления и исправление ошибок |
| Специалист по защите данных | Требования к хранению и передаче информации |
| Аналитик | Связь использования с записями, визитами, экономией и оплатами |
| Маркетолог | Объяснение пользы подходящей аудитории, без искусственного разгона скачиваний |
Решение зависит от этапа: идеи, установки, активации или окупаемости
| Ситуация | Решение |
|---|---|
| Приложения ещё нет, повторяемый сценарий не найден | Не начинать разработку |
| Задача есть, но её закрывает мобильный сайт | Улучшить сайт и измерить результат |
| Есть регулярная задача и большая подходящая аудитория | Проверить прототип и посчитать экономику |
| Приложение уже разработано, установок мало | Проверить ценность предложения и путь установки |
| Установки есть, активаций мало | Исправить вход и первое целевое действие |
| Активации есть, регулярного использования нет | Проверить, существует ли повторяемая задача |
| Пользователи активны, экономического эффекта нет | Пересчитать метрики и стоимость владения |
| Приложение полезно, но недоступно части Android-аудитории | Добавить подходящие магазины, включая RuStore |
Главные вопросы владельца сводятся к аудитории, пользе и окупаемости
Минимальное число пользователей зависит от ценности одного сценария
Единого минимального числа нет. Для массовой функции с небольшой ценностью могут потребоваться тысячи регулярных пользователей. Для дорогостоящей длительной программы достаточно нескольких сотен, если приложение заметно сокращает работу координаторов, ошибки или потери пациентов.
Один филиал может оправдать приложение при длительном лечении
Иногда. Решение зависит от частоты взаимодействия и сложности лечения. Один филиал с программами диализа, реабилитации или длительного наблюдения может иметь более сильный сценарий, чем крупная клиника с преимущественно разовыми визитами.
Приложение чаще удерживает существующих пациентов, чем привлекает новых
Самостоятельно — редко. До установки пациент уже должен узнать о клинике и увидеть пользу продукта. Приложение чаще работает с существующей базой, повторными обращениями и сопровождением.
Полезные действия важнее скачиваний и открытий
Важны пациенты, которые регулярно завершают полезные действия. Даже активность без записей, результатов, оплат, экономии времени или снижения пропусков может оказаться пустой метрикой.
Количество магазинов выбирают по устройствам собственной аудитории
Следует проверить устройства и способы установки у собственной аудитории. Каждый дополнительный магазин требует сопровождения версий, карточек, отзывов и обновлений.
Критерий остановки проекта устанавливают до разработки
Критерий устанавливают до разработки. Например: минимальное количество активированных пользователей, доля регулярного использования, снижение звонков, рост повторных визитов или срок выхода на окупаемость. Если после согласованного периода показатели не достигнуты, владельцу нужен пересмотр продукта, а не бесконечное финансирование.
Приложение создают после подтверждения пользы и экономики
Собственное приложение оправдано, когда пациент регулярно решает через него важную задачу, а клиника получает измеримый экономический эффект. Размер базы, количество функций, наличие приложения у конкурентов и карточка в RuStore сами по себе этого не доказывают.
Сначала клиника считает подходящую аудиторию, проверяет сценарий на пациентах и сравнивает приложение с более простыми решениями. Затем оценивает стоимость владения и определяет минимальное количество экономически полезных пользователей. Только после этого стоит заказывать разработку или расширять число магазинов распространения.