Щоб покупець вибрав товар на сайті, уточнив деталі в переписці й забрав його в магазині, продавці мають працювати з одним замовленням. Для цього потрібні спільні коди товарів, перевірений залишок, записаний резерв і відповідальний працівник. Почніть з цього сценарію та перевірте його протягом тижня.
Так працює омніканальність: магазин поєднує різні способи покупки в послідовний процес. Покупцеві не доводиться повторювати домовленості кожному продавцю, а працівники бачать, що вже зробили колеги та що потрібно зробити далі.
Одне замовлення від сайту до видачі
Умовний приклад: покупчиня знаходить на сайті синю сорочку розміру М. Пише магазину, щоб уточнити довжину рукава, і просить відкласти сорочку до вечора. Продавець знаходить саме цей розмір і колір, перевіряє наявність, записує резерв та повідомляє, коли й де можна забрати покупку.
Увечері працює інший продавець. За номером замовлення він бачить сорочку, погоджену ціну, термін резерву та стан оплати. Знаходить підготовлений пакунок, перевіряє оплату й фіксує видачу. Переписка допомогла уточнити покупку, а всі подальші дії працівники пов’язали з одним замовленням.
Повідомлення «відкладіть, будь ласка» саме собою ще не створює резерв в обліку. Працівник має оформити його або перевірити, що налаштований обмін із сайтом уже зробив це. Облікова база також не збирає автоматично всі розмови з покупцями: важливі домовленості продавець переносить у запис замовлення.

Узгодьте товари та дані замовлення
Власник разом із продавцем перевіряє, чи можна однозначно знайти кожен товар. Синя сорочка розміру М і така сама сорочка розміру L мають різні коди. Код кожного варіанта повинен відповідати тому самому товару на сайті й у магазині. Розробник перевіряє це зіставлення під час налаштування обміну.
Назви «сорочка синя» недостатньо: продавець може відкласти інший розмір. Виберіть кілька товарів із різними кольорами й розмірами та звірте їхні коди, характеристики й одиниці виміру. Особливо перевірте позиції, які продаєте і поштучно, і упаковками.
Для кожного замовлення ведіть один запис, доступний працівникам, які його обробляють. У ньому потрібні:
- Номер замовлення, дата та джерело звернення — сайт або переписка.
- Ім’я покупця та контакт для погодженого зв’язку щодо замовлення.
- Код товару, назва, розмір, колір, кількість та одиниця виміру.
- Погоджена ціна, сума замовлення та стан оплати.
- Місце самовивозу, термін резерву та домовлений час отримання.
- Поточний стан замовлення, відповідальний продавець і наступна дія.
Якщо покупець після оформлення на сайті пише в повідомленнях, продавець доповнює наявний запис. Перед створенням нового замовлення перевіряє, чи вже є замовлення з цим номером. Зміну розміру, ціни або часу отримання теж записує там, щоб колега бачив останню домовленість.
Перевірте залишок і підтвердьте резерв
Перед обіцянкою відкласти товар продавець перевіряє фізичну наявність та чинні резерви. Для самовивозу важливо знайти конкретну річ у потрібному магазині, звірити розмір і колір, оглянути її та покласти у визначене місце для замовлень.
Умовний розрахунок: у магазині фізично є 5 синіх сорочок розміру М, із них 2 вже зарезервовані. Якщо фізична кількість ще включає ці резерви, доступно для нових замовлень 5 − 2 = 3 штуки. Усі числа тут стосуються одного товару, одного місця зберігання та однієї одиниці виміру.
Якщо система вже показує вільний залишок — 3 штуки, — повторно віднімати 2 зарезервовані сорочки не потрібно. Власник має з’ясувати, що означає показник у конкретній системі, та пояснити це продавцям. Інакше працівники рахуватимуть доступну кількість по-різному.
Власник визначає термін резерву, а продавець погоджує його з покупцем. Наприклад: «Сорочку підготували. Можете забрати сьогодні до 19:00 за адресою… Номер замовлення… Якщо не встигаєте, напишіть нам до цього часу». Це умовна домовленість магазину з покупцем.
Повідомлення про готовність продавець надсилає після перевірки товару та оформлення резерву. Коли погоджений термін минає, відповідальний працівник перевіряє домовленості, знімає резерв за прийнятим у магазині порядком і записує причину. Так наступна зміна розуміє, чому товар знову доступний.
Передавайте замовлення між змінами та зберігайте історію
Власник призначає відповідального за замовлення на кожній зміні. Перед завершенням роботи продавець передає колезі незавершені замовлення: що підготовлено, де лежить товар, чи підтверджено оплату та коли потрібно зв’язатися з покупцем. Колега перевіряє записи й приймає ці замовлення в роботу.
Під час самовивозу продавець знаходить замовлення за номером і звіряє товар. Якщо оплату вже внесли в облік, не записує її повторно. Якщо покупець платить під час отримання, фіксує нову оплату. Видачу товару також записує один раз у межах цього замовлення, щоб не створити другий продаж.
Якщо покупець скасовує замовлення, продавець записує причину та звільняє резерв. Якщо повертає вже отриманий товар, працівник пов’язує повернення з первинним продажем і окремо фіксує рух товару та грошей. Історію замовлення зберігає. Перед поверненням речі в доступний залишок перевіряє її стан.
Облік і синхронізація інтернет-магазину в Торгсофт
Торгсофт може підтримати товарну частину цього процесу: вести облік і передавати на сайт дані про товари, ціни та залишки, а замовлення із сайту — приймати для обробки як рахунки. Для цього потрібна окрема платна опція «Синхронізація з інтернет-магазином» та ліцензія Ультра або Термінал. Розробник сайту має підготувати обробник, який прийматиме й формуватиме файли обміну. На тестовому замовленні перевірте, чи код із сайту визначає потрібний товар у програмі.
Для файлового обміну налаштовують розклад. За інструкцією Торгсофт, автоматичний файловий обмін запускають не частіше ніж раз на 10 хвилин. Автоматичний обмін працює, коли програму запущено на визначеному комп’ютері під зазначеним користувачем. Передавання й обробка файлів потребують часу, тому наявність на сайті може відставати від змін у магазині. Для останньої одиниці продавець перевіряє залишок перед підтвердженням покупцеві.
У довідці з налаштування синхронізації описано параметр «Резервувати товари рахунка» на вкладці «Центри обліку». За ввімкненого параметра програма використовує дату резерву із замовлення, а якщо її немає — кількість днів із налаштування. Узгодьте ці значення з умовами, які повідомляєте покупцеві. Перевірте резерв після обробки тестового замовлення: саме повідомлення в месенджері його не створює. Інші канали потребують окремої перевірки можливостей і налаштувань.
Перевірте один сценарій за тиждень
На початку тижня власник обирає сценарій «сайт → переписка → резерв → самовивіз», визначає відповідальних і погоджує правила резерву. Продавець звіряє тестові товари, готує записи замовлень і місце для пакунків. Розробник перевіряє коди, обмін даними та поведінку сайту після зміни залишку.
Потім команда проходить тестове замовлення від початку до кінця, включно з передачею іншій зміні. Окремо перевіряє останню одиницю: що побачить покупець на сайті, якщо її зарезервували або продали в магазині до наступного обміну. Ще два тести — скасування резерву та повернення після видачі. Перевірте залишок, записи оплати, видачі й повернення та збереження історії.
Наприкінці тижня власник розбирає знайдені помилки й визначає, хто їх виправить. Для подальшої оцінки можна рахувати частку відмов через відсутність товару. Умовно: 8 відмов зі 100 замовлень — 8%; у наступному порівнянному періоді 3 зі 100 — 3%. Різниця становить 5 відсоткових пунктів. Це показує зміну результату, але не доводить впливу окремого налаштування: перевірте також зміни асортименту, попиту та роботи продавців.








Повернутися до попереднього кроку