Разработка портала для аптеки: где ломается логика заказа
Разработка портала для аптеки почти всегда упирается не в витрину, а в три места, где логика заказа расходится с реальностью. Первое — остатки. Каталог лекарств показывает наличие из кэша, который обновляется раз в несколько минут или раз в сутки, а на кассе товар уже продан или списан по сроку. Клиент бронирует позицию, приходит, и её нет — доверие к порталу теряется с первого такого случая.
Второе — геопоиск аптек. Если он строится по прямой дистанции до точки, а не по реальному маршруту, портал ведёт человека к ближайшей по карте аптеке, до которой на деле ехать дольше, чем до соседней. Отдельная беда — привязка к неточным координатам: адрес определяется по центру района, и выдача съезжает на километр, хотя рядом есть точка с нужным препаратом.
Третье — бронирование товара без подтверждения. Заявка уходит в никуда: аптека не видит её в своей очереди, клиент считает, что товар за ним, а срок брони не ограничен. Всё это не косметика витрины, а разрыв между интерфейсом и учётной системой аптеки.
Разбираем, как это закрывается: синхронизация остатков с учётной системой в реальном времени, геопоиск по маршруту и подтверждённая бронь с понятным сроком жизни.
Что даёт портал с каталогом и бронью
Поиск нужного препарата за секунды, а не за звонок
Каталог с остатками строится на регулярной синхронизации с учётной системой аптечной сети: позиции, фасовки, аналоги и наличие по каждой точке обновляются с заданным интервалом. Посетитель вводит действующее вещество или торговое название и сразу видит, где препарат есть сейчас, — без уточняющих звонков и поездок «на удачу». Поиск по аптекам с учётом района, часов работы и близости к маршруту сокращает путь от запроса до конкретной точки до одной-двух минут.
Бронирование без звонка и предсказуемая доля подтверждений
Бронь оформляется в интерфейсе: клиент выбирает аптеку, фиксирует позицию и получает подтверждение, а сотрудник видит заказ в своей очереди. Срок хранения брони настраивается под логистику сети, поэтому товар не «зависает» на полке, а доля подтверждённых броней растёт за счёт автоматической проверки остатка в момент оформления. Если позиции нет, система предлагает ближайшую точку или аналог — клиент не уходит с пустым результатом.
Нагрузка на операторов падает на рутинных обращениях
Типовые вопросы — «есть ли в наличии», «до скольки работает», «можно ли отложить» — закрываются порталом без участия человека. Операторы переключаются на сложные случаи: рецептурные позиции, доставку, претензии. При том же штате сеть обрабатывает больше обращений в пиковые часы, а время ответа на линии не растёт.
Управляемость вместо ручных сверок
Администратор видит статистику по точкам: что ищут, что бронируют, где отказывают чаще. Эти данные ложатся в закупки и распределение остатков между аптеками — ассортимент подстраивается под реальный спрос, а не под прошлогодние отчёты.
Способы связать каталог с остатками аптек
Связка каталога с реальными остатками — самая хрупкая часть портала: если данные о наличии отстают, покупатель бронирует то, чего на полке нет, и звонок в аптеку превращается в отказ. Выбор способа синхронизации определяет, как часто обновляются остатки, что происходит при недоступности учётной системы и сколько ручной работы ложится на сотрудников аптеки.
Мы работали со всеми тремя схемами и видим их так.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Прямая интеграция с учётной системой | Одна-две аптеки, один поставщик учётного ПО, стабильный канал связи | Любой сбой учётной системы роняет остатки на портале; обновление привязано к её регламенту; при росте сети число точек интеграции растёт лавинообразно |
| Промежуточный слой | Сеть аптек, разные учётные системы, нужна частота обновления выше, чем даёт учётный контур | Требует отдельного сервиса и его сопровождения; расхождения между слоем и учётной системой нужно разбирать регламентом |
| Ручное обновление | Небольшой ассортимент, редкие изменения, нет доступа к учётной системе | Остатки устаревают в течение дня; ошибки ввода; бронирования на отсутствующий товар |
Почему промежуточный слой обычно выигрывает
Он забирает данные из учётной системы по расписанию, нормализует их к единому виду и отдаёт каталогу. Частота обновления задаётся отдельно от регламента учётного контура — остатки можно подтягивать заметно чаще, а при недоступности системы портал продолжает работать на последнем срезе, помечая данные как «уточняются».
Что решаем на этапе проектирования
Определяем, какие события считаются изменением остатка, как разруливаются конфликты между слоем и учётной системой и что видит покупатель, если данные устарели. Отдельно фиксируем правила бронирования: сколько держится резерв и когда он автоматически снимается.
Как мы строим портал: этапы работ
Работа идёт итерациями по 1-2 недели: каждая заканчивается демонстрацией на тестовом контуре, а не отчётом в документе. Так заказчик видит работающий геопоиск и бронь задолго до финальной сдачи и может скорректировать приоритеты, пока изменения дешевы.
- Аудит данных и текущих систем. Собираем, откуда приходят товары и остатки: выгрузка из учётной системы, прайсы поставщиков, ручные таблицы. Фиксируем частоту обновления, дубли позиций, расхождения в единицах измерения и правила сопоставления аптек с адресами — это фундамент, на котором дальше держится весь каталог.
- Проектирование схемы интеграции. Определяем, что тянем в реальном времени, а что пакетно по расписанию, как обрабатываем недоступность источника и что показываем пользователю, если остатки не пришли. Отдельно описываем поведение при отмене брони и возврате позиции в продажу.
- Сборка каталога и геопоиска. Реализуем поиск по названию, действующему веществу и форме выпуска, ранжирование по расстоянию и наличию. Проверяем на реальных адресах: как ведёт себя выдача на границе районов, при неточных координатах и в час пик по нагрузке.
- Настройка брони. Прописываем срок жизни брони, лимиты на позицию и на пользователя, повторные брони, уведомления о готовности заказа. Согласуем сценарии с фармацевтами: что делать при частичном наличии и как снимать бронь, если клиент не пришёл.
- Проверка сценариев. Прогоняем сквозные пути: поиск, выбор аптеки, бронь, подтверждение, выдача. Отдельно — отказы: пустой остаток, закрытая точка, потеря связи с учётной системой, одновременная бронь последней упаковки двумя клиентами.
- Передача портала. Разворачиваем на боевом контуре, настраиваем резервное копирование и мониторинг доступности, передаём доступы и документацию. Обучаем сотрудников аптек работе с очередью броней.
Параллельно с разработкой ведём журнал решений: почему выбран такой интервал синхронизации, как считается расстояние, что происходит при конфликте остатков. На передаче он превращается в инструкцию для вашей команды — портал можно развивать без нас.
Что заказчик получает на руки
Портал для аптеки живёт не в вакууме: у него есть владелец со стороны бизнеса, дежурный инженер и подрядчик, который подключается к доработкам. Чтобы передача не превращалась в археологию по чужим файлам, мы отдаём проект как комплект артефактов — с описанием того, как система устроена и как её сопровождать.
- Схема данных — связи между товарами, аптечными пунктами, остатками, бронированиями и пользователями, с описанием ключей и ограничений целостности.
- Конфигурации окружений — параметры подключения к каталогу, геопоиску и внешним справочникам лекарств, раздельно для тестового и рабочего контуров.
- Регламент обновления — порядок выкладки новой версии, проверки миграций и отката на предыдущий релиз, если проверки не прошли.
- Документация портала — точки интеграции, форматы обмена, поведение при недоступности внешнего сервиса и логика пересчёта остатков.
- Политики доступа — роли сотрудников аптеки и администраторов, границы видимости данных и правила работы с персональными данными клиентов.
- Описание бронирования — жизненный цикл заявки от создания до выдачи или отмены, включая срок годности резерва и повторное освобождение товара.
- Инструкция для дежурной смены — что проверять при жалобе на поиск или бронь и по каким признакам отличать сбой каталога от проблемы на стороне аптеки.
Такой комплект снимает зависимость от конкретных людей: новый инженер входит в проект по документации, а не по переписке. Опишите задачу — вернёмся с оценкой и планом, включая состав передаваемых материалов.
Кейс: портал для сети аптек с геопоиском
Сеть из нескольких десятков аптек пришла с классической проблемой: остатки в каталоге расходились с реальным наличием на полке. Клиент выбирал товар, ехал в конкретную точку — и не находил его. Доля таких обращений доходила до трети от всех бронирований, а фармацевты тратили смену на звонки и ручное подтверждение вместо работы с покупателем.
Мы перестроили обмен данными между кассовым контуром и порталом. Остатки по каждой точке стали обновляться по событиям продажи и прихода, а не по расписанию раз в несколько часов, поэтому позиция уходит из доступных к брони почти сразу после продажи. Геопоиск ранжирует точки не по прямой линии, а по реальному маршруту и часам работы: если ближняя аптека закрыта или товара там нет, покупатель сразу видит следующую подходящую.
Аптечная сеть получила портал, где бронь подтверждается автоматически, а спорные позиции уходят фармацевту отдельной очередью с приоритетом. Среднее время подтверждения сократилось с нескольких часов до минут, доля отмен по причине «товара не оказалось» упала почти до нуля, а нагрузка на смену за счёт снятых звонков снизилась примерно на четверть.
Отдельно закрыли сценарий частичного заказа: если из трёх позиций подтвердились две, покупатель видит это до визита и решает, забирать ли остаток. Такой шаг убрал основную причину негатива на кассе и разгрузил поддержку.
Чем отличается бронь от резерва в аптечном портале?
Бронь и резерв — разные сущности, и путать их в аптечном портале дорого. Бронь фиксирует намерение клиента: заказ привязан к конкретному человеку, у него есть срок хранения брони, по истечении которого позиция возвращается в свободный остаток. Резерв — это физическое удержание упаковки на полке под уже подтверждённый заказ, и он уменьшает доступный остаток для всех остальных покупателей сразу. Пока товар лежит в резерве, его не продаст офлайн-кассир и не забронирует другой посетитель портала.
Разница проявляется в момент отмены брони. Если клиент отказался до подтверждения, система просто снимает удержание — остаток возвращается в каталог, никаких действий персонала не требуется. Если же отменяется подтверждённый резерв, нужен сценарий возврата: кладовщик снимает физическую метку, товар снова становится доступным, а история операции остаётся в журнале для сверки. Без этого расхождения между данными портала и фактическим наличием накапливаются за считаные дни.
Выбор режима зависит от модели работы аптеки. Для самовывоза с коротким окном достаточно резерва на несколько часов: он защищает от двойной продажи, но требует, чтобы персонал вовремя снимал просроченные удержания. Для доставки и предзаказов логичнее двухступенчатая схема — сначала бронь с понятным сроком хранения, затем перевод в резерв после подтверждения наличия и оплаты. Так портал не блокирует остатки под заказы, которые клиент не выкупит.
Ограничения есть у обоих режимов. Резерв без автоматического снятия по таймауту замораживает полку и снижает оборот. Бронь без проверки остатка в реальном времени приводит к отменам на этапе сборки, когда товара уже нет. Мы закладываем в схему данных раздельные статусы, таймеры и правила отмены брони с уведомлением клиента — иначе портал и аптека начинают жить в двух разных реальностях.
Частые технические сомнения
Перед стартом заказчики обычно задают одни и те же вопросы: выдержит ли портал пиковую нагрузку, как он состыкуется с учётной системой аптеки и что будет с данными, когда остатки меняются каждые несколько минут. Ниже — ответы по существу, без общих слов.
Выдержит ли портал сезонный наплыв — например, в период роста заболеваемости?
Каталог и карточки товаров отдаются из кэша, а поиск и проверка остатков идут к базе — тяжёлые запросы не блокируют выдачу страниц. Такой разнос ролей держит отклик стабильным, когда одновременных посетителей в разы больше обычного. Ёмкость подтверждаем нагрузочным тестом на профиле, близком к реальному.
Как портал получает актуальные остатки и цены из учётной системы аптеки?
Обмен идёт через интеграционный слой: он забирает изменения из товароучётной системы и раскладывает их по каталогу. Данные обновляются по расписанию и по событиям — позиция, которой нет в наличии, не показывается доступной к брони. Если внешняя система недоступна, портал работает на последнем снимке и не отдаёт покупателю заведомо неверный статус.
Что с поддержкой после запуска — правки придётся ждать неделями?
Поддержка идёт по регламенту с уровнями срочности: сбой бронирования или оплаты — вне очереди, плановые доработки — по согласованному порядку. Обновления выкатываем через автоматическую сборку и проверки, поэтому типовая правка не превращается в долгую операцию. Доступы, логи и схема развёртывания остаются у вас, мы не привязываем портал к себе.
Можно ли расширить портал позже — добавить доставку, программу лояльности, вторую сеть?
Архитектура разбита на независимые части: каталог, поиск, бронирование, личный кабинет. Новый модуль подключается к ним, не переписывая существующее, а вторая аптечная сеть добавляется как отдельный источник данных. Поэтому развитие портала — это доработка, а не новый проект с нуля.
Опишите вашу задачу — вернёмся с оценкой и планом по нагрузке, интеграциям и поддержке.
Обсудим задачу вашего портала
Чтобы оценка была точной, а не «плюс-минус», перед началом разработки портала для аптеки нам важно понять ваш сценарий целиком: как устроены остатки по точкам, кто отвечает за контент карточек, есть ли интеграция с учётной системой и как вы видите бронирование — с оплатой или без. Чем конкретнее вводные, тем меньше допущений в плане и тем предсказуемее сроки.
Что стоит подготовить к разговору:
- перечень аптечных точек с адресами и режимом работы — под геопоиск и зоны доставки;
- выгрузку номенклатуры: наименования, формы выпуска, дозировки, аналоги, признаки рецептурных позиций;
- данные об остатках и правилах их обновления — как часто и из какой системы они попадают на портал;
- описание сценария бронирования: срок хранения заявки, подтверждение фармацевтом, отмена и уведомления;
- требования к ролям и доступам — администратор каталога, оператор точки, поддержка;
- примеры порталов, которые вам нравятся по логике поиска и карточки товара.
После разбора задачи мы вернёмся с оценкой и планом: разложим работы по этапам, зафиксируем, что делаем на вашей стороне и что берём на себя, обозначим риски по интеграциям и предложим порядок запуска — сначала каталог и геопоиск, затем бронирование. Опишите задачу в удобном формате, и мы вернёмся с конкретикой по срокам и составу работ.
