COD order verification

What is the difference between verification and confirmation?

Verification asks whether the order can physically be fulfilled at all: is the phone number valid, is the address in a wilaya and commune the carrier actually serves today, and is this a duplicate of an order already sitting in the system from the same customer. Confirmation asks a separate question entirely: whether the customer still wants it and agrees to the specifics as recorded when they placed the order. A store can verify an order is real and deliverable and still have the customer decline it at confirmation once they see the total price written out. The reverse is true too: a customer can eagerly confirm an order whose phone number or address was never actually usable in the first place, and confirmation alone would never catch that on its own. Skipping verification and going straight to confirmation means some fraction of "confirmed" orders still fail because the phone number was wrong all along, which shows up as a delivery failure rather than a return, but costs the same fees and the same lost time regardless of which label eventually gets attached to it in your records.

What should a verification check actually cover?

A phone number in a valid Algerian mobile format, starting with 05, 06 or 07, since a malformed number cannot be reached by the carrier's driver either, no matter how carefully the rest of the order was filled out by the customer. An address that names a real wilaya and commune the carrier serves, since not every commune has stopdesk or home-delivery coverage from every carrier operating in the country, and assuming coverage without actually checking creates a failure that only surfaces once the parcel is already in transit and money has been spent moving it. And a duplicate check: the same phone number or the same name-and-address combination placing multiple orders for the same product in a short window, which is usually an accidental double order from a customer clicking twice in frustration rather than two genuine separate purchases worth fulfilling in full and shipping separately.

What happens when verification fails?

None of these should silently proceed to shipping regardless of how tempting it is to keep the queue moving quickly on a busy day. An order that fails verification and ships anyway becomes a failed delivery attempt that costs the outbound fee for nothing gained in return, and that fee is charged whether or not anyone ever actually notices the underlying cause of the failure afterward.

Should verification happen before or after confirmation?

Before, when possible, and this ordering is worth being genuinely deliberate about rather than leaving to chance. Confirming a customer's agreement to an order that cannot actually be delivered wastes the confirmation step entirely, because the order still fails downstream regardless of what the customer said in reply to the confirmation message. Running a quick verification pass, even automated and near-instant against your existing coverage data, before sending the confirmation message means the confirmation conversation only happens for orders that could actually ship if the customer agrees to them, which respects the customer's time as much as it protects your own from wasted effort.

How does verification change with order volume?

At low volume, a person can eyeball a phone number and address for obvious problems as each order comes in, one at a time, with full undivided attention given to it. Past a few dozen orders a day, that eyeballing degrades measurably: tired reviewers miss the same class of error repeatedly, usually late in the day when attention is thinnest and the queue feels longest. A ruleset that checks phone format and carrier coverage automatically, and flags duplicates by matching against the existing order list in real time as new orders arrive, catches what manual review starts missing once volume passes what one person can carefully check order by order without cutting corners under time pressure to keep up.