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