Automate the reorder, keep the approval

The part of reordering worth automating

Most of what routine reordering asks of you is repetition. For a given supplier, on a regular rhythm, someone checks which items have fallen below their reorder point and builds a purchase order to top them back up — and then does it again next week, and the week after. That repetition is what makes it a chore, but it's also what makes it safe to hand off: the judgment in replenishment isn't in generating the draft, it's in deciding whether to send it. Assisty's automation is built along exactly that seam. Routine purchase orders draft themselves on a schedule you set, and nothing reaches a supplier until you approve it. You set the rules once, and the recurring mechanics — remembering it's Monday, pulling the below-threshold list, assembling the order — stop being something you do by hand every cycle. What's left on your plate is the part that actually needs a person: the yes or no.

A rule is a supplier, a scope, and a cadence

A rule is three choices: the supplier, the scope, and the cadence. Choose those, and Assisty generates the purchase orders on time — seeded with the same suggested quantities you'd get in the Smart Buying Table. That detail matters, because it means an auto-drafted order isn't a rougher approximation than one you'd assemble by hand; it starts from the same buying-table math you'd use anyway. A typical rule reads like a sentence: every Monday, draft a purchase order for anything from a given supplier that's dropped below its reorder point. You can create and manage those rules in the UI — picking the supplier, the scope, and the cadence from the interface — or you can just tell Atlas what you want in plain language, describe the rule the way you'd say it out loud, and let it set the rule up for you. Either way the output is the same: a draft that appears on schedule, already populated, waiting for you.

Nothing reaches a supplier until you approve it

The reason automating this doesn't mean losing control is that automation drafts orders; it doesn't send them. Every auto-generated purchase order lands in an approval queue. You open it, review what it's proposing, adjust anything that needs adjusting, and then approve it or reject it — and a supplier only ever sees an order you signed off on. Nothing goes out on the strength of a rule alone. That division is deliberate: the rule takes over the routine, and you keep the judgment. It removes the step of remembering to build the order and pulling the numbers together, not the step of deciding whether this cycle's order is actually right. If demand shifted, if you'd rather hold off on a slow mover, if a supplier's terms changed — you see the draft before any of it becomes a commitment, and rejecting it costs nothing. Automation handles the part that's the same every week so your attention goes to the part that isn't.

The same purchase orders, not a second system

It also helps that an auto-generated PO isn't a separate species of order. It's an ordinary purchase order — the same one-PO-per-supplier grouping, the same tax, currency, and landed-cost handling, and the same lifecycle and pre-send review as the orders you create directly from the buying table. So turning on a rule doesn't fork your process into "real" purchase orders and "automated" ones you have to reconcile against each other later; there's one kind of purchase order in the system, and a rule is simply another way to draft it. Everything downstream — how it groups by supplier, how it costs out, how it moves from draft to approved to sent — works the way it already does. The automation changes who assembles the draft and when, not what a purchase order is. That's what makes it something you can leave running: it isn't a parallel workflow to babysit, just your existing one with the repetitive first step taken off your hands.