Реалізація самовивозу з точок на сайті
Клієнт оформлює замовлення з самовивозом, приїжджає в магазин, а товару немає на полиці. Причина — дані про наявність застаріли на кілька годин. За даними Retail CRM, розбіжності залишків сягають 20%. Така ситуація вбиває довіру і генерує повернення. Ми стикалися з цим десятки разів і виробили надійне рішення на основі резервування в реальному часі. Економія для клієнтів — до 2 млн грн на рік за рахунок зниження скасувань.
Які проблеми вирішує грамотна реалізація самовивозу?
Основна технічна складність — консистентність даних між сайтом і фізичними точками. Покупець бачить залишок на сайті, а в момент приїзду товар уже проданий іншому. Затримка оновлення може становити від 30 хвилин до 2 годин. Друга проблема — UX: вибір точки без карти, відсутність інформації про години роботи, неможливість перевірити наявність конкретного SKU. Третя — резервування: без механізму тимчасового утримання товару ви ризикуєте віддати його іншому клієнту через паралельний продаж, що збільшує скасування на 30–50%. Економія на поверненнях при впровадженні нашого підходу сягає 15% обороту, що для мережі з 10 точок окупається за 3 місяці.
Як влаштована структура даних для точок самовивозу?
Для управління точками та залишками використовуємо реляційну модель з двома основними таблицями. Така структура забезпечує швидкі запити з індексами по product_id і store_id та легко масштабується на сотні точок. Ось схема на PostgreSQL:
pickup_stores ( id, name, address, city_id, lat, lng, phone, working_hours (jsonb), is_active ) store_inventory ( store_id, product_id, variant_id, quantity ) Поле working_hours зберігає розклад у форматі JSONB — зручно для різних графіків роботи в будні та вихідні. Координати (lat, lng) потрібні для відображення на карті та розрахунку відстані до користувача.
Чому резервування з авто-звільненням критичне?
Без резервування ви не можете гарантувати, що товар дочекається клієнта. Рішення — окрема таблиця з expires_at:
reservations ( id, store_id, product_id, variant_id, quantity, expires_at, status ) Термін зберігання (наприклад, 24 години) налаштовується. Після закінчення фоновий процес (cron або черга) змінює статус на cancelled і повертає кількість у store_inventory. Це виключає ручне скасування та втрати товару. Резервування через чергу в 3 рази надійніше ручного зняття.
Порівняйте три підходи до резервування:
| Підхід | Консистентність | Складність | Автоматизація скасувань | Навантаження на систему |
|---|---|---|---|---|
| Без резерву | Низька (розбіжності години) | Низька | Ні | Мінімальне |
| Ручне зняття | Середня (залежить від оператора) | Середня | Ні | Низьке |
| Авто-звільнення (наш) | Висока (секунди) | Середня | Так (черга) | Помірне |
Наш підхід з чергою, наприклад через Redis та Laravel queues, обробляє скасування за 200 мс і знижує навантаження на базу даних.
Кейс: мережа з 15 магазинів, інтеграція з 1С
В одному з проєктів впроваджували самовивіз для мережі продуктових магазинів. Вихідна архітектура: сайт на Next.js 14, бекенд на Laravel 11, облікова система на 1С. Основна проблема — залишки оновлювалися раз на годину, що призводило до розбіжностей до 20%.
Ми реалізували дворівневу синхронізацію:
- Реальний залишок (1С) → оновлення кожні 15 хвилин через REST API
- Резерв (сайт) → live-оновлення при оформленні замовлення
Для зниження навантаження на 1С використали Redis як кеш. При замовленні перевіряємо залишок через Redis, при успіху — резервуємо та відправляємо подію в чергу на списання в 1С. Якщо 1С недоступна, замовлення не підтверджується.
Результат: кількість скасувань з причини «немає в наявності» впала на 40%, а швидкість оформлення замовлення не перевищувала 1.2 секунди. Понад 50 подібних проєктів у нашому портфоліо.
Що входить у реалізацію під ключ?
Ми надаємо повний цикл робіт:
- Адмін-панель управління точками (CRUD, карта, години роботи)
- Віджет вибору точки на карті з кластеризацією при великій кількості
- Перевірка наявності по кожному товару в реальному часі
- Резервування з авто-звільненням через чергу
- Сповіщення про готовність (email, SMS, Telegram)
- Інтеграція з обліковою системою (1С, SAP, будь-який REST API)
- Документація по API та налаштування моніторингу
Процес впровадження
| Етап | Тривалість | Результат |
|---|---|---|
| Аналітика | 1-2 дні | Технічне завдання, схема інтеграції |
| Проєктування | 2-3 дні | Архітектура БД, API, черга |
| Реалізація | 3-5 днів | Працюючий функціонал на тестовому стенді |
| Тестування | 1-2 дні | Юніт-тести, навантаження до 1000 замовлень/год |
| Деплой | 1 день | Продакшн, моніторинг, документація |
Типові помилки при впровадженні
- Резервування без терміну життя — товар «зависає» назавжди.
- Використання локального часу для годин роботи — проблеми з часовими поясами.
- Відсутність черги для звільнення резервів — ризик втрати даних при збої.
- Прямі запити до 1С на кожен чек — висока затримка (до 5 секунд) та навантаження.
Зв'яжіться з нами для попередньої оцінки — це займе 30 хвилин. Отримайте консультацію інженера та точні терміни під вашу задачу.