Добавить в корзинуПозвонить
Найти в Дзене

Личный кабинет в клинике: что оказалось сложнее самой разработки

Недавно снова вернулся к задаче, которая на бумаге выглядит очень простой: пригласить пациентов клиники пользоваться личным кабинетом. Ну правда, что там сложного? Есть ЛК. Есть пациенты. Есть ссылка. Администратор в клинике лично предлагает пациенту подключиться, кому-то дополнительно пишем сообщение — и вроде бы всё должно работать. Но, как обычно, реальность решила немного поиздеваться над красивой схемой. Потому что личный кабинет сам по себе не внедряется. Даже если он классный. А он, на мой взгляд, реально классный. Там можно смотреть записи, записываться на новые посещения, получать рекомендации после процедур и бонусные рубли. Пациенту всё равно нужно объяснить, зачем ему туда заходи
Оглавление

Недавно снова вернулся к задаче, которая на бумаге выглядит очень простой: пригласить пациентов клиники пользоваться личным кабинетом.

Ну правда, что там сложного?

Есть ЛК. Есть пациенты. Есть ссылка. Администратор в клинике лично предлагает пациенту подключиться, кому-то дополнительно пишем сообщение — и вроде бы всё должно работать.

Но, как обычно, реальность решила немного поиздеваться над красивой схемой.

Потому что личный кабинет сам по себе не внедряется. Даже если он классный. А он, на мой взгляд, реально классный. Там можно смотреть записи, записываться на новые посещения, получать рекомендации после процедур и бонусные рубли.

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

И вот тут задача перестаёт быть «дать пациенту ссылку или сказать пару слов на ресепшене». Она становится маленьким, но вполне настоящим бизнес-процессом: личное приглашение, сообщение, фиксация, контроль результата и следующий шаг.

С чего начал

Я сначала сформулировал для себя простую мысль: ЛК — это не просто страница на сайте.

Он должен стать нормальным рабочим сервисом между пациентом и клиникой.

Чтобы пациент мог:

  • посмотреть свои записи;
  • записаться на новое посещение;
  • получить рекомендации после процедуры;
  • в перспективе — работать с документами, справками и историей обращений.

А клиника при этом меньше теряла хвосты: повторные записи, вопросы после визита, рекомендации, документы и прочие мелочи, которые в операционке обычно расползаются по чатам.

И администратору должно быть проще. Не держать в голове, кому уже предлагали ЛК, кому нужно напомнить, кто заинтересовался, а кто пока не дошёл до регистрации.

Но сразу появились обычные практические вопросы:

  1. Как понять, у кого ЛК уже есть?
  2. Кого уже приглашали?
  3. Где это фиксировать?
  4. Что делать, если пациент ответил вопросом?
  5. Как не написать не тому человеку?
  6. Как сделать так, чтобы процесс не держался только на мне или на памяти администратора?

Вот это, на мой взгляд, и есть нормальная цифровизация. Не «мы внедрили инновационную платформу», а «мы нашли место, где постоянно теряется работа, и начали его приводить в порядок».

Что добавил в админке

Первое, что нужно было видеть — есть у пациента ЛК или нет.

В панели клиники в списке клиентов есть признак личного кабинета. Это уже помогает: можно отфильтровать людей, у которых ЛК ещё нет, и понять, с кем нужно работать.

Но одного признака мало.

Мне нужна была история: что с пациентом уже происходило.

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

Для меня это важная штука.

Комментарий в карточке клиента — это не «заметочка для красоты». Это способ не терять контекст.

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

Потому что «я вроде кому-то писала или говорила» — это не процесс. Это начало будущей путаницы.

Какие статусы нужны

Я выписал основные варианты: что с пациентом уже произошло и какой следующий шаг нужен.

  • не приглашали;
  • приглашение отправлено;
  • пациент задал вопрос;
  • ответили типовым сообщением;
  • нужен человек / нестандартный вопрос;
  • ЛК создан;
  • нужен повторный контакт;
  • пациент отказался;
  • контакт не найден или небезопасен для отправки.

Такие статусы нужны не ради красоты. Они помогают быстро понять, что уже было сделано и где следующий шаг.

Без них всё быстро превращается в «ну мы же вроде писали», «а кому именно?», «а она ответила?», «а ЛК появился?», «а кто должен был проверить?».

Я такие квесты не люблю. У них всегда плохой финал.

Почему выбрал Telegram

Канал тоже пришлось выбирать не по принципу «где моднее», а по реальности.

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

SMS — дорого и неудобно для диалога.

WhatsApp я не хочу делать основным каналом по понятным юридическим и операционным причинам.

Telegram в нашем случае выглядит логичнее: многие пациенты уже общаются с клиникой там, можно ответить на вопрос, не выглядит как сухая системная рассылка.

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

То есть задача стала такой: убрать приглашение из режима «если администратор вспомнила» и перевести его в понятный процесс: Telegram, карточка клиента, комментарий, статус и следующий шаг.

Почему нельзя отправить всем один текст

Технически можно.

Берём список, вставляем одинаковое сообщение, жмём отправить. Формально — работа сделана.

Но по ощущениям пациента это будет выглядеть как спам.

Поэтому я сразу заложил несколько правил:

  • обращаться по имени, если имя нормальное и не выглядит странно;
  • не ошибаться с родом;
  • учитывать контекст — был недавно, есть будущая запись, давно не был;
  • объяснять пользу ЛК, а не просто кидать ссылку;
  • упоминать 1000 бонусных рублей за начало использования;
  • оставлять возможность спокойно задать вопрос.

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

Но формулировка должна быть человеческой.

Не «уважаемый клиент, информируем вас о наличии функционала». Такое хочется закрыть ещё до второго предложения.

Где начался цирк с автоматизацией

Дальше я попробовал автоматизировать отправку через Telegram Web.

И вот тут начались танцы с бубнами 🙂

Вставить текст в поле и нажать кнопку — не проблема. Это как раз решается быстро.

Проблема в другом: нужно быть абсолютно уверенным, что открыт именно нужный чат.

А Telegram Web в этом месте оказался довольно капризным. Где-то чат не успевает прогрузиться. Где-то заголовок не совпадает. Где-то активный чат ведёт себя не так, как ожидаешь.

Для обычной личной переписки это неприятно. Для клиники — недопустимо.

Потому что сообщение уходит от имени клиники реальному пациенту. Ошибка «ой, отправили не туда» здесь не вариант.

Поэтому я добавил жёсткие проверки перед отправкой:

  • сначала сверить строку чата с ФИО;
  • открыть чат;
  • проверить заголовок;
  • посмотреть последние сообщения;
  • убедиться, что приглашение в ЛК ещё не отправляли;
  • проверить, что поле ввода пустое;
  • вставить только текущий текст;
  • после отправки проверить, что сообщение действительно появилось.

Если хоть что-то не сходится — не отправлять.

Да, это замедляет процесс. Зато сильно снижает шанс устроить себе проблему на ровном месте.

Что получилось

В базе есть пациенты без признака ЛК.

Потенциально кандидатов было больше двух сотен. Но безопасно сопоставить с Telegram-чатами получилось далеко не всех.

Часть отправок прошла нормально. Часть пришлось пропустить: где-то Telegram Web не открывал чат, где-то не получалось уверенно проверить заголовок, где-то были таймауты.

И я сознательно останавливал процесс.

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

Вообще это хороший тест на зрелость автоматизации.

Если система умеет только жать кнопку — это ещё не автоматизация. Это обезьяна с доступом к интерфейсу, которая может оказаться опаснее обезьяны с гранатой.

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

Что я из этого вынес

Первое: личный кабинет пациента — это не только разработка.

Можно сделать хороший сервис, но если не встроить его в ежедневную работу клиники, он будет жить отдельно. Где-то там, красивый и никому особо не нужный.

Второе: админка должна хранить историю действий, а не только данные.

Мне важно видеть в карточке пациента не просто ФИО и телефон, а контекст: приглашали ли его, отвечал ли он, открыл ли рекомендацию, нужен ли следующий шаг.

Третье: коммуникации с пациентами нельзя автоматизировать в режиме «и так сойдёт».

Особенно в медицине и косметологии. Здесь лучше быть занудным: проверить чат, текст, контекст, поле ввода и последние сообщения. Это занимает лишнее время, зато потом не приходится объяснять, почему пациент получил чужое сообщение.

Четвёртое: иногда хороший результат — это не отправленное сообщение, а вовремя остановленная отправка.

Звучит не так эффектно, но бизнесу от этого спокойнее.

Что дальше

Следующий шаг — уйти от хрупкого сценария через Telegram Web.

Сейчас смотрю в сторону более надёжной схемы: привязать пациента к конкретному Telegram-контакту в карточке, фиксировать отправки как события, отдельно обрабатывать ответы и по возможности уйти от хрупкого Telegram Web к API/боту или другому каналу, где меньше магии интерфейса и больше контроля.

Чтобы было понятно:

  • кому уже написали;
  • кто зарегистрировался;
  • кто задал вопрос;
  • кто требует внимания администратора;
  • кому нужен повторный контакт;
  • где всё это записано.

То есть цель не в том, чтобы «разослать 200 сообщений».

Цель — сделать нормальный управляемый процесс: приглашение → ответ → регистрация → дальнейшая работа с пациентом.

Вот такими задачами я сейчас занимаюсь в клинике.