How to Build an Order Tracking System

The commercial case is simple. Every "where is my order?" message costs staff time, and each unanswered one raises the chance of a refund request or a chargeback dispute. Stores that publish honest tracking absorb far fewer of those messages, and the ones that do arrive are easier to answer because the history is already recorded.

This is a build guide: the data model, the integrations, the page, the messages and the costs. It assumes you already have a delivery process; if that part is still informal, sort the dispatch workflow out first.

What an order tracking system does

An order tracking system records the state of every order as it changes, exposes that state to the customer in plain language, and notifies them at the moments that matter. It sits between your order management and your delivery partners.

It is made of four layers:

Tracking is not the same as a courier waybill lookup. A waybill covers only the courier's leg. Customers want to know about everything from payment to doorstep, including the two days the item sat waiting for stock.

Step 1: Design the status model

Start here, on paper, before any development. A good model has two layers: internal statuses for your team and customer-facing statuses in plain language.

Three design rules:

1. Customers need fewer states than you do. Collapse packed, awaiting pickup and similar into "being prepared". Internally keep the detail.
2. Every status needs an owner and a maximum age. If an order has been "being prepared" for three days, something is wrong and an alert should fire internally before the customer complains.
3. Statuses move forward, with defined exceptions. Write the allowed transitions down. Orders should not jump from paid to delivered without the states in between, or your data becomes useless for diagnosing delays.

Store each change as an event with a timestamp, the actor and an optional note, rather than overwriting a single status field. The event log is what lets you answer a dispute honestly weeks later.

Step 2: Decide where status events come from

Automatic updates are the whole point. Every status that depends on a human remembering will eventually be wrong.

• Payment provider webhooks. Paystack, Flutterwave and similar providers can notify your system when a payment succeeds, fails or is refunded. Verify the webhook signature and make handling idempotent so a repeated callback does not duplicate an order.
• Courier APIs and webhooks. Where your courier supports it, map their status codes to yours once, in a translation table. Courier vocabularies differ, and you do not want their words leaking into your customer messages.
• Rider app or dispatch tool. For in-house delivery, the rider marks picked up, delivered or failed, with a photo or a delivery code.
• Staff actions in admin. Stock confirmation, packing and cancellations. Keep these to as few clicks as possible.
• Scheduled checks. Where a courier has no webhook, poll their tracking endpoint on a schedule and update from the response.

Build a fallback rule for every source. If a courier webhook stops arriving, the system should flag orders stuck in transit beyond the expected lead time rather than leaving them silent.

Step 3: Build the customer tracking page

Requirements that matter more in practice than design:

• No login required. Access by order number plus phone number or email, or by a unique link in the order message. Most Nigerian shoppers check out as guests, and forcing account creation to check an order is a support call waiting to happen.
• Mobile-first and light. The page will mostly open from a WhatsApp link on mobile data. Keep it under a few hundred kilobytes.
• Plain-language timeline. Current status at the top, in large text, then the history with dates.
• An expected date, not a promise of an hour. "Expected Thursday 24 September" with a note that traffic and weather can affect timing.
• Item list and delivery address, so the customer can spot an address error early.
• Courier name and waybill number where relevant, with a link to the courier's own tracking.
• A contact action that opens WhatsApp with the order number pre-filled, so support does not start with "what is your order number?".
• Honest delay messaging. If an order is late, say so on the page with a reason. Silence generates refund requests.

For repeat customers, an account order-history page adds value, but it should complement the guest tracking link rather than replace it.

Step 4: Set up notifications people actually read

Choose events carefully. Too many messages get muted; too few create uncertainty.

A sensible default for a Nigerian store:

Practical notes:

• WhatsApp is where Nigerian customers live, but business-initiated messages at scale run through the WhatsApp Business Platform from Meta, which requires approved message templates and has per-message costs. Smaller stores start with the WhatsApp Business App and manual or lightly automated sending.
• SMS remains the reliable fallback when a customer has no data. Keep it short, include the order number and one link.
• Email carries the detail: invoice, item list and policy.
• Include an opt-out and honour it. Under the Nigeria Data Protection Act 2023 you should tell customers what you collect and why, and transactional messages should stay transactional rather than becoming marketing.

Step 5: Choose a build route

Indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate.

Implementation sequence that avoids rework:

1. Agree the status model and the customer-facing wording.
2. Add the event log to the order data model.
3. Wire payment webhooks, then staff admin actions.
4. Build the tracking page and the WhatsApp or SMS dispatch message.
5. Add the first courier feed and the status translation table.
6. Add stuck-order alerts for your operations team.
7. Add the second courier and the reporting dashboard.

How much does an order tracking system cost?

Beyond build cost, budget the running costs, which scale with orders rather than with time.

A quick way to judge the investment: estimate the staff hours spent each week answering order-status messages, add the value of orders refunded because customers lost confidence, and compare that annual figure with the build cost.

What changes for Nigerian stores

Customers track by WhatsApp, not by bookmarking a page. The dispatch message is the tracking system for most buyers. Make that single message excellent: status, expected date, item, link.

Addresses cause the visible failures. Showing the delivery address prominently on the tracking page catches errors while they are still cheap to fix.

Courier data quality varies. Some partners provide clean webhooks, others provide a portal and a phone number. Design the system so a manual status update is always possible without breaking the event log.

Interstate expectations differ. For deliveries outside your city, customers often expect park-to-park or terminal collection. Your status wording should support "ready for collection at terminal", not only "out for delivery".

Network interruptions affect staff too. Admin updates should queue and retry rather than silently failing when a browser loses connection mid-update.

Festive delays are predictable. Publish revised lead times on the tracking page during peak periods so the system tells the story before customers ask.

Example (hypothetical): an electronics store in Ibadan

Example (hypothetical): an Ibadan electronics store handling about 40 orders a day sold through its website, Instagram and WhatsApp, and its two-person support desk spent most of the morning answering order-status questions.

What was built, in order:

• A twelve-state internal model collapsed into five customer-facing states.
• An event log on every order, recording who changed what and when.
• A guest tracking page reachable by order number and phone number, linked in every message.
• Automated WhatsApp messages on confirmation, dispatch and delivery, with SMS fallback.
• A courier status feed mapped into the internal model, plus manual override for the second courier that had no API.
• An internal alert when an order stays in "being prepared" for more than 24 hours.

The most useful piece turned out to be the stuck-order alert: it surfaced items that had been sold but were not actually in stock, which was the underlying cause of most late deliveries. The tracking system did not just inform customers, it exposed an inventory problem.

Mistakes to avoid

• Overwriting the status instead of logging events. You lose the history you need for disputes and for measuring delays.
• Requiring an account to track an order. Guest checkout plus login-only tracking is a guaranteed support queue.
• Exposing raw courier status codes. Customers should never read internal vocabulary.
• Promising delivery times you cannot control. Give a date range and update it when it changes.
• Sending notifications for every internal step. Customers mute noisy senders and then miss the important message.
• No alert for stuck orders. Silent failures become complaints and refunds.
• Ignoring the failed-attempt path. A failed delivery needs a phone call and a reschedule option, not a status change nobody reads.
• Forgetting the refund status. "Refund processed" is one of the highest-value messages you will ever send.

Launch checklist and what to measure

• Status model documented with allowed transitions and customer wording
• Event log storing timestamp, actor and note for every change
• Tracking page accessible without a login and tested on mobile data
• Dispatch message includes order number, expected date and tracking link
• Payment webhooks verified and idempotent
• Courier statuses mapped, with manual override available
• Failed delivery triggers a human follow-up task
• Stuck-order alerts configured with sensible thresholds
• Opt-out honoured and privacy notice updated
• Support team trained to answer from the event log

Metrics worth reviewing weekly: order-status enquiries per 100 orders, average time in each status, percentage of orders delivered within the promised window, failed delivery rate by reason code, and refunds attributed to delivery delay.

Conclusion

Order tracking is mostly a data discipline problem. Define a status model your customers understand, record every change as an event, automate updates from payments and couriers, expose a tracking page that needs no login, and send a small number of well-timed messages on the channels Nigerian customers actually use. Do that and the support queue shrinks while your operations data becomes good enough to fix the delays behind the questions.

If your team is answering order-status messages all day, Linestech builds order management and tracking systems for Nigerian online stores, including WhatsApp and SMS notifications and courier status integration.

Frequently asked questions

What is the difference between order tracking and courier tracking?

Courier tracking covers only the delivery leg, from pickup to doorstep. Order tracking covers the whole journey, including payment confirmation, stock checks, packing and returns. Customers judge you on the full journey, including the days before the courier ever received the parcel.

Can I build order tracking without integrating a courier API?

Yes. Start with your own statuses updated by staff and payment webhooks, and paste the courier's waybill number into the order so customers can follow the delivery leg on the courier's site. Add API integration when order volume makes manual updates unreliable.

How many notifications should a customer receive?

Usually four to six per order: confirmation, a progress note if preparation takes more than a day, dispatch with the tracking link, out for delivery, delivered, and a refund message if applicable. Anything beyond that risks being muted.

Should the tracking page show the courier's name?

Yes for most stores, because it helps customers who want to call or check the courier directly. The exception is when you want to change couriers frequently without customer confusion; even then, show the waybill number so disputes can be resolved.

How do I handle orders placed on WhatsApp or Instagram?

Create them in the same order system rather than leaving them in chat. Give them the same order number format, statuses and tracking link. If they live only in a chat thread, you lose reporting, reconciliation and the ability to answer questions later.

What should happen when a delivery fails?

Log a reason code, notify the customer immediately through a channel that invites a reply, create a task for a human to call, and offer a reschedule or a pickup option. The failure should also feed a report so recurring causes, such as incomplete addresses, get fixed at checkout.

Does an order tracking system reduce refunds?

It reduces refunds caused by uncertainty, which are a meaningful share of them. Customers who can see accurate progress are more willing to wait through a delay. It will not fix refunds caused by wrong items, damage or genuinely late delivery.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Act 2023 — NDPC
• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers
• Baymard Institute e-commerce UX research