It sells out in week two, then spends the rest of the month unable to sell. Divide its units by the whole month and it reads as a slow mover, so you reorder it short. Allyvia rebuilds the days each style could actually have sold, divides by those, and shows you the day count it used before you spend.
Ask your POS whether the days it could not sell are in the divisor. We asked all of them. Here is what each one publishes, including the ones that get it right.
You commit cash months ahead and live with the answer for a year. Allyvia does the arithmetic for each one and shows its working, so you can disagree with it before the money leaves.
Velocity is measured over the days a style could actually have sold, reconstructed by walking the stock ledger backwards: it had stock at open, or it sold something, or a delivery landed. A single day is capped at three times your median selling day, so one bridal party of twelve is not read as a demand rate, and the last fortnight counts double.
Honest limit. This reads styles with history. A new-season dress committed six months out has none, and that is the most expensive buy you make.
Quantity is velocity times lead time plus your review period plus safety, less what is on hand and already on order. The review period is the term most often dropped, and dropping it makes every order one cycle short. After a supplier's third real delivery their stated lead time is replaced by the median of what they actually did, so one disastrous shipment does not inflate every order you place afterwards.
Honest limit. Standard inventory theory executed carefully. The narrow parts are the measured lead time, the review-period term, and that every input is shown.
Slow stock is flagged against the lower of an absolute threshold and a share of your own median velocity, so a shop that turns slowly is not told its whole floor is dead. Capital tied is your cost times units on hand. Before a markdown is proposed, Allyvia looks for members who buy styles tagged like that one. The offer is built switched off, and you turn it on.
Honest limit. A cost of zero is treated as unknown, never free, so an item with no cost recorded is excluded rather than reported at full margin.
One style. Twenty-eight days. It sold out on day nine and nobody could buy it after that. The only thing separating these two orders is what you divide by.
18 units ÷ 28 days = 0.64 a day
0.64 × 45 day horizon
18 units ÷ 9 days = 2.0 a day
2.0 × 45 day horizon
Illustrative, and the gap is the point rather than the figures. The case this engine was built against was 27 units where 162 was right. That is two methods on one style, not a measured saving.
Cover, not quantity. A suggestion says how many days of stock are left against how long the supplier actually takes, because that is the form the decision is in.
Illustrative, and every figure on it would be yours. The projection is a model estimate and is labelled as one on the real dashboard too.
Push membership hard with a thin rack and you sell out of goodwill. Buy deep with a quiet circle and the money sits on the floor. Move both and watch what happens.
Balanced on both sides: members carry a steady share of revenue, and the rack turns over without much sitting past 60 days.
Illustrative model, not a forecast. Your own numbers replace these on day one.
The same failure that under-orders a style also aims your best offers at the wrong people, and it is invisible until someone counts.
We loaded one boutique's real export: 13,864 transactions over a year and 420 customer records. Those 420 records were 370 actual people. Forty-seven of them held two or three records each, and because a duplicate splits a person's spend, 32 of the 41 customers who had spent over $4,000 that year did not read as high spenders at all. The best customer showed $4,266. She had spent $9,883.
One shop, one year, one export. Duplicate identities are repaired before anything is tiered, because a tier built on a split record invites the wrong person.
Every recommendation carries an estimated value before you act. Afterwards the outcome is measured against the same figure the recommendation named, at 14, 30 or 90 days, counted once rather than once per window and only when you acted on it.
Their own documentation, quoted, with the link. Including the ones whose answer is better than ours would be if we had stayed quiet about it.
Quantity sold divided by number of days in the time period.Shopify also ships a days-out-of-stock metric, tells you it represents lost sales, and does not subtract it from that divisor.
50 units divided by 32 days (42-10) = 1.5 items sold per day (excluding stock outs).They exclude the out-of-stock days and it drives the suggested order. This is the right answer and it is theirs.
calculated based on the full reporting period, not the period the product was available and in-stock.
average quantity sold in one day during your trailing sales sample period.No stockout or availability concept is documented anywhere in its reordering pages. We are reporting an absence, not a denominator.
Sales velocity = Sales / number of days product was in stock for the selected period.On by default. The dedicated planning tools already do this, and have for years.
Read from public documentation and checked on 14 September 2026. Planners call this censored demand and the correction is decades old, so the argument is not that we invented it. It is that the system ringing the sale is the one that knows which days it could not.
If you already run one, you have the arithmetic. Three things are different here, and none of them is the formula.
None of this is why you would switch. It is why you can. Open any of it if you want the detail, including what each one does not do.
Receipt printers, scanners and cash drawers work out of the box, and you keep Stripe or Square underneath. A sale still rings up if the Wi-Fi drops.
Not yet: physical register hardware has not run outside a simulator, and there is no offline card capture. If you need a webshop, keep selling online where you already do.
Styles, sizes and colourways to the unit across locations, on an append-only ledger with a single write path, which is what makes the sellable-day arithmetic above possible at all.
Not yet: nothing recommends which sizes to buy within a run, and imported sales history does not write ledger movements, so the reconstruction works from the day you go live rather than from your archive.
Revenue, net profit, receivables and cash in one view, posted through to your accounting software, with an overdue payable flagged the day it slips. Refunds net against the day of the sale rather than deleting it.
One definition of revenue, cost and margin across every screen, which sounds like table stakes until two screens disagree.
Rotas drafted against predicted footfall, time clock on the counter, hours flowing through without anyone retyping them.
Not yet: payroll is not built. It is designed around an embedded provider and is not in this product today, so do not plan on it.
Every recommendation carries what drove it, how confident the model is, and an estimated value, then gets measured afterwards.
Honest about the start: a new shop sees a quiet product for its first weeks. The forecast needs about a week of trading, and the savings ledger stays blank until three outcomes have been verified.
You spent years deciding what your shop looks like. Type your address below and see it carried through everything your customers touch. The counter, the receipt, the membership tile, down to the corners of a button. Try someone else's if you'd rather; it works on any address.
These are original style directions, not official merchant brand kits. Explicit colours take priority. Unknown font names are surfaced for review. Image-based candidates are explicitly visual matches, never verified original fonts.
Tiers, perks and member offers run on your own customers today, inside the till and the books rather than beside them. The part that would bring you somebody else's customers is built and has not shipped.
Your tiers, your thresholds, your perks, computed from spend the till already records. Members are matched to one person rather than to duplicate records, and an offer aimed at a segment needs a minimum audience before it can be sent, so a small shop cannot accidentally identify one customer by who redeems.
Limit. Offers apply automatically on the register. On the web till a code is recorded for attribution and does not yet take money off the sale.
A shared consumer app where a member of one boutique discovers another and arrives with standing rather than as a stranger. Merchant-owned status that travels is the one thing a single-shop platform cannot copy, and it is the reason to build it.
Where it honestly stands. The mechanism is written, tested and merged. It has not reached a single shopper, because the consumer app is not in any store. We will not describe it as working until it is. What it needs now is boutiques, not engineering.
If you want to be in it when it opens, say so on the demo and we will put you in the first city we switch on.
Cheaper to read now than to discover in week three. If any of these is the thing you need most, one of the incumbents is the better buy and we will say so on the call.
“The till is not the hard part. The buy is.”
Bring a customer export and a stock export. Before you decide anything we will tell you how many of your customers are actually two customers, and which of your styles the calendar method has been under-ordering. If the answer is none, we will say so and you will have spent twenty minutes.