Колко струва един ден празен рафт.
marql намира SKU-тата, паднали на нула, които още са се продавали, и остойностява отсъствието по вашите продажби, а не по себестойността. Оттук нататък екранът спира, а плейбукът прави още две стъпки: през маржа и през заместването. Накрая слага трите реални възможности една до друга — да платите за по-ранна доставка, да поемете дупката или да я заобиколите със заместител.
В риск
381 €
седмично, от които 38 € се откупуват
- по продажби, не по себестойност
- работи с каса и наличности
- възстановимо ≠ в риск
Екраните са от демо пазара Mercado Claro и са заснети на 1 септември 2026 г. Интерфейсът тук е в тъмна тема, а marql AI отговаря на испански; плейбук 01 показва друг пазар в светла тема. Цифрите са генерирани, а тенантът движи собствен часовник, така че това са моментни снимки, не константи.
Рафтът е празен. Търсенето — не.
В Mercado Claro една позиция е на нула в Мадрид · Маласаня. Granola artesanal, втори ден поред. marql я остойностява по продажбите на самия обект и показва ≈381 € седмично в риск, докато рафтът се зареди. Дотук стига продуктът; оттук започва решението. Защото 381 € не са това, което веригата губи, и със сигурност не са толкова, колкото си струва да платите на куриер. Между цифрата на екрана и цифрата, върху която купувачът може да стъпи, стоят две умножения и всяко от тях я смалява.
- 381 €
- седмични продажби в риск
- 223 €
- марж вътре в тях
- 38 €
- толкова струват два дни
- 2
- дни поред
От рафт на нула до решение с цена.
Четири етапа. Третият обикновено се прескача, а той е важният: възможностите не струват еднакво и най-евтината често е да не направите нищо и да запишете защо.
SKU, което се е продавало, вече е на нула.
Всеки ден сканирането съпоставя наличностите с историята на продажбите и изважда SKU-тата, които са имали оборот през последните 30 дни, а днес са без наличност. Редовете се събират в един инцидент на обект, а не в по един на SKU. Подредени са в ленти според вида пари: повтарящо се седмично изтичане, продажби, които се изчерпват, блокиран капитал. Лентата под всеки ред показва колко. Изчерпването е в собствената си лента с 381 € — под три изтичания, които струват повече на седмица, и над свръхналичността, на която е посветен първият плейбук тук.
Ежедневно сканиране · един инцидент на обект · дължина на лентата = пари в игра
Денят отсъствие получава цифра — от продажбите, не от себестойността.
Ставката идва от скорошните продажби на самото SKU, а не от средно за категорията или от ценова листа. Точно затова това е единственият плейбук, който работи само с каса и наличности: дотук данни за себестойност изобщо не са нужни. Цифрата е седмична, защото такъв е периодът на инцидента. Превръщането ѝ в дневна е работа на читателя, а не число, което продуктът си съчинява.
По продажбите на самото SKU · без данни за себестойност
Различава позиция, която е спряла, от позиция, която е угаснала.
marql проверява има ли поръчано, има ли същото SKU другаде в мрежата и изпразвал ли се е този обект и преди. Повторение на един и същи адрес е проблем със снабдяването, облечен като проблем с рафта. Продуктът показва броя, вместо да разчита на паметта — а разликата е между това да оправите едно изчерпване и да плащате за същото всеки месец.
Поръчано · налично другаде · брой повторения
Върнатата наличност не е върнат приход.
След потвърждаване на действието marql фиксира базовия период и прозореца за измерване. Прозорецът трябва да надживее пика: първите дни след зареждането продават търсенето, натрупано докато рафтът е бил празен, и разкрасяват всяко решение, измерено срещу тях. Струва си да се каже точно къде живее това. На този тенант регистърът на въздействието е датиран отчет сред запазените изгледи, с данни към 10 август 2026 г., а не жива повърхност, която се обновява пред очите ви. Преглед, който трябва да отворите, пак е преглед. Преглед, който никой не отваря, не е.
Датиран отчет · база, замразена при потвърждаване · прозорец отвъд пика
Нулата може да бъде правилното число.
Аритметиката не се оспорва: SKU-то се е продавало и няма наличност. Оспорва се дали някой изобщо трябва да действа. В поне пет обичайни случая празният рафт е точно това, което е искано, и който плати за по-ранна доставка в някой от тях, плаща надценка, за да развали чуждо решение.
Позицията се изчерпва нарочно
SKU, извадено от асортимента, стига до нула точно по план. Планът обаче живее в главата на купувача или в таблица, която продуктът никога не е виждал. Сигналът вижда позиция, продавала се добре 28 дни и после спряла — а контролираното изчерпване изглежда от данните точно така.
Има ли нещо поръчано и продава ли се вече заместител в същата подкатегория? При планирано изчерпване няма нито отворена поръчка, нито дупка в оборота на подкатегорията: наследникът вече го поема.
Сезонът свърши, а прозорецът още не го знае
Ставката чете скорошните продажби. При сезонна позиция този прозорец стъпва върху края на сезона и продължава да цитира търсене, което вече го няма. Рафтът е празен, защото никой не купува, а не защото нищо не е дошло.
Същото SKU, същите седмици миналата година. Ако и тогава темпото е падало така, сезонът е свършил. Ако миналата година по това време още се е продавало, не е.
Заместителят вече е на рафта, но с друг код
Смяна на грамаж, смяна на доставчик или преформулиране дават на същия продукт ново SKU. Старият код пада на нула и си остава там — и това е правилно. Търсенето продължава необезпокоено един баркод по-нататък.
Оборотът на подкатегорията за същите дни. Ако подкатегорията е равна, докато SKU-то е на нула, търсенето не си е отишло. Преместило се е и няма какво да се възстановява.
Ограничена серия, която не е и щяла да се зарежда
Еднократна покупка, край на серия при доставчика, съвместна колекция с отпечатана крайна дата. Изчерпването е резултатът, заради който покупката е направена, а сигналът описва успех.
Възможно ли е било зареждане изобщо? Има ли запис за доставчик със срок, или първоначалната поръчка е била всичко? SKU без път за презаявка не се ускорява на никаква цена.
Рафтът е празен, складът — не
Сканирането чете записаното количество, а то е точно нула. Наличност, която физически стои отзад незаведена или е заведена на друг обект, изглежда точно като наличност, която не съществува. В реална верига това е най-честият от петте случая и най-евтиният за оправяне.
Продължават ли продажбите по SKU, което системата дава на нула? Тази комбинация е невъзможна и решава въпроса, без някой да излиза от офиса. Ако и продажбите са спрели, проверката е някой да отиде до склада. Отговорът влиза в записа, защото незаписаната фантомна нула се връща всяка седмица.
Накратко
Нито един от тези случаи не връща прихода там, където той наистина е бил в риск. Променя се друго: при четири от петте действието става „не прави нищо и запиши защо“, а при петия — „иди и виж“ вместо „плати за ускоряване“. marql разпознава причина само когато тя е в данните: отворена поръчка, равна подкатегория, запис за доставчик. Изчерпване, което живее в главата на купувача, му е невидимо, а точно презаписът, който го отбелязва, е полезното нещо.
Рафтът беше празен. Решението пак се провали.
Пет начина да се обърка, след като сигналът е бил верен. В реда, в който се случват: грешните пари, грешната спешност, грешният адрес, грешната победа, грешното счетоводство. Сценариите са построени, не наблюдавани — зад тях не стоят цифрите на никоя верига.
Надценка, сметната срещу прихода вместо срещу маржа
381 € седмично правят куриера за 100 € да изглежда очевиден. Само че решението не връща 381 €. То връща брутния марж на бройките, които иначе изобщо не биха се продали, а при маржовете на този тенант това са около 223 €. От тях пък се брои само частта, която не отива към друг продукт, печелейки маржа си така или иначе. Два дни от седмица от седем струват около 38 €. Куриерът излиза на загуба, а на екрана нищо не подсказва това.
Умножете, преди да решите: продажби в риск по маржа, по частта, която не би се заместила, по спечелените дни, делено на седем. Резултатът е таванът на надценката. При тази позиция той е една десета от заглавната цифра, не половината ѝ.
Ускоряване на търсене, което вече си е тръгнало
Основна позиция липсва девет дни. Надценката се плаща на осмия, палетът пристига на деветия, а хората, които са я търсили през първата седмица, отдавна са напазарували другаде. Бройките идват; търсенето не се връща с тях. Ускоряването откупува дните, които маха от началото на дупката, а не вече изхабените.
Броят се спечелени дни, не дни без наличност. Ако доставката е щяла да дойде в петък, а надценката я мести в сряда, сметката върви по два дни. При позиция, отсъствала по-дълго от един цикъл на пазаруване, заложете по-нисък процент на връщане от стойността по подразбиране в калкулатора.
Оправяне на рафта, когато причината е нагоре по веригата
Обект се изпразва, получава прехвърляне и се изпразва пак три седмици по-късно. Всеки отделен отговор е бил правилен, но нито един не е стигнал до причината: количество на поръчката под реалното темпо на обекта, срок на доставка, оставен на стойност по подразбиране, която никой не е поглеждал, или маршрут, който подминава този адрес. Надценката се плаща всеки месец, а дефектът така и не излиза наяве, защото всяко събитие се затваря самò.
Пребройте събитията по обект за 30 дни, преди да изберете действие. Повторението не е изчерпване, а дефект в поръчките или логистиката, който се представя за изчерпване. Месечното ускоряване е абонамент за симптома.
Заместване с по-слаб продукт, наречено спестяване
Клиентът е насочен към съседния артикул, дневната каса се задържа и инцидентът се затваря като обработен. Заместителят обаче носи по-малък марж. Веригата е разменила отсъствие с висок марж срещу присъствие с нисък и никой не е записал разликата. Редът с прихода остана равен — точно затова никой не е погледнал реда с маржа.
Заместването е нормално действие и има цена: разликата в марж на бройка между двете SKU-та, умножена по бройките. Ако тази разлика не се знае, защото липсват доставни цени, заместването е неостойностено и се записва като такова, а не като победа.
Измерване, което захваща пика след зареждането
Рафтът се напълва и първите дни продават натрупаното търсене. Срещу тези дни всяко действие изглежда като триумф. Срещу следващия месец позицията е там, откъдето е тръгнала, а регистърът вече е записал възстановяването.
Базата и прозорецът се фиксират при потвърждаване на действието, никога след като цифрите са известни. Прозорецът е достатъчно дълъг, за да събере цели седмични цикли, а не дните веднага след зареждането. На регистъра трябва да се позволи да отговори „без ефект“ и „недостатъчно данни“. Регистър, който казва само „доказано“, не измерва нищо.
Накратко
Четири от петте са грешно действие, избрано по вярно число. Петият е вярно действие, записано нечестно. Формата е същата като в плейбук 01, защото е същият недостиг на смелост в същата точка от цикъла. Най-тежки са първият и третият: единият стъпва върху пари, които всъщност ги няма, другият продължава да лекува проблем на грешния адрес.
Започнете с този, който има значение
Кои от днешните празни рафтове си струва да заредите по-рано срещу доплащане?
Има ли аномалии през последните 7 дни?
1 открита аномалия — няма активни сигнали.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01Кои SKU-та са днес на нула, след като са имали оборот през последните 30 дни?
- 02Колко печели всяко от тях на ден с продажби и какъв марж носи?
- 03За кои от тях има поръчано и за кога е обещано?
- 04Кои са налични в обект, достатъчно близо за прехвърляне?
- 05Кои обекти са се изпразвали повече от веднъж през последните 30 дни и с какво?
- 06Напишете плана: действие, отговорник, срок и прозорец, в който ще бъде оценен.
Какво е нужно, за да остойностите ден отсъствие.
Наличност по SKU × обект
Ежедневна моментна снимка, не броене на живо. Без нея плейбукът изобщо не тръгва. Връзка само с касата често не я носи, а това е първото за проверка, не последното.
Продажби по SKU × обект
Количество, стойност и дата, поне за последните 28 дни. Точно те слагат цена на деня и точно затова плейбукът работи без данни за себестойност.
Брутен марж на SKU-то
Без него отсъствието пак се брои и се подрежда по оборот, но таванът на това колко си струва да го съкратите не се смята. Тогава колоната с решението остава празна, вместо да се запълва със средно за мрежата.
Срок на доставка и какво е поръчано
Доставчик, отворени поръчки и наблюдаваната дата на доставка. От тях зависи колко дни всъщност купува надценката, а това е множителят, около който се върти цялото решение.
Как е изчислено
Сканирането, прозорецът и сметката.
С думите на самия продукт, от блока, който отпечатва под инцидента: сканирането минава по дневните редове на всеки продукт — продажби, себестойност, наличност — и назовава точните SKU-та зад парите, така че всеки артикул носи собствен принос в евро, а не дял от общата сума.
Дневни редове по SKU, обикновено прозорец от 7 до 28 дни според проверката. Проверките за тенденция сравняват два съседни прозореца с еднаква дължина. Цифрата е седмична, защото такъв е периодът на инцидента.
- марж в риск седмично = седмични продажби в риск × брутен марж
- възстановимо = марж в риск седмично × (1 − дял на заместването)
- колко струва спечелен ден = възстановимо ÷ 7 × спечелени дни
- Синхронизация POS / ERP
- product_sales_daily · inventory_daily
- сканиране по SKU
- инцидент, групиран по обект
- inventory_daily
- qty_in_stock
- product_sales_daily
- product_ext_id, revenue
Две неща, които този блок няма да замаже. Първото: себестойност няма сред колоните, които проверката чете. Точно затова плейбукът работи с каса и наличности, и точно затова стъпката с маржа по-долу е вашето число, а не на продукта. Второто: двата екрана не си съвпадат. На 1 септември 2026 г. инцидентът показваше ≈381 € седмично по Granola artesanal. В същата минута marql AI, попитан за същото SKU, отговори ~316,80 € седмично — около 53 € на ден при средно дневно търсене 9,6 бройки и цена 5,50 €, умножени по шест дни вместо по седем. Разликата е около 65 € върху цифра от 381 €. Нито едното число не е измислено и страницата няма да избира любимец. Отбелязва обаче, че решение с такъв размер не бива да се взема върху цифра, която мърда с една шеста според това от кой екран я четете.
Проверете на вашите числа
Трите уравнения отгоре, с отворени полета. Калкулаторът тръгва с цифрите на този плейбук, така че първото, което показва, са 381 € от заглавието, превърнати в числото, върху което наистина се решава. Сменете което и да е поле и сметката тръгва след вас.
- Марж в риск седмично
- 223 €
- Струва си да платите най-много
- 38 €
Две от четирите полета са допускания, не отчитания. Маржът тръгва от 58,5 % — смесената стойност за този тенант — защото при това SKU инцидентът няма колона за себестойност; сложете вашата. Делът на заместването тръгва от 40 %, защото правдоподобна цифра върши повече работа от празно поле, а това е единственото число тук, което никой не може да провери без данни на ниво ред от бон. Калкулаторът не смята надценката: тя идва като оферта от вашия доставчик или куриер. И не знае дали въведените дни са дни без наличност, или спечелени дни. Точно това е режим на провал 02.
Три възможности, три различни бюра.
Трите действия в този плейбук принадлежат на три различни обхвата и никой от тях не може да поеме другите две. Това е необичайно — повечето решения се събират на едно място — и обяснява защо празният рафт толкова често получава отговора, който най-близкият човек може да даде, вместо правилния. Продуктът не оставя това на навика: заявката за поръчка по-долу носи количеството, времевия печат на буфера, от който идва, и изречението „само собственикът или операционният директор може да създаде чернова на поръчка“. Обхватът се прилага, а не се препоръчва.
Управител на обект
Само собствените обекти. Единственият обхват, който държи факт, какъвто никой друг няма: съвпадат ли рафтът и складът.
- Контрапример 05: отиването до склада и записването какво е намерено там.
- Заместването на рафта — накъде да се насочи търсенето и към кое точно живо SKU.
- Дали позицията изобщо може да се продава: увредена, с грешен етикет, с изтекъл срок.
Надценката за ускоряване и прехвърлянето. И двете са разходи, направени извън този обхват, срещу полза, измерена вътре в него, и нито едно от тях изобщо не се появява в този inbox.
Дните от записаната нула до зареден рафт. И дали фантомните нули, които е докладвал, са останали докладвани.
Регионален мениджър
Група обекти. Първият обхват, който вижда едно и също SKU налично на един адрес и липсващо на друг.
- Прехвърлянето, защото това е първият обхват, който вижда и двата му края.
- Изборът между преместване и изчакване — сравнение, което трябва да включи и деня, който самото прехвърляне отнема.
- Кой празен рафт е проблем на мрежата и кой е местен.
Покупката, създала дупката, и срокът, срещу който е поръчана. Регионът мести наличност, която вече има; не може да направи да пристигне повече.
Дните отсъствие в групата и каква част от тях са затворени с преместване, а не с плащане за скорост.
Собственик
Цялата мрежа. Единственият обхват, който вижда един и същ обект да се изпразва отново и отново, а не един обект да се изпразни веднъж.
- Надценката за ускоряване: единственото действие тук, което харчи пари, за да купи време.
- Количеството на поръчката и срока зад режим на провал 03 — причината, не симптома.
- Решението да поемете дупката и да го запишете като решение, а не като пропуск.
Единственият факт, който държи най-малкият обхват: в склада ли е палетът. Всяка надценка, платена по фантомна нула, е одобрена тук и е можела да бъде спряна само на другия край.
Похарчена надценка срещу върнат марж. И дали обектите, изпразнили се два пъти, са се изпразнили и трети.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
Sofia Center
54 000 €−0%−2%Varna Mall
39 900 €+2%−0%Plovdiv East
39 500 €−16%−17%—Накратко
Това са трите обхвата, които продуктът носи, а не твърдение как трябва да е устроена една верига. Верига с централно звено по зареждането има позиция, каквато никой от трите не описва, и този плейбук няма да я измисля. Наложете собствените си длъжности върху обхватите, а не обратното. И забележете, че тук най-евтиното действие е на най-малкия обхват — обратното на обичайното, и точно затова се прескача.
Всичко отгоре, в една таблица.
Нищо от това не иска marql. Продуктът автоматизира ежедневното сканиране по всички SKU-та и обекти. Самият метод е три решения и двайсетина полета, а за един обект се прави на ръка за следобед. Вземете го. Ако сметката постоянно променя това, което иначе бихте направили, ето го и аргументът да я автоматизирате.
Празен ли е рафтът, или е празен записът?
Контрапример 05 и режими на провал 02 и 03, събрани в едно дърво. Минава се преди всякакъв разговор за пари, защото три от четирите му изхода не струват нищо.
Продало ли е това SKU нещо, откакто количеството е станало нула?
- ДаГрешен е записът, не рафтът. Намерете наличността, поправете количеството и запишете причината. Незаписаната фантомна нула се връща всяка седмица и всеки път струва надценка.
- НеРафтът наистина е празен. Продължете.
Важи ли някой от контрапримерите в секция 03 — нарочно изчерпване, приключил сезон, заместител под друг код, позиция, която не е щяла да се върне?
- ДаЗапишете кой точно, кой го е решил и кога записът да се преразгледа. Не действайте. Записът е това, което спира случката да идва като изненада всяка седмица.
- НеТърсенето е реално и необслужено. Продължете.
Колко пъти този обект е стигал до нула през последните 30 дни?
- Повече от веднъжЛекувайте модела, не събитието. Сравнете количеството на поръчката с реалното темпо на обекта и срока с наблюдавания, преди да похарчите нещо за скорост. Това е режим на провал 03.
- ВеднъжЕдинично събитие. Минете на част 02.
Има ли същото SKU в обект, достатъчно близо за прехвърляне, без онзи обект да остане без покритие?
- ДаСравнете прехвърлянето с надценката в част 03. Прехвърлянето също отнема ден, а покритието на изпращащия обект трябва да го понесе.
- НеИзборът е между ускоряване и поемане. Минете на част 02.
Един от пет изхода: поправяте количеството, записвате причина и не правите нищо, отстранявате причината нагоре по веригата, прехвърляте, или остойностявате чакането в част 02.
Колко струва един ден отсъствие
Режим на провал 01 във вид на лист: трите умножения между цифрата на екрана и цифрата, върху която се решава. Всеки ред е по-малък от предишния и точно в това е смисълът.
- Седмични продажби в риск, както ги показва инцидентът
- Направо от инцидента или от експорт на продажби. Дотук данни за себестойност не са нужни: проверката, която вдига сигнала, не чете такава колона.
- Средно дневно търсене и цена на рафта
- Запишете и двете. При демо SKU-то са 9,6 бройки на ден по 5,50 € — оттам идват ~53 € на ден. Това умножение показва и дали седмичната цифра на вашия екран е сметната по шест дни, или по седем.
- Седмични продажби в риск, изравнени
- Дневно търсене по цената, по седем. Ако не съвпада с показаното от инцидента, сте намерили същото несъответствие, което намери и този плейбук. Запишете коя цифра ползвате и защо, защото всичко надолу я наследява.
- Брутен марж на SKU-то
- Маржът на самото SKU, не на категорията и не на веригата. Ако липсват доставни цени, спрете дотук и подредете по оборот. Оценъчният марж превръща тавана в догадка с десетична запетая.
- Марж в риск седмично
- Продажби в риск по маржа. Ускоряването връща това, а не реда над него.
- Дял от търсенето, който се замества
- Допускане, и в листа трябва да е обозначено като такова. Без данни на ниво ред от бон никой не може да го провери. Основните стоки с близък съсед на рафта се заместват масово; позиция, за която хората идват специално, почти не се замества.
- Възстановим марж седмично
- Марж в риск по единица минус дела на заместването. Разделете на седем и умножете по дните, които надценката наистина купува. Именно този резултат, а не редът тук, се сравнява с надценката.
Едно число: колко наистина струва седмица празен рафт във възстановим марж. И дневната ставка под него.
Струва ли си по-ранното пристигане?
Самото разклонение. Три възможности, едно сравнение и четвърти ред, който почти никой не записва: бездействието има цена и често тя е най-ниската на страницата.
- Дата на доставка без намеса
- Наблюдаваната, не договорената. Ако последните три доставки са закъснели, наблюдаваната е истинската.
- Дата на доставка при платена надценка
- Потвърдена с доставчика или куриера, не предполагаема. Непотвърдена дата не купува нищо.
- Наистина спечелени дни
- Разликата между горните два реда. Не дните, вече изкарани без наличност — те са загубени на всяка цена. Това е режим на провал 02.
- Таван на надценката
- Възстановимият марж седмично от част 02, делен на седем и умножен по спечелените дни. Всяка оферта над този ред губи пари дори когато проработи. При демо SKU-то това са около 38 € за два дни срещу 381 € на екрана.
- Оферирана надценка
- Пълната цена на по-ранното пристигане, заедно с всичко, което ускореният маршрут добавя: частичен товар, доставка извън работно време, шофьор.
- Цена на прехвърлянето, ако е възможно
- Транспортът, денят, който отнема, и маржът, рискуван в изпращащия обект. Прехвърляне, което изпразва друг рафт, е преместило проблема, не го е решило.
- Решението и неговата цена
- Ускоряване, прехвърляне, заместване или поемане. И числото, което го е направило най-евтиното от четирите. Поемането също е решение с цена, а записването на тази цена е това, което го прави решение.
Избрано действие заедно със сметката, която го е избрала, и записана цена на невзетата възможност.
Фиксирайте измерването, преди да действате.
Режим на провал 05 във вид на лист. Единствената част със срок: всяко поле се попълва преди действието, защото щом резултатът се знае, нито едно от тях не може да бъде избрано честно. Подсказките казват какво иска самият регистър на marql, така че лист, воден по този стандарт, и продуктът отговарят на един и същи въпрос.
- Действието, в едно изречение
- Какво се прави, по кое SKU, в кой обект и на каква цена.
- Отговорник
- Име с обхват, който наистина може да свърши това — секция 07. Тук трите възможности са на три различни обхвата.
- База, замразена сега
- Цифрата, срещу която ще се мери ефектът, записана и непреизчислявана после. В таблица замразяването значи да поставите стойността, а не да оставите формула, която ще мърда.
- Прозорец за измерване
- Точни дати, избрани сега. Започва след като пикът след зареждането отмине, а не по време на него, и покрива цели седмични цикли. Измерване през пика е режим на провал 05.
- Метриката
- Дни без наличност по това SKU в този обект. Една метрика. Втората е начинът след време да си изберете изгодния резултат. Оборотът тук е лош избор, защото мърда по причини, които това действие не е предизвикало.
- Съпоставени контроли
- Сравними обекти, които не са получили действието. marql не обявява ред за доказан при по-малко от четири такива обекта. Без тях се връща към собствената волатилност на единицата, което е по-слабо твърдение и се обозначава като такова.
- Какво би анулирало прозореца
- Промоция по SKU-то или по най-близкия му заместител, промяна на цената, смяна на доставчик или второ изчерпване вътре в прозореца. При всяко от тях честната присъда е „неубедително“, а не „доказано“.
- Какво е без ефект и какво е по-зле
- И двете, записани преди да ги знаете. Тук „по-зле“ е напълно достижимо: платена надценка, купила по-малко дни от обещаните, е похарчила пари за нищо.
Ред, който може да се затвори в шест посоки: открито, измерва се, доказано, без ефект, неубедително, по-зле. Ако последните три са недостижими във вашата версия, първите три не струват нищо.
Накратко
Това е целият метод. marql не добавя по-добро уравнение. Пуска сканирането всеки ден по всички SKU-та и обекти, а не по рафта, покрай който някой е минал. Групира редовете по обект, за да се вижда повторението като модел, а не като девет отделни инцидента. И води регистъра, така че затворен ред да не може тихомълком да бъде отворен и разкрасен. Сметката отгоре е същата и в двата случая, а делът на заместването си остава число, което никой от двама ни не може да измери.
09 · Границата на доказаното
Приход в риск
≠ доказано връщане.
381 € са седмични продажби в риск по едно SKU в един обект. Това е цифрата на самия инцидент, видима на екрана в началото на страницата. Не е загуба: част от търсенето купува нещо друго при същото посещение и печели маржа си така или иначе. Каква точно част е единственото число тук, което никой не може да измери без данни на ниво ред от бон. marql го няма, затова калкулаторът го пита, вместо да го показва.
Не е и марж. Ускоряването връща брутния марж на бройките, които иначе изобщо не биха се продали — около 223 € при маржовете на този тенант. Възстановимата част от тях, за дните, които надценката наистина купува, е около 38 €. Цифрата на екрана и цифрата, върху която купувачът стъпва, се различават десет пъти, и винаги в една и съща посока.
И не е доказан ефект. Той се записва едва след като действието е изпълнено, базата е замразена и контролният прозорец се е затворил отвъд пика. Когато данните не стигат или външен фактор е изкривил резултата, регистърът отбелязва ефекта като недоказан. Демо тенантът движи собствен часовник, така че всяка цифра тук е моментна снимка, не константа.
Това, което продуктът наистина прави — а екранът по-долу е най-ясният пример — е да отпечата условията до самото отчитане: колко от деня е изминал наистина спрямо очакваното за този час и колко обекта изобщо са подали данни. Цифра за темпо без тези два реда не се чете, а повечето табла пропускат и двете.
Откъде са екраните
Трите повърхности, през които мина решението
Готови ли сте да видите
намерените евро?
Демото се води спрямо касите и счетоводството, които вече използвате. Оставете данните си и изберете час.