Отменени поръчки заради липса на наличност? eMAG, Trendyol, онлайн магазин

Продавате една и съща стока на няколко места едновременно – в eMAG, в Trendyol и в собствения си онлайн магазин – но складът Ви е един. Когато наличностите се разминат между каналите, започват свръхпродажбите, отменените поръчки и спадът в рейтинга на акаунта. Синхронизацията на наличностите при многоканална продажба не е прищявка, а условие за поддържане на здравето на акаунта. Показваме как работят моделите за синхронизация, как да изберете честотата и как да избягвате конфликти, преди да прераснат в истински проблем.

Съдържание

1. Защо разминаването на наличностите боли?
2. Модели за синхронизация на наличностите
3. Честота на синхронизацията и конфликти
4. Добри практики за многоканална синхронизация
5. Често задавани въпроси

Защо разминаването на наличностите боли?

Представете си последната бройка от даден продукт на рафта. Виждат я клиент в eMAG, клиент в Trendyol и клиент във Вашия магазин – и всеки от тях може да я купи в една и съща минута. Ако каналите не знаят един за друг, ще продадете една стока три пъти. Точно това е свръхпродажбата (oversell) и тя е най-скъпата последица от липсата на синхронизация.

Последиците не свършват с един недоволен клиент. Разминаването на наличностите задейства цяла каскада:

• Отменени поръчки – щом нямате с какво да изпълните продажбата, трябва да откажете поръчката. В маркетплейса отказ по вина на търговеца е един от най-лошите сигнали, които можете да изпратите на платформата.
• Спад в рейтинга и здравето на акаунта – платформите отчитат процента на отменените и закъснелите поръчки. Високото ниво на отмени понижава рейтинга, избутва офертата надолу в резултатите, а в краен случай води до ограничения на акаунта. Как да следите тези показатели в eMAG, описваме в материала за рейтинга и здравето на eMAG акаунта.
• Загуба на бутона „Купи“ и на видимост – оферта с история на отмени губи от конкуренцията дори при същата цена.
• Разходи за обслужване – всяка отмяна е време за обяснения пред клиента, възстановяване на плащането и риск от негативен отзив, който остава в акаунта задълго.

Обратният проблем е по-тих, но също реален. Когато от предпазливост занижавате наличностите във всеки канал, за да не продадете повече, отколкото имате, губите продажби – стоката стои в склада, а офертата показва „няма наличност“. Добрата синхронизация е намирането на баланс между тези два сценария: да продадете всичко, което имате, но никога повече.

Модели за синхронизация на наличностите

Синхронизацията на наличностите винаги стъпва на един и същ принцип: трябва да има един източник на истината за наличността, от който всички канали вземат числата. Разликата между моделите е в това къде се намира този източник и как разпределя наличната стока между каналите.

Централен склад (single source of truth)

Най-чистият модел: една система – най-често OMS или интегратор – поддържа актуалната наличност на всеки SKU и я разпраща до всички канали. Магазинът и маркетплейсите нямат свои независими числа; те са само „дисплеи“ на това, което показва централният склад. Ако още нямате внедрена такава система, добре е да започнете с разбиране на това какво е OMS система за управление на поръчки и каква роля играе в многоканалната продажба.

Предимството е простата логика: наличността е една, така че няма за какво да се спори. Предизвикателството е скоростта – наличността трябва да стига до каналите достатъчно бързо, за да не се застъпят две паралелни продажби.

Предпазни буфери

Буферът (stock buffer) е умишлен резерв, който не пускате за продажба. Ако имате 10 бройки, а буферът е 2, каналите виждат 8. Двете бройки са възглавница за закъсненията в синхронизацията и за продажбите, които се застъпят в прозореца между актуализациите.

• Процентен или количествен буфер – фиксиран брой бройки или процент от наличността. Процентът се мащабира по-добре при продукти с висока обращаемост.
• Буфер за всеки канал – на канал с по-бавна синхронизация или с повече паралелни поръчки можете да дадете по-голяма възглавница.
• Цената на буфера – колкото по-голям е буферът, толкова по-малък е рискът от свръхпродажба, но толкова повече „замразена“ стока не продавате. Това е съзнателен компромис, а не настройка „завинаги“.

Приоритети на каналите и отделни пулове

Когато стоката е малко, а каналите – няколко, трябва да решите кой има предимство. Тук влизат две стратегии: приоритет на канала (при ниска наличност стоката „отива“ първо в най-важния канал) и отделни пулове (разделяте наличността твърдо, напр. част за магазина, част за eMAG, част за продажбите в Trendyol на румънския пазар). Таблицата по-долу сравнява трите подхода.

Модел	Как работи	Кога е подходящ
Общ пул + буфер	Всички канали виждат една и съща наличност минус буфера	Изборът по подразбиране – максимизира продажбата на цялата наличност
Приоритет на канала	При ниска наличност важи редът на каналите	Когато един канал е явно по-важен по марж
Отделни пулове	Наличността е разделена твърдо между каналите	Лимитирани продукти, договори, гарантирана наличност

На практика най-често се използва моделът на общ пул с буфер, а отделните пулове се пазят за продукти, които просто не бива да свършват в конкретен канал.

Честота на синхронизацията и конфликти

Ключовият въпрос е: колко бързо след продажба в един канал останалите канали научават за новата наличност? Колкото по-дълъг е този прозорец, толкова по-голям е рискът междувременно някой да купи стока, която вече я няма.

Има два основни механизма за актуализация:

• На интервали (polling) – системата периодично запитва каналите и изпраща новите наличности. Прост и предвидим, но между два цикъла има „сляп прозорец“.
• По събития (webhook / near real-time) – каналът сам съобщава за продажбата в момента на извършването ѝ, а системата веднага коригира наличността навсякъде другаде. Свива слепия прозорец почти до нула, но изисква стабилна интеграция и обработка на грешки.

Реалната честота зависи от лимитите на API на всяка платформа – не може да се запитва произволно често. Конкретните интервали и лимити се различават между eMAG, Trendyol и платформата на магазина и понякога се променят.

Отделна тема са конфликтите при запис, тоест ситуацията, в която две събития се опитват да променят една и съща наличност в един и същ момент. Най-честите случаи и начинът за обезвреждането им:

• Надпревара между две продажби – две поръчки за една и съща стока в прозореца на синхронизация. Решение: предпазен буфер и подреждане на актуализациите на опашка вместо презаписване по принципа „последният печели“.
• Ръчна корекция срещу автоматика – складовият служител коригира наличността в същия момент, в който синхронизацията я презаписва. Решение: един източник на истината и ясно правило, че ръчните промени минават само през централния склад.
• Връщане и повторно заприходяване – стоката се връща и трябва да се върне в пула. Решение: автоматично отчитане на връщането в същата система, която намалява наличностите при продажба.
• Грешка в интеграцията – каналът не е потвърдил актуализацията. Решение: повторни опити (retry) и известие, когато наличността не се потвърди след няколко опита.

Добри практики за многоканална синхронизация

Синхронизацията на наличностите не е еднократна настройка, а процес, който трябва да се проектира и следи. По-долу е списък с правила, които на практика най-често отличават акаунтите без свръхпродажби от онези, които гасят пожари всяка седмица.

• Един източник на истината за наличностите – изберете една система (OMS или интегратор), която поддържа наличността, и не позволявайте на никой канал да има свое независимо число.
• Единни SKU и съпоставяне на офертите – един и същ продукт трябва да е еднозначно свързан между магазина, eMAG и Trendyol. Без чисто съпоставяне на SKU синхронизацията актуализира не тези оферти, които трябва.
• Буфер според обращаемостта – по-голям за бестселърите с много паралелни поръчки, по-малък за бавно движещите се позиции.
• Актуализация по събития, където е възможно – колкото по-близо до реално време, толкова по-малък е слепият прозорец за свръхпродажба.
• Мониторинг и известия – уведомление, когато наличността падне под праг, когато синхронизацията спре да потвърждава промените или когато се появи отмяна заради липса на стока.
• Опашка вместо презаписване – актуализациите се обработват една след друга, така че две паралелни промени да не се „изядат“ взаимно.
• Логика на връщанията в същата система – върнатата стока се връща в пула автоматично, без ръчно заприходяване.

Техническият слой на този пъзел най-често се реализира чрез интегратор или специално написан скрипт. Как изглежда такава интеграция на практика на примера на популярен инструмент, показваме в материала за интеграцията на BaseLinker с eMAG. Независимо от избрания инструмент принципът остава същият: наличността се брои на едно място, а каналите само я отразяват.

Често задавани въпроси

Направете следващата стъпка

Ако свръхпродажбите и отмените се връщат при Вас редовно, това е знак, че наличностите трябва да стъпят на един автоматизиран източник на истината. Вижте как подхождаме към автоматизацията и внедряването на OMS, или пишете ни – ще анализираме Вашия пъзел от канали и ще предложим модел за синхронизация, съобразен с обращаемостта и лимитите на Вашите платформи.