Developing a delivery tracking bot for a mobile app

Why the delivery tracking bot breaks during order peaks

While there are dozens of orders, the delivery tracking bot works unnoticed: the courier service sends an event, the app changes the status, the client receives a notification.

At peak — season, sale, mass shipping — the flow of events grows many times over, and the first to break are not the screens but the connections between systems: some updates do not arrive, some arrive again, some get stuck in the queue and surface hours later.

The first failure is status desynchronization. The delivery service provides updates asynchronously, while order statuses in the app are assembled from several sources: warehouse, courier, pickup point.

If events are applied in the wrong order — "delivered" arrives before "handed to courier" — an intermediate state remains in the order card. The client sees "in transit" where the parcel is already waiting at the pickup point and contacts support.

The second is duplicate delivery notifications. When a failure occurs, the receiver responds with an error, the service resends, and without a unique event identifier the same update is processed twice: two notifications in a row for one order.

The third is stuck orders: an event is lost, the order remains in active forever, and only an operator can manually move it to a final status.

The higher the peak, the more noticeable the share of such orders and the more the flow of inquiries grows — support spends time not on clients but on reconciling data between the service panel and the app.

We break down how this is closed: idempotent event processing, scheduled reconciliation as insurance against losses, and explicit rules for transitions between statuses.

What changes after embedding tracking into the app

While delivery status lives in the carrier's portal, the app remains a storefront: the client learns about a delay last — from an email or after calling support.

Embedded tracking makes a status change an event inside the app, and the effect stops being "it became more convenient" — it is measured by metrics before and after launch.

• Share of automatic statuses. Webhooks and periodic polling instead of manual entry: 92–97% of "created — in transit — with courier — delivered" transitions arrive without an operator.
• Response time to a deviation. "Delay" or "could not reach" events reach the operator queue in 30–60 seconds, not hours after the client's call — a return can still be prevented.
• Support load. "Where is my parcel" inquiries are closed by the order screen with the tracking number and status, their share drops 2–3 times, and the shift switches to returns and claims.
• Delivery time. A reminder about arrival at the pickup point and one day before the courier's visit reduces the number of failed delivery attempts — the time to the client is shortened by 8–15%.
• Notification scenarios. Channel and template for each transition: in-app notification for a status change, email for refusal, quiet hours, duplicate suppression; texts are edited by configuration, without a release.
• Eliminated class of failures. A failure of the carrier's interface no longer causes status loss: events are queued and retried with increasing delay, discrepancies are reconciled with CDEK by tracking number.

We take metrics before the start of work and again a month after launch — from the event export, not from feelings.

Methods of notifying about order statuses: comparison of approaches

The choice of notification method determines where the user learns the order status: in the app, in a messenger, or in a message from the courier service.

In practice, channels are combined: in-app notifications cover the main scenarios, a messenger bot provides a fallback for those who deleted the app, and integration with courier services provides data we do not have — the waybill number, the fact of handover to the courier, and delivery.

The limitations of services are more important than their capabilities: each channel dictates its own rules for message templates, sending frequency, and phone number confirmation — for example, CDEK provides events only for its own shipments and in its own format. Below are the options that are actually chosen between when launching a delivery tracking bot.

Stages of embedding tracking: from audit to handover

Tracking breaks not on the map but on the coordination of statuses between the warehouse, courier, and delivery service. The user sees "in transit" for the third day, support answers the same thing, and the notification arrives after the courier has left. We structure the work so that discrepancies surface on staging, not in reviews.

1. Status audit. We collect the systems that know about the order: accounting, warehouse, delivery service, courier app. We bring their state codes into one mapping table — it immediately shows which statuses arrive with a delay and which do not arrive at all.
2. Data flow diagram. We determine how an event reaches the phone: polling an external service, an incoming signal, or an intermediate storage. The diagram marks where an event is lost during a connection break and how often to poll the source.
3. Notification rules. We agree on which statuses the bot reports immediately, which accumulate in the order feed, and which we do not show at all. One event — one message, even if it came from two sources.
4. Testing on real orders. We run real and test orders: whether the status matched, whether the notification arrived on time, what a person sees on cancellation and return. Separately — network loss and the app in the background.
5. Project handover. We hand over the status table, flow diagram, notification rules, and instructions for connecting a new carrier. We walk through it on a live order so that an edit can be made without us.

Each stage ends with an artifact: a table, a diagram, or a run on data. At acceptance, it is visible not "it works" but exactly what was checked.

Configurations, diagrams, and policies: what the team keeps

After launching the delivery tracking bot, the team should have artifacts left, not verbal agreements.

Everything related to sending notifications, data exchange with delivery services, and access to client orders is recorded in writing — this is enough to develop the product on your own or hand it over to another team without losing context.

• Notification service settings — message templates for each status, channel order, quiet hours, and behavior when external mailing is unavailable.
• Integration diagrams — a map of exchange between the app, bot, and delivery services: where we request statuses, where we receive incoming notifications, how shipment numbers are matched.
• Access policies — roles in the management panel, rights for manual sending and retry, key rotation procedure.
• Failure handling policy — what to do if a status did not arrive, was duplicated, or was late; who handles the inquiry and within what time frame.
• Event logs and metrics — share of delivered notifications, delay between a status change and the message, list of unresolved conflicts.
• Documentation — description of scenarios, support instructions, procedure for releasing and rolling back a bot version.

We update artifacts with every change and store them next to the code, not in chat. The check is simple: your engineer or a new team uses these materials to assemble a version and handle a typical failure without questions to us.

Case: delivery tracking relieved the support service

The client is the delivery network «Severny Marshrut» with its own fleet of couriers. In the app, the client saw one line "in transit" until delivery itself: a change of courier, a rescheduled window, and a repeat visit were not reflected anywhere.

The load fell on support — inquiries about order status accounted for about 40% of the incoming flow.

What we did

The delivery tracking bot was connected directly to the events of the accounting system: each shipment state turns into an event with an identifier, type, and timestamp.

Then the notification matrix works — which events go to the client, with what delay and through which channel, with duplicate suppression and fallback to a reserve channel if delivery fails.

The app reads the status from the same event stream, so the screen and the notification do not contradict each other.

Two months later, support stopped being the only source of truth about the order: the client learns about a deviation before opening the chat. The freed-up operator resource went to complex cases — damage, address disputes, returns.

How does delivery tracking in an app differ from an external service?

An external service provides a ready-made status line and removes carrier integration from you, but events go through someone else's node. You see what the service considered necessary to pass on, in its format and with its delay.

Your own delivery tracking is built on direct exchange with carriers' software interfaces — from order acceptance to delivery.

The speed of status updates depends on the method of receiving events. An external service more often polls carriers on a schedule, so there is a noticeable pause between the actual scan and the display of the status in the app.

Your own environment receives events at the moment they are sent, and repeated triggers are suppressed by key — the status does not jump back or duplicate in the order history.

Control over data is the second difference.

Your own status history is stored with you: it can be rebuilt when the order model changes, exported for analyzing delivery times, multiple carriers combined into one scale, and you do not depend on how long the service stores the archive and what it calls the stages.

Flexibility of notification scenarios appears where the triggers are described by you.

The "two stops left" threshold, quiet hours by the recipient's time zone, different texts for the courier and the client, escalation for a stuck status — these are rules on your side, not a set of ready-made checkboxes. Notifications from the delivery tracking bot in this case also live in your environment.

The cost of ownership shifts: an external service saves on launch but adds a permanent dependency — its failure or change of terms becomes your downtime. Your own tracking requires work at the input, but expenses are predictable, and improvements are released at your pace.

Technical questions: reliability, access, failures, and metrics

Engineering doubts around a delivery tracking bot are usually the same: delivery service unavailability, rights to order data, testing scenarios before production release, and responsibility boundaries after handover. Below are the answers in the form needed for a technical decision.

We record them in the documentation before the start: status flow diagram, access matrix, set of checks, handover policy. Then notification reliability and responsibility are not a matter of verbal agreements.

What rights does the bot need for order data?

We read only the fields needed for status: order number, current stage, planned date, recipient contact. Access is via a service account with a short key lifetime, personal data is masked in logs.

How is tracking tested before real orders appear?

The sandbox substitutes delivery service responses: we run rare branches — cancellation after assembly, return, partial delivery, long delay. Each scenario is a separate check, branch coverage goes into the report.

What changes after project handover?

We hand over configurations, integration diagrams, tests, and instructions for typical failures; support continues in an agreed mode. Responsibility for the bot logic and working checks is fixed in writing.

Let's discuss the task: we will review your statuses and scenarios

So that the estimate of work is based on your reality, not on average assumptions, we need inputs for the project: how the order path is currently structured and where the delivery tracking bot should fit into it. With the minimum set below, we will return with an implementation plan and timelines by stage.

• The list of delivery statuses as the client sees them, and transition rules: where "in transit" ends, what "at the pickup point" means, what is considered a cancellation or return.
• The event source — accounting system, warehouse, or delivery service — and whether it has a software interface for reading, or statuses are entered manually by people.
• Notification channels: messenger messages, push notifications in the app, email; whether duplication is needed and whether the recipient can disable mailing.
• Roles and scenarios: who receives messages and whether response actions are needed — rescheduling a date, confirming an address, contacting the courier.
• Volumes: how many orders per day on average and at peak, how many notifications are per order — this determines the queue scheme and protection against duplicates during failures.
• Ready-made message templates and presentation requirements: language, tone, localization, substitution of recipient data.
• Access to the test environment and test records — without them, an end-to-end scenario cannot be checked.

Describe the task in free form, even if some inputs have not yet been collected: we will clarify the missing parts with questions. We will return with a work estimate and an implementation plan showing the stages, dependencies, and acceptance points.