As developers we love real-time systems — but courier tracking is not one. Here is how TCS parcel tracking in Pakistan actually works, and why it behaves the way it does.
The identifier: every shipment gets a consignment (CN) number — 10 to 12 digits — generated at booking. Tracking number, tracking ID, CN number and consignment number are all the same thing; different sites just label it differently.
The data model is scan events, not GPS. Nobody is tracking the truck live. Each time staff scan the parcel — at a branch, a sorting hub, a delivery point — the system logs a checkpoint with a timestamp. Your tracking page is simply a chronological list of these events: Booked, In Transit, Arrived at Hub, Departed from Facility, Out for Delivery, Delivered. No scan means no update, which is why a parcel can go quiet for hours while moving normally.
For end users, the flow is trivial: enter the CN number on a tracking page like tcs-tracking.pk and the backend returns the event history. No auth needed for a one-off lookup, which is good UX for a high-frequency, low-trust task.
Edge cases worth handling if you ever build on this kind of data: brand-new bookings can take 2-4 hours to appear in the system; 'Delivered' with no parcel in hand needs an immediate support ticket (proof-of-delivery records exist); RTO (Returned to Shipper) usually means failed delivery attempts or a bad address.
The takeaway: it is an event-sourced system with human-speed updates. Design your expectations — and your polling intervals — accordingly. A clean reference for the user-facing side, including status meanings and the helpline (111-123-456), is at tcs-tracking.pk.
Top comments (0)