# 01 BUSINESS REQUIREMENTS ## 1. Business model Low-inventory, on-demand fulfilment. No warehouse. Products are sourced from a nearby factory or store on order. The money path: customer orders on the site, chooses Cash on Delivery, the order is verified by phone or WhatsApp, the factory prepares it, a courier collects and delivers it, the courier collects cash from the customer, and the courier remits that cash to the business in a periodic settlement batch. Two consequences shape the entire system: 1. **Verification is the core operational loop, not a nicety.** Unverified COD orders become RTO, and RTO costs courier charges with no revenue. 2. **Cash collection and cash settlement are separate events.** The system must track both, or the owner cannot tell which courier owes what. ## 2. Personas **Ayesha, the buyer.** 25 to 45, shops on an Android phone over 4G, arrives from a Meta ad or a Google search. Wants to see the fabric clearly, know the size fits her bed, know the total price including delivery, and pay cash at the door. Will abandon a checkout that asks for a password or an email she does not want to give. Trusts a real phone number and a real address in the footer more than any badge. **The owner, running operations.** Not technical. Opens the admin twice a day. Needs to see which orders need a call, call them, confirm them, hand a list to the factory, type in tracking numbers, and see what the courier owes. Every extra click is a cost. **Future: a fulfilment assistant.** Should be able to update fulfilment and courier fields without touching prices, settings or plugins. ## 3. Core user journeys **Purchase, guest, COD.** Land on homepage or a category from an ad, filter by size, open a product, choose size and colour, see the COD badge and delivery estimate, add to cart, checkout in one page with name, mobile, province, city, area and address, select COD, place order, see confirmation with the order number and a note that a call is coming, receive a WhatsApp confirmation. **Verification.** Owner opens the Verification Required filter, works top to bottom, taps a WhatsApp link that is pre-filled with the order details, marks Confirmed or logs an attempt or cancels with a reason. **Fulfilment.** Confirmed orders are listed for the factory, marked Packed, then Ready for Courier, then Shipped with a courier name and tracking number, which triggers the shipped email. **Delivery and cash.** Order marked Delivered, COD marked Collected with a date, then reconciled against a settlement record when the courier remits. ## 4. Business rules ### 4.1 Phone numbers Canonical stored form: `03XXXXXXXXX`, eleven digits. Accept and normalise on input: `+92 3XX XXXXXXX`, `0092...`, `92...`, spaces, dashes, brackets. Reject anything that does not resolve to `03` followed by nine digits. Validate the operator prefix is in the live set (030 to 034, plus 035 where relevant). Landlines are not acceptable as the COD contact number. Store the raw entry alongside the normalised value for audit. A duplicate phone number on an open order triggers a warning at checkout and a flag in admin. ### 4.2 COD thresholds Admin-configurable settings, never hard-coded. Suggested launch values, to be confirmed by the client: | Band | Rule | |---|---| | Under Rs 5,000 | auto-confirm, one WhatsApp confirmation message | | Rs 5,000 to Rs 20,000 | mandatory verification call or WhatsApp reply before confirmation | | Above Rs 20,000 | verification plus optional partial advance of Rs 1,000 or 20 percent, cancel after 48 hours if unreachable | Verification is forced regardless of value when any of these are true: - a single line item quantity is above 5 - the phone number has a prior RTO or cancelled order - the delivery city is not in the recognised city list - the address is under 25 characters ### 4.3 The verification loop Run twice daily, 10am and 5pm. Filter to Verification Required, sort oldest first, work top to bottom. For each order: tap the WhatsApp button (pre-filled message), wait for a reply, otherwise call. Mark Confirmed, or Log Attempt, or Cancel with a reason. After three failed attempts across 48 hours, cancel as unreachable. For this to be a thirty-second job per order, the order list row must show, without opening the order: order ID and age in hours, customer name, phone as a tap-to-call link, city, order total, a short badge saying why verification triggered (High Value, Prior RTO, Unknown City, Large Quantity), attempt count, prior order count and prior RTO count for that phone, and the items in one line. Three inline buttons on the row: Confirm, Log Attempt, Cancel with reason. No page reload between orders. Every action writes an order note automatically. That is the audit trail. ### 4.4 Cancellation The customer can cancel free of charge until the order reaches Ready for Courier. After courier handover, a refusal at the door is RTO, not a cancellation, for reporting purposes. Admin can cancel at any point with a mandatory reason code: unreachable, customer cancelled, out of stock at factory, fraud suspected, duplicate order, out of service area. ### 4.5 RTO When a parcel returns: the order moves to RTO, stock is restored if stock tracking was on, COD is never recorded as collected, and the courier RTO charge (typically Rs 150 to Rs 300) is recorded against the order so gross margin stays honest. The customer's phone number gets an RTO counter. Two RTOs disables COD for that number and checkout shows advance payment only. ### 4.6 Returns and exchanges Bedding is a hygiene product, so the policy is narrow and must be stated on the product page. Accepted only if the packaging seal is unopened, within 7 days of delivery, and only for: wrong item sent, wrong size sent, manufacturing defect, or transit damage. Used or washed bedding is not returnable. Pillows and opened bedding sets are non-returnable unless defective. Exchange is preferred over refund, because a COD refund requires an outbound cash transfer. Where a refund is unavoidable it goes by bank transfer or wallet within 7 working days and the customer supplies the account title and number. Return shipping is paid by the business only where the business was at fault. ### 4.7 Shipping and free shipping Pakistan-wide flat rate, configurable in WooCommerce, with a city-tier override. City tiers live in `bc_settings` under `city_tiers`. Each tier holds a city list, a shipping fee and a lead-day range, so the delivery estimate on the product page and at checkout reflects where the customer actually is. Launch with one tier covering everywhere, and add tiers when the courier's own rate card is confirmed (open question 3). Everything reads through one method, `BC_Locations::tier_for_city()`, so adding a tier changes no template. The free shipping threshold is calculated on the cart subtotal **after coupon discount and excluding shipping**, so a coupon cannot be stacked to unlock free delivery. Suggested launch threshold Rs 3,000. The cart shows a progress nudge: "Add Rs 640 more for free delivery." If a partial cancellation drops the order below the threshold, shipping is not retro-applied in MVP. ### 4.8 COD collection and settlement Two distinct events. **COD Collected**: the courier confirms the customer paid. Recorded per order with a date and an amount. **Settlement Received**: the courier remits cash to the business, usually weekly or biweekly, covering many orders at once. Recorded as a settlement record with a reference, date, gross amount, courier charges deducted, net received, and the list of orders it covers. Any order marked Delivered but absent from a settlement after 21 days appears on an ageing report. That report is how the owner catches courier shortfalls. ## 5. Order lifecycle See `docs/06-DATA-MODEL.md` for slugs. The commercial states are: Pending Payment (online only), Verification Required, Confirmed, Shipped, Delivered, plus Cancelled, RTO and Refunded. Fulfilment stage, delivery status, COD status and settlement are meta fields on the order, filterable in the order list, not separate statuses. The reasoning is in decision D-04. Stock reduces at Confirmed, not at Pending. Delivered is the only status counted as revenue. ## 6. Non-functional requirements - Mobile first. Most traffic is Android on 4G. - LCP under 2.5 seconds on a throttled 4G connection, CLS under 0.05. - The site must survive a Meta ad traffic spike on shared hosting, which means anonymous traffic is served from page cache and never touches PHP. - Order emails must reach the inbox, not spam. - The owner must be able to run a full day of operations without technical help. - Everything translation-ready for a future Urdu version, English at launch. - No card data is ever received or stored. ## 7. MVP boundary **In scope**: product catalogue with variations, discovery and filtering, product detail, cart, guest checkout, COD with verification, order management with fulfilment and manual courier tracking, COD collection and settlement, coupons, reviews, order emails, an operations dashboard, GA4 and Meta Pixel, SEO fundamentals, security hardening, backups. **Out of scope for MVP**, deferred with reasoning in decision D-21: customer accounts, photo reviews, uploaded product video, pattern and availability filters, per-user coupon limits, coupon category restrictions, CAC and ROAS analytics, Urdu localisation, a factory portal, courier API integration, and a second staff role. ## 8. Success criteria The MVP is ready when a real customer can discover a product, understand it, pick the right variation, add it to cart, check out as a guest, choose COD, place the order and get a confirmation. And the owner can see the order, verify it, confirm it, send it to the factory, assign a courier, record tracking, mark it delivered, record COD collection, reconcile a settlement, manage products and read the day's numbers. If all of that works reliably, it ships.