Розробка порталу для аптеки: де ламається логіка замовлення
Розробка порталу для аптеки майже завжди впирається не у вітрину, а в три місця, де логіка замовлення розходиться з реальністю. Перше — залишки.
Каталог ліків показує наявність із кешу, який оновлюється раз на кілька хвилин або раз на добу, а на касі товар уже продано або списано за терміном. Клієнт бронює позицію, приходить, і її немає — довіра до порталу втрачається з першого такого випадку.
Друге — геопошук аптек. Якщо він будується за прямою дистанцією до точки, а не за реальним маршрутом, портал веде людину до найближчої за картою аптеки, до якої насправді їхати довше, ніж до сусідньої.
Окрема біда — прив'язка до неточних координат: адреса визначається за центром району, і видача з'їжджає на кілометр, хоча поруч є точка з потрібним препаратом.
Третє — бронювання товару без підтвердження. Заявка йде в нікуди: аптека не бачить її у своїй черзі, клієнт вважає, що товар за ним, а термін броні не обмежений. Усе це не косметика вітрини, а розрив між інтерфейсом і обліковою системою аптеки.
Розбираємо, як це закривається: синхронізація залишків з обліковою системою в реальному часі, геопошук за маршрутом і підтверджена бронь із зрозумілим терміном життя.
Що дає портал з каталогом і бронюванням
Пошук потрібного препарату за секунди, а не за дзвінок
Каталог із залишками будується на регулярній синхронізації з обліковою системою аптечної мережі: позиції, фасування, аналоги та наявність по кожній точці оновлюються із заданим інтервалом.
Відвідувач вводить діючу речовину або торгову назву й одразу бачить, де препарат є зараз, — без уточнювальних дзвінків і поїздок «навмання».
Пошук по аптеках з урахуванням району, годин роботи та близькості до маршруту скорочує шлях від запиту до конкретної точки до однієї-двох хвилин.
Бронювання без дзвінка та передбачувана частка підтверджень
Бронювання оформлюється в інтерфейсі: клієнт обирає аптеку, фіксує позицію та отримує підтвердження, а співробітник бачить замовлення у своїй черзі.
Термін зберігання бронювання налаштовується під логістику мережі, тому товар не «зависає» на полиці, а частка підтверджених бронювань зростає завдяки автоматичній перевірці залишку в момент оформлення.
Якщо позиції немає, система пропонує найближчу точку або аналог — клієнт не йде з порожнім результатом.
Навантаження на операторів падає на рутинних зверненнях
Типові питання — «чи є в наявності», «до котрої години працює», «чи можна відкласти» — закриваються порталом без участі людини. Оператори переключаються на складні випадки: рецептурні позиції, доставку, претензії.
За того самого штату мережа обробляє більше звернень у пікові години, а час відповіді на лінії не зростає.
Керованість замість ручних звірок
Адміністратор бачить статистику по точках: що шукають, що бронюють, де відмовляють частіше. Ці дані лягають у закупівлі та розподіл залишків між аптеками — асортимент підлаштовується під реальний попит, а не під торішні звіти.
Способи зв'язати каталог із залишками аптек
Зв'язка каталогу з реальними залишками — найкрихкіша частина порталу: якщо дані про наявність відстають, покупець бронює те, чого на полиці немає, і дзвінок в аптеку перетворюється на відмову.
Вибір способу синхронізації визначає, як часто оновлюються залишки, що відбувається при недоступності облікової системи та скільки ручної роботи лягає на співробітників аптеки.
Ми працювали з усіма трьома схемами і бачимо їх так.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряма інтеграція з обліковою системою | Одна-дві аптеки, один постачальник облікового ПЗ, стабільний канал зв'язку | Будь-який збій облікової системи обвалює залишки на порталі; оновлення прив'язане до її регламенту; при зростанні мережі кількість точок інтеграції зростає лавиноподібно |
| Проміжний шар | Мережа аптек, різні облікові системи, потрібна частота оновлення вища, ніж дає обліковий контур | Потребує окремого сервісу та його супроводу; розбіжності між шаром і обліковою системою потрібно розбирати регламентом |
| Ручне оновлення | Невеликий асортимент, рідкісні зміни, немає доступу до облікової системи | Залишки застарівають протягом дня; помилки введення; бронювання на відсутній товар |
Чому проміжний шар зазвичай виграє
Він забирає дані з облікової системи за розкладом, нормалізує їх до єдиного вигляду і віддає каталогу.
Частота оновлення задається окремо від регламенту облікового контуру — залишки можна підтягувати помітно частіше, а при недоступності системи портал продовжує працювати на останньому зрізі, позначаючи дані як «уточнюються».
Що вирішуємо на етапі проєктування
Визначаємо, які події вважаються зміною залишку, як розв'язуються конфлікти між шаром і обліковою системою та що бачить покупець, якщо дані застаріли. Окремо фіксуємо правила бронювання: скільки тримається резерв і коли він автоматично знімається.
Як ми будуємо портал: етапи робіт
Робота йде ітераціями по 1-2 тижні: кожна завершується демонстрацією на тестовому контурі, а не звітом у документі. Так замовник бачить працюючий геопошук і бронювання задовго до фінальної здачі та може скоригувати пріоритети, поки зміни дешеві.
- Аудит даних і поточних систем. Збираємо, звідки надходять товари та залишки: вивантаження з облікової системи, прайси постачальників, ручні таблиці. Фіксуємо частоту оновлення, дублі позицій, розбіжності в одиницях вимірювання та правила зіставлення аптек з адресами — це фундамент, на якому далі тримається весь каталог.
- Проєктування схеми інтеграції. Визначаємо, що тягнемо в реальному часі, а що пакетно за розкладом, як обробляємо недоступність джерела і що показуємо користувачеві, якщо залишки не надійшли. Окремо описуємо поведінку при скасуванні бронювання та поверненні позиції в продаж.
- Складання каталогу та геопошуку. Реалізуємо пошук за назвою, діючою речовиною та формою випуску, ранжування за відстанню та наявністю. Перевіряємо на реальних адресах: як поводиться видача на межі районів, при неточних координатах і в годину пік за навантаженням.
- Налаштування бронювання. Прописуємо термін життя бронювання, ліміти на позицію та на користувача, повторні бронювання, повідомлення про готовність замовлення. Узгоджуємо сценарії з фармацевтами: що робити при частковій наявності та як знімати бронювання, якщо клієнт не прийшов.
- Перевірка сценаріїв. Проганяємо наскрізні шляхи: пошук, вибір аптеки, бронювання, підтвердження, видача. Окремо — відмови: порожній залишок, закрита точка, втрата зв'язку з обліковою системою, одночасне бронювання останньої упаковки двома клієнтами.
- Передача порталу. Розгортаємо на бойовому контурі, налаштовуємо резервне копіювання та моніторинг доступності, передаємо доступи й документацію. Навчаємо співробітників аптек роботі з чергою бронювань.
Паралельно з розробкою ведемо журнал рішень: чому вибрано такий інтервал синхронізації, як рахується відстань, що відбувається при конфлікті залишків. На передачі він перетворюється на інструкцію для вашої команди — портал можна розвивати без нас.
Що замовник отримує на руки
Портал для аптеки живе не у вакуумі: у нього є власник з боку бізнесу, черговий інженер і підрядник, який долучається до доопрацювань.
Щоб передача не перетворювалася на археологію за чужими файлами, ми віддаємо проєкт як комплект артефактів — з описом того, як система влаштована і як її супроводжувати.
- Схема даних — зв'язки між товарами, аптечними пунктами, залишками, бронюваннями та користувачами, з описом ключів і обмежень цілісності.
- Конфігурації середовищ — параметри підключення до каталогу, геопошуку та зовнішніх довідників ліків, окремо для тестового і робочого контурів.
- Регламент оновлення — порядок викладки нової версії, перевірки міграцій і відкату на попередній реліз, якщо перевірки не пройшли.
- Документація порталу — точки інтеграції, формати обміну, поведінка при недоступності зовнішнього сервісу та логіка перерахунку залишків.
- Політики доступу — ролі співробітників аптеки та адміністраторів, межі видимості даних і правила роботи з персональними даними клієнтів.
- Опис бронювання — життєвий цикл заявки від створення до видачі або скасування, включно з терміном придатності резерву та повторним вивільненням товару.
- Інструкція для чергової зміни — що перевіряти при скарзі на пошук або бронь і за якими ознаками відрізняти збій каталогу від проблеми на стороні аптеки.
Такий комплект знімає залежність від конкретних людей: новий інженер входить у проєкт за документацією, а не за листуванням. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом матеріалів, що передаються.
Кейс: портал для мережі аптек із геопошуком
Мережа з кількох десятків аптек прийшла з класичною проблемою: залишки в каталозі розходилися з реальною наявністю на полиці. Клієнт обирав товар, їхав до конкретної точки — і не знаходив його.
Частка таких звернень сягала третини від усіх бронювань, а фармацевти витрачали зміну на дзвінки та ручне підтвердження замість роботи з покупцем.
Ми перебудували обмін даними між касовим контуром і порталом. Залишки по кожній точці почали оновлюватися за подіями продажу та надходження, а не за розкладом раз на кілька годин, тому позиція зникає з доступних для броні майже одразу після продажу.
Геопошук ранжує точки не за прямою лінією, а за реальним маршрутом і годинами роботи: якщо ближня аптека зачинена або товару там немає, покупець одразу бачить наступну відповідну.
Аптечна мережа отримала портал, де бронь підтверджується автоматично, а спірні позиції надходять фармацевту окремою чергою з пріоритетом.
Середній час підтвердження скоротився з кількох годин до хвилин, частка скасувань із причини «товару не виявилося» впала майже до нуля, а навантаження на зміну завдяки знятим дзвінкам знизилося приблизно на чверть.
Окремо закрили сценарій часткового замовлення: якщо з трьох позицій підтвердилися дві, покупець бачить це до візиту й вирішує, чи забирати залишок. Такий крок прибрав основну причину негативу на касі та розвантажив підтримку.
Чим відрізняється бронювання від резерву в аптечному порталі?
Бронювання та резерв — різні сутності, і плутати їх в аптечному порталі дорого. Бронювання фіксує намір клієнта: замовлення прив'язане до конкретної людини, у нього є термін зберігання бронювання, після закінчення якого позиція повертається до вільного залишку.
Резерв — це фізичне утримання упаковки на полиці під уже підтверджене замовлення, і він зменшує доступний залишок для всіх інших покупців одразу. Поки товар лежить у резерві, його не продасть офлайн-касир і не забронює інший відвідувач порталу.
Різниця проявляється в момент скасування бронювання. Якщо клієнт відмовився до підтвердження, система просто знімає утримання — залишок повертається до каталогу, жодних дій персоналу не потрібно.
Якщо ж скасовується підтверджений резерв, потрібен сценарій повернення: комірник знімає фізичну позначку, товар знову стає доступним, а історія операції залишається в журналі для звірки. Без цього розбіжності між даними порталу та фактичною наявністю накопичуються за лічені дні.
Вибір режиму залежить від моделі роботи аптеки. Для самовивозу з коротким вікном достатньо резерву на кілька годин: він захищає від подвійного продажу, але вимагає, щоб персонал вчасно знімав прострочені утримання.
Для доставки та передзамовлень логічнішою є двоступенева схема — спочатку бронювання з зрозумілим терміном зберігання, потім переведення в резерв після підтвердження наявності та оплати. Так портал не блокує залишки під замовлення, які клієнт не викупить.
Обмеження є в обох режимів. Резерв без автоматичного зняття за таймаутом заморожує полицю та знижує оборот. Бронювання без перевірки залишку в реальному часі призводить до скасувань на етапі збирання, коли товару вже немає.
Ми закладаємо в схему даних роздільні статуси, таймери та правила скасування бронювання з повідомленням клієнта — інакше портал і аптека починають жити у двох різних реальностях.
Часті технічні сумніви
Перед стартом замовники зазвичай ставлять одні й ті самі питання: чи витримає портал пікове навантаження, як він зістикується з обліковою системою аптеки і що буде з даними, коли залишки змінюються кожні кілька хвилин. Нижче — відповіді по суті, без загальних слів.
Чи витримає портал сезонний наплив — наприклад, у період зростання захворюваності?
Каталог і картки товарів віддаються з кешу, а пошук і перевірка залишків ідуть до бази — важкі запити не блокують видачу сторінок. Такий розподіл ролей тримає відгук стабільним, коли одночасних відвідувачів у рази більше за звичайне. Ємність підтверджуємо навантажувальним тестом на профілі, близькому до реального.
Як портал отримує актуальні залишки та ціни з облікової системи аптеки?
Обмін іде через інтеграційний шар: він забирає зміни з товарооблікової системи і розкладає їх по каталогу. Дані оновлюються за розкладом і за подіями — позиція, якої немає в наявності, не показується доступною для бронювання.
Якщо зовнішня система недоступна, портал працює на останньому знімку і не віддає покупцеві вочевидь неправильний статус.
Що з підтримкою після запуску — правки доведеться чекати тижнями?
Підтримка йде за регламентом з рівнями терміновості: збій бронювання або оплати — поза чергою, планові доопрацювання — за узгодженим порядком. Оновлення викочуємо через автоматичне складання і перевірки, тому типова правка не перетворюється на довгу операцію. Доступи, логи і схема розгортання залишаються у вас, ми не прив'язуємо портал до себе.
Чи можна розширити портал пізніше — додати доставку, програму лояльності, другу мережу?
Архітектура розбита на незалежні частини: каталог, пошук, бронювання, особистий кабінет. Новий модуль підключається до них, не переписуючи наявне, а друга аптечна мережа додається як окреме джерело даних. Тому розвиток порталу — це доопрацювання, а не новий проєкт з нуля.
Опишіть ваше завдання — повернемося з оцінкою та планом щодо навантаження, інтеграцій і підтримки.
Обговоримо задачу вашого порталу
Щоб оцінка була точною, а не «плюс-мінус», перед початком розробки порталу для аптеки нам важливо зрозуміти ваш сценарій загалом: як влаштовані залишки за точками, хто відповідає за контент карток, чи є інтеграція з обліковою системою і як ви бачите бронювання — з оплатою чи без. Чим конкретніші вхідні дані, тим менше припущень у плані і тим передбачуваніші строки.
Що варто підготувати до розмови:
- перелік аптечних точок з адресами та режимом роботи — під геопошук і зони доставки;
- вивантаження номенклатури: найменування, форми випуску, дозування, аналоги, ознаки рецептурних позицій;
- дані про залишки та правила їх оновлення — як часто і з якої системи вони потрапляють на портал;
- опис сценарію бронювання: строк зберігання заявки, підтвердження фармацевтом, скасування та повідомлення;
- вимоги до ролей і доступів — адміністратор каталогу, оператор точки, підтримка;
- приклади порталів, які вам подобаються за логікою пошуку та картки товару.
Після розбору задачі ми повернемося з оцінкою та планом: розкладемо роботи за етапами, зафіксуємо, що робимо на вашій стороні і що беремо на себе, позначимо ризики щодо інтеграцій і запропонуємо порядок запуску — спочатку каталог і геопошук, потім бронювання. Опишіть задачу в зручному форматі, і ми повернемося з конкретикою щодо строків і складу робіт.
