From order to doorstep, tracked.
Courier labels, pickups and delivery status without leaving the dashboard. No courier panel logins, no spreadsheet, no copy-pasted tracking numbers.
Four couriers, one drawer
One credential per courier, entered once in Settings → Couriers. Nothing to re-key per order.
Enter a credential once in Settings → Couriers
One credential per courier, entered once in Settings → Couriers. Nothing to re-key per order.
Order tracking for online store
The order lifecycle: a state machine, not a status label
Every order occupies exactly one state at a time. Every transition writes an order event with an actor and a timestamp — the same log staff, couriers and a customer's public tracking page all read from.
- 1Placed
- 2Confirmed
- 3Packed
- 4Picked up
- 5In transit
- 6Delivered
| What happens automatically at each lifecycle state | Trigger | Automatic actions | Who can see it |
|---|---|---|---|
| Placed | Customer completes checkout (or staff creates a manual order) | Inventory soft-reserved; order confirmation sent by SMS/email/WhatsApp; fraud/COD risk score attached if enabled | Staff, customer |
| Confirmed | Staff clicks Confirm, or auto-confirm rule passes (e.g. prepaid, or COD under a risk threshold) | Order enters the pick queue; hard inventory allocation; "Confirmed" Bangla SMS sent | Staff, customer |
| Packed | Staff marks items packed against the pick-list | Package weight/dimensions locked for courier rate calc; label becomes eligible for generation | Staff |
| Picked up | Courier scans the label or staff marks manual handover | Pickup timestamp and courier consignment ID attached to the order; "On the way" SMS sent | Staff, customer, courier |
| In transit | Courier webhook posts an intermediate scan | Each scan appended to the public tracking timeline; ETA recalculated if the courier supplies one | Staff, customer |
| Delivered | Courier webhook posts final delivery scan, or staff manually confirms cash-in-hand | COD amount posted to the remittance ledger as "awaited"; inventory deduction finalized; delivery SMS + review-request trigger sent | Staff, customer |
| Returned | Courier webhook posts RTO/return scan, or staff processes a customer-initiated return | Return reason captured; stock optionally auto-restocked pending inspection; return counted against that courier's return-rate metric | Staff |
| Lost | Staff marks lost after courier confirms non-recovery, or after an SLA-breach investigation closes with no resolution | Inventory written off; case flagged for courier claim; excluded from delivery-rate KPI as a distinct category from "returned" | Staff |
Returned and Lost are both exits from In transit, not from Delivered — a parcel does not need to reach the doorstep to leave the pipeline.
Steadfast, Pathao, RedX, Paperfly API
Courier coverage, cut-off and remittance, side by side
No single courier wins every parcel. The right choice depends on four variables you already know at pack time — treat courier selection as a decision tree, not a default.
Destination zone
Weight band
Fragility or liquid
COD value and remittance tolerance
| Courier coverage, cut-off and remittance comparison | Inside-Dhaka coverage | Outside-Dhaka coverage | Typical pickup cut-off | Typical COD remittance cycle | Return window |
|---|---|---|---|---|---|
| Steadfast | Full metro | Wide, most districts | Same-day if booked before contracted cut-off | Weekly, per your contract | Per courier policy |
| Pathao Courier | Full metro | Major districts | Same-day, tight cut-off | Weekly or twice-weekly, per your contract | Per courier policy |
| RedX | Full metro | Wide, most districts | Same-day if booked before contracted cut-off | Weekly, per your contract | Per courier policy |
| Paperfly | Full metro | Widest rural reach, per operator claims | Next-day standard | Weekly, per your contract | Per courier policy |
| Manual / own rider | Your defined zone | N/A | Your own SOP | Same-day cash-in-hand | Your own policy |
Values are couriers' published terms shown for comparison — not a Framique guarantee, and not a substitute for your signed contract.
Inside the order drawer
One drawer, not four portals.
Open the order, pick a courier from the same panel that shows the customer's address and items, generate a label, and request a pickup. The courier's API call happens behind the button; nothing you type goes into a second tab.
- Suggests a courier based on destination, weight, fragility and COD value — pre-selected but always overridable.
- Shows the courier's live quoted rate for that weight band before you commit, not after the label prints.
- Generates and previews the label as a PDF thumbnail inside the drawer; bulk printing is available from the order list.
- Requests pickup with a chosen time window, subject to that courier's cut-off.
- Writes the Confirmed → Packed → Picked up events automatically as each step completes.
Order drawer
Returns and RTO
Return-to-origin is a data problem that surfaces at the courier.
Address and phone verification before confirmation catch most RTOs before a courier ever touches the parcel. A confirmation message for COD orders above a value threshold filters out impulse or mistaken checkouts. Courier-level return-rate tracking turns RTO into a fact you can renegotiate terms with.
- Address and phone verification before confirmation.
- A confirmation call or SMS for COD orders above a value threshold you set.
- Courier-level return-rate tracking, per courier per month.
What a 4-point RTO improvement is worth
600 COD orders/month, average order value 1,200 BDT , gross margin 32%, current RTO rate 14%.
600 × 14% = 84 RTOs × 604 BDT = 50,736 BDT /month
600 × 10% = 60 RTOs × 604 BDT = 36,240 BDT /month
Save 14,496 BDT /mo
Annualized: 173,952 BDT
Recompute this with your own AOV, margin and RTO rate under Analytics → Returns; the formula is (orders × RTO% × (round-trip fee + AOV × margin)).
RTO reduction checklist
- Address field requires area/thana selection, not free text, for Dhaka and major-district addresses.
- Phone number format validated (11-digit BD mobile) at checkout, before payment step.
- COD orders above your set threshold trigger a confirmation SMS with amount and courier name.
- Orders unconfirmed after 48 hours auto-flag to the exceptions queue, not silently expire.
- Return reason is a required field on every RTO event — distinct rows in Analytics, not one bucket.
- Monthly return-rate-per-courier review is a standing item, not ad hoc.
Address quality and phone verification
Two structured fields do most of the work.
A cascading area selector (division → district → upazila/thana) backs the free-text street line, so 'outside coverage' is caught at checkout, not at pickup. Phone numbers are format-validated to 11-digit BD mobile prefixes, with optional OTP verification for COD orders above your risk threshold, sent via the same SMS gateway used for order notifications.
- Cascading division → district → upazila/thana selector, free text remains only for house/road number.
- 11-digit BD mobile format validation at the field level.
- Optional OTP verification for COD orders above your risk threshold — one SMS integration, not two.
আপনার অর্ডার নিশ্চিত করতে এই কোডটি লিখুন: {code}
Packing and pick-list workflow for a small warehouse
1. Batch into a pick-list
2. Pick against the list
3. Pack and weigh
4. Mark packed
5. Batch pickup request
- Pick-list grouped by bin location, not by order number.
- Each line shows product image thumbnail, not just SKU code.
- Fragile-flagged items surface a packing-material reminder at the pack step.
- Weight variance beyond a set tolerance blocks label generation until confirmed by a second staff member.
- Batch pickup grouped by courier and by pickup time window.
Inventory reservation and oversell prevention
Soft reservations that never reach Confirmed release back to available stock automatically after a configurable timeout — commonly 30–60 minutes for payment orders, longer for COD orders pending a confirmation call.
| Stock states and availability | When it applies | Available to sell? |
|---|---|---|
| On hand | Physically in the warehouse, uncommitted | Yes |
| Soft-reserved | Order Placed, payment not yet settled or COD not yet confirmed | No — decremented from available immediately |
| Hard-allocated | Order Confirmed | No — locked to that order specifically |
| Deducted | Order Delivered | No — permanently removed from on-hand |
| Restocked | Order Returned and inspection passed | Yes, once inspection completes |
Delivery-status webhooks and Bangla customer notifications
Each row is independently toggleable per merchant — high-touch WhatsApp support can disable SMS for 'In transit' and keep only 'Confirmed' and 'Delivered'.
| Notification rules and Bangla copy | Channel | English copy | বাংলা copy |
|---|---|---|---|
| Confirmed | SMS | Your order #{id} is confirmed and being packed. | আপনার অর্ডার #{id} নিশ্চিত হয়েছে, প্যাক করা হচ্ছে। |
| Picked up | SMS | Your order #{id} is on its way with {courier}. | আপনার অর্ডার #{id} {courier}-এর মাধ্যমে যাত্রা শুরু করেছে। |
| In transit (out for delivery) | SMS | Your parcel is out for delivery today. | আপনার পার্সেল আজ ডেলিভারির জন্য বের হয়েছে। |
| Delivered | SMS + review request | Delivered. Thank you for your order — rate your experience: {link} | ডেলিভারি সম্পন্ন। ধন্যবাদ — আপনার অভিজ্ঞতা জানান: {link} |
| Returned | SMS | Your order #{id} could not be delivered and is being returned. We'll contact you. | আপনার অর্ডার #{id} ডেলিভারি সম্ভব হয়নি, ফেরত পাঠানো হচ্ছে। আমরা যোগাযোগ করব। |
Exceptions queue and SLA breach handling
Each exception surfaces with the order, the courier, the last known event, and time elapsed since that event — sorted oldest-first.
No confirmation after 48 hours
No pickup scan after cut-off
No transit scan for N days
Delivery attempted but not completed
Remittance reconciliation with the courier
45 Delivered orders in a remittance cycle, COD total 54,200 BDT . Courier pays 52,900 BDT . The 1,300 BDT gap is flagged Short, with the underlying order-level amounts listed so the specific orders responsible can be raised with the courier directly.
| Remittance ledger states | Meaning |
|---|---|
| Awaited | Order Delivered, COD amount logged, courier has not yet paid out. |
| Remitted | Courier payout received and matched to one or more orders. |
| Short | Remitted amount doesn't match the sum of matched orders — flagged for manual reconciliation. |
| Disputed | Order marked Delivered by courier webhook, but no matching remittance after the courier's stated cycle has passed. |
Peak-season capacity checklist: Eid and Pohela Boishakh
Order volume during Eid-ul-Fitr, Eid-ul-Adha and Pohela Boishakh windows routinely multiplies baseline daily volume. Plan against capacity, not just demand.
- Confirm each courier's own stated peak-season cut-off changes in advance.
- Pre-negotiate a temporary rate or priority-pickup arrangement if peak volume will meaningfully exceed your contracted volume.
- Increase the soft-reservation timeout for payment orders if gateway load is expected to slow checkout completion.
- Stage packing materials and box sizes for your peak-week forecast, not your average week.
- Schedule extra confirmation-call staffing for the COD confirmation step.
- Set a temporary, explicit delivery-delay notice on the storefront and in the Confirmed SMS.
- Review the exceptions queue daily, not weekly, during the peak window.
- Reconcile remittance more frequently during and immediately after the peak window.
Framique vs spreadsheet + courier panels
The spreadsheet doesn't disappear because it was bad at its job — it disappears because a state machine and a webhook do the same job without the re-typing.
| Framique compared to a spreadsheet and courier panels | Spreadsheet + courier panels | Framique |
|---|---|---|
| Choosing a courier per order | Manual judgment call, no data | Suggested by the decision framework, always overridable |
| Generating a label | Log into courier panel, re-type address | Generated from the order, address already there |
| Requesting pickup | Separate action per courier panel | Batch request from the order list |
| Tracking status | Check each courier's tracking page manually | Webhook-driven timeline on the order and a public customer page |
| Customer “where is my order” messages | Manual reply, per message | Bangla notifications sent automatically at each state |
| Return rate per courier | Not tracked, or tracked manually in a separate sheet | Automatic per-courier, per-month metric |
| COD remittance matching | Manual line-by-line against a courier statement | Auto-matched, exceptions surfaced as Short/Disputed |
| Oversell prevention | Manual stock check, error-prone at volume | Soft-reservation at order placement, real-time |
| Exceptions (stalled orders) | Discovered when a customer complains | Surfaced automatically by elapsed-time thresholds |
| Peak-season readiness | Ad hoc, remembered from last year if at all | Checklist and capacity settings built into the same dashboard |
16
Payment rails wired end to end
Fulfilment questions, answered
Do I need all four couriers, or can I use just one?
What happens if a courier's webhook goes down temporarily?
Can I use my own delivery riders instead of a third-party courier?
How is the return rate per courier calculated?
Does the risk score for COD orders auto-cancel anything?
What if the courier's remittance amount is short and they dispute the shortfall?
Can customers track their order without creating an account?
Does inventory get restocked automatically after a return?
How far in advance should I set up peak-season settings?
What data do I need to switch from a spreadsheet workflow?
Stop reconciling parcels by hand.পার্সেল হাতে হিসাব করা বন্ধ করুন।
Every state change, every label, every remitted taka — one ledger, not four browser tabs.