Actionable Data Insight Services

The dashboards read the same tables the call-centre panel writes to, so there is no nightly ETL and no reporting lag. Counters aggregate live: orders by queue state — unassigned, assigned, confirmed, cancelled, postponed, no-response — per-agent throughput, and a live unconfirmed count pulled from the upstream order hub with anything already assigned locally excluded, so the same order is never counted in two places.

Confirmation rate is derived from the actual attempt history rather than a summary column: every call attempt is its own row, carrying its number, its result and the agent who made it. For store-scoped users the figures are filtered by source and store code rather than by assignee — which is what makes the multi-store queue view correct for a store that has no named agent working it.

Scoring runs on signals the order pipeline already captures, not on anything the customer is asked. Per order that means the complete courier event history and every status transition; the COD amount alongside the COD-received and delivery-charges-paid values reconciled after delivery; the call-attempt record, including how many attempts confirmation took and whether the customer ever answered; a normalised phone number with the SKU and quantity fingerprint used for duplicate detection inside a 24-hour window; and the address-quality flags produced by geocoding.

Return-to-origin batches close the loop. A returned order is received against a batch, validated on scan, and its inventory added back — so every RTO produces a labelled outcome tied to the same features the score was computed from, and the model is retrained on what actually came back rather than on what was predicted.

One inbound layer takes orders from Shopify, YouCan and WhatsApp. Each storefront posts to its own endpoint and the raw payload is logged before anything is parsed, so nothing is lost to a malformed request. WhatsApp orders arrive as free text and run through a Unicode-safe parser that extracts reference number, customer name and number, product SKU and quantity, address, COD amount and store code.

Phone numbers are normalised to Saudi format on arrival, so one customer resolves to one history however the number was typed. Store code is read from the signed-in session and never from the request body, so an order cannot be pushed into another store’s book. Duplicate detection runs inside a lock before insert: the same phone with the same SKU and quantity map inside a 24-hour window of a live order is caught and auto-cancelled rather than shipped twice.

Every carrier posts status callbacks to its own endpoint — iMile, Shipa, Jingdong and COD Solutions. Each follows the same shape: log the raw payload, acknowledge with 200 immediately so the courier does not retry, then process the update in the background through one shared status pipeline that writes the order’s status, site and history and applies the matching inventory effect. Because acknowledgement and processing are separate, a slow database never turns into a carrier-side retry storm.

Booking runs the other way through the same layer: shipment creation returns a tracking number stored against the order, and labels are generated and merged into a single PDF for a dispatch run. Timestamps from every carrier are normalised to the KSA zone on arrival, which is what makes transit time and delay genuinely comparable across four couriers running on four clocks.

An address written by a customer is rarely an address a courier will accept. The location pipeline takes the raw text, creates or updates the order’s location record, calls the geocoding service through an n8n workflow, matches the response back to the order by reference number, stores the resolved latitude and longitude, then runs a reverse lookup to derive the area and the city.

Validation is strict on the join. If the resolved area does not belong to the resolved city, the area is cleared rather than guessed — a plausible-but-wrong zone costs a failed delivery and a return leg, which is more expensive than an empty field. Customer-supplied location payloads are accepted on the same path, so a pin dropped in a chat corrects the record before dispatch.

The web host and the database hosts run their clocks in different zones, so “today” is never read from a machine. A single helper resolves the Asia/Riyadh day and everything routes through it: dashboard counters, agent and admin reports, every date filter, and the date anchoring applied to bulk imports as they land.

Scheduled work is pinned the same way. The nightly routine that auto-confirms postponed orders whose date has arrived runs at midnight KSA, not at midnight wherever the server happened to be provisioned. Inbound courier timestamps are normalised on arrival too, so a delivery recorded at 01:00 UTC does not quietly fall into yesterday’s numbers.