Product
The SKUs That Should Never Auto-Order
Automation earns its keep on routine decisions — so the scoping question worth answering deliberately is which items are never routine.
Scope is a positive selection, so exclusion happens silently
An automation rule in Assisty is three choices: supplier, scope, cadence — then Assisty generates the purchase orders on time. Two of those are logistics. The third is a policy decision wearing a filter's clothes.
A rule's scope is a filter — “items below reorder point,” say. That's a positive selection: it names what qualifies. Everything it doesn't name is excluded — silently, on every run, forever. You never see a list of what the rule passed over: a skipped item produces nothing to look at.
Exclusion isn't a switch you flip; it's the shape of what you left out. Those SKUs are worth deciding before the run, not in a receiving bay. Two questions get you there.
Can the math see it, and could you unwind it?
The first is legibility. Every suggestion in the Smart Buying Table is computed from your sales velocity, lead times, and incoming stock — and an automation rule seeds its POs with those same suggested quantities. So the question to ask about a SKU is not “is the number right?” but “does this item have the inputs the number needs?” Any velocity-based computation still returns a number when the history is thin; what it can't return is confidence in it — and a scheduled rule will act on it either way, without anyone reading the row.
The second is reversibility. Inside the buying table, mistakes are cheap: every change shows a was→now chip with per-row undo, and nothing is committed until you create the order. Once a PO clears the approval queue and reaches a supplier, undo becomes a phone call, a restocking fee, or a season of dead stock. What matters isn't how likely a rule is to be wrong, but what a wrong quantity costs when it is.
Legibility and reversibility echo the two axes ABC/XYZ classification crosses — value against predictability — asked one SKU at a time.
| SKU pattern | Can the math see it? | Could you unwind a wrong order? | Belongs in a rule's scope |
|---|---|---|---|
| Steady repeat seller, short lead | Yes — regular velocity to project from | Yes — the next cycle absorbs a small miss | Yes |
| New launch | No — no history to compute from | Sometimes, but the miss is usually large | Not until it has cycles behind it |
| Erratic or lumpy seller | Barely — an average that describes no real week | Depends on shelf life | No |
| Long-lead import | Only at a horizon the forecast can't reach | No — the money is committed for months | No |
| High-MOQ, perishable, or end-of-life | Possibly | No — one step is the whole bet | No |
The four patterns that fail one of the tests
New launches. A product with no sales history gives velocity nothing to compute from. Any number you attach to it is an assumption, and an assumption should have a person's name on it. A launch belongs outside the scope until enough real cycles accumulate that the math is reading the product, not your guess about it.
Erratic and lumpy sellers. Here history exists; it just doesn't generalize. Long gaps punctuated by wildly different order sizes produce an average velocity that describes no week that ever happened. It's a number, not a signal — and a weekly rule can't tell the difference.
Long-lead imports. A longer lead time forces the forecast further out, and accuracy falls the further out you go. The order also commits money for the whole of that window, with no correction available until the goods land.
Take one steady seller and change nothing but the lead time. At a one-week lead, an automated order bets roughly a week of demand; if the estimate drifts, next week's run corrects it. At a ten-week lead, the identical rule commits much of a season, and the first correction arrives when the container does. Same SKU, same math, same rule — very different money riding on one unreviewed number. (Illustrative — no store figures.)
Anything you couldn't unwind. High minimum order quantities and case-pack rounding make the smallest possible correction a big step. Perishables convert an over-order into waste on a clock. End-of-life and seasonal exits are items you're deliberately running down, where a routine top-up reverses the decision. Custom goods have no exit at all.
“The approval queue will catch it” is not a scoping strategy
It's a fair objection: every auto-generated PO lands in an approval queue, where you review it, adjust it, approve or reject it, and suppliers only ever see what you signed off on. The gate is real.
But a gate's value depends on the attention it gets, and attention is the scarce input. Scope everything in and the queue fills with drafts that are almost always fine — precisely the condition under which the one that isn't gets waved through. Exception management works because exceptions are rare enough to be worth reading; routine approvals train the opposite habit.
Narrow scope is what keeps approval a decision rather than a reflex. Automation does the routine; you keep the judgment — and that split only holds if the routine part is genuinely routine.
Excluded isn't neglected. It's routed.
Leaving a SKU out of a rule's scope doesn't mean nobody buys it. It means it's bought where the judgment tools live: the Smart Buying Table surfaces what matters ranked by money at stake, each finding carrying its one-tap fix, and you can tell Atlas how reality differs from the data and watch the table recompute. Then you select the rows you're ready to buy and create the purchase orders — Atlas splits the selection into one PO per supplier and asks which location receives it.
Both lanes end in the same place: an ordinary purchase order — one drafted for you and reviewed, the other decided by you and created.
And the boundary should move. Rules are created and managed in the UI, or by just telling Atlas what you want, so scope is editable as facts change. A launch with clean cycles behind it can be scoped in; a steady seller whose supplier switches to a long overseas lead comes out. The exclusion list is a living document, not a setup step.