A HoReCa kitchen in Riyadh orders roughly the same 35 SKUs from its distributor every week — dairy, packaged staples, packaged proteins, the same volumes give or take a delivery cycle. Nothing about that order is complicated. What is expensive is that, in a phone- and WhatsApp-based ordering channel, the buyer or the coordinator rebuilds it from memory every single week, and a list rebuilt from memory is a list that loses a line item now and then.
Every reorder starts from zero in a manual channel
A WhatsApp voice note or a phone call has no memory of last week's order. The buyer either keeps their own running note — a phone memo, a scrap of paper taped inside a cupboard — or trusts the coordinator to remember what a specific kitchen orders every Tuesday. Neither is a system. Both degrade the moment the usual person is unavailable: the buyer's regular ordering staff member is off, or the coordinator managing that account is on leave and a colleague is covering their book cold.
The cost of this is not that the order is wrong in some dramatic way. It is that reconstructing a known-good order from memory costs genuine minutes every week, and every reconstruction is a chance to drop a SKU, misstate a quantity, or default to whatever is easiest to remember rather than what the kitchen actually needs that week. A buyer who has to do this thirty or forty times a year eventually orders less often than they would if placing the order cost them nothing.
A draft order and a reorder solve two different moments
The Emdaad Buyer Portal treats these as two related but distinct actions, not one feature wearing two names. A draft order is a cart the buyer started and did not finish — they were called away mid-shift, or wanted to check stock levels before committing — saved so they can return to it later without starting over. Reordering is different: it takes a completed order from the buyer's order history and rebuilds it as a new cart, for the buyer who wants to repeat a settled pattern rather than resume an interrupted one.
Both remove the same underlying tax — retyping a known list — at the two points in a buyer's week where it actually shows up: the interrupted session, and the routine week that looks like the last one.
Why neither one carries a price forward
A saved draft or a rebuilt reorder stores SKU and quantity only. It never stores a price, because net price is the output of five pricing layers resolved fresh each time — base price list, contract override, volume tier break, promotional override, and manual customer override — and any one of those can have moved in the time between when an order was placed and when a buyer opens a draft or repeats it. A price sitting in a saved draft would be a stale number pretending to be a live one.
Say the Riyadh kitchen's regular order sits as a draft over a weekend, and a promotional override on one dairy line expires Monday morning. The buyer opens the draft Monday afternoon and the line carries an amber flag naming the cause — promotion ended — before they reach checkout, exactly as it would if the price had shifted mid-session on a fresh cart. Nothing is hidden and nothing is guessed at; the price is re-resolved against whatever rules are in effect the moment the buyer looks at it, not the moment they first built the list.
A draft remembers what the buyer wants to order. It never pretends to remember what it will cost.
A rebuilt cart still passes through the cart, not around it
Reusing SKUs and quantities from a past order is a shortcut on typing, not a shortcut on validation. A reordered or resumed cart is checked against the same MOQ, pack, and order-multiple rules as any other cart, against available-to-promise stock fresh within 60 seconds, and against the account's credit exposure fresh within 5 minutes — the same continuously synced copy of the ERP every order submission checks. If a SKU the kitchen ordered last month has since gone out of stock, or its case size has changed since the last delivery, the buyer sees that at the cart, before submission, not as a short-picked line discovered on the loading dock.
The buyer can also amend or cancel while the order is still pre-release, the same as any order — a rebuilt cart is not a locked commitment the moment it is generated, it is a starting point the buyer confirms or adjusts. This is what makes reordering safe to build as a one-tap action rather than something a buyer has to double-check line by line: the checking still happens, just automatically, at submission, instead of by the buyer re-verifying stock and pricing from memory the way a manual reorder would require.
100% of orders are validated before dispatch — pricing, ATP, credit, and pack rules checked at submission — whether the cart was built fresh or rebuilt from a draft or an order history.
Retention that lives in the platform, not in one coordinator's memory
In a coordinator-run channel, a buyer's ease of reordering is tied to a specific person's memory of that account — how well the coordinator knows this kitchen's usual list, how long they have managed the relationship, whether they are at their desk this week. That is a fragile place to keep a retention advantage: it disappears the day the coordinator moves to a different book of accounts, and it was never something the distributor could see or manage directly in the first place.
Moving the same convenience into structured ordering infrastructure does not change what the buyer wants — the same weekly list, placed with less effort — it changes where that convenience is kept. A saved draft and an order history live on the account, not in one employee's head, available the same way regardless of who is covering that buyer relationship this week. For a distributor watching order frequency drift down for reasons nobody can quite name, the honest first question is not whether buyers still want to order. It is how much effort ordering currently costs them, and whether any of that cost is left over from having to reconstruct, every single week, an order the system already knew.