Bot type
The bot that answers "where is my order" so your dispatcher does not
A Telegram delivery tracking bot pushes status changes to the customer as the driver updates them, and gives drivers a one-tap way to record pickup, transit and delivery. It removes inbound status calls. It does not improve your actual delivery times, and it will expose them.
Delivery tracking bots: price, timeline and limits
- Fixed price
- $4,200 USD
- Delivery
- 21 calendar days from kickoff
- Live location
- User-initiated, 8 hours maximum
- Broadcast ceiling
- ~30 messages/second bot-wide
- File transfer
- Send up to 50 MB, download up to 20 MB
- Delivery order
- Not guaranteed for messages sent in rapid succession
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Dispatch teams in the Gulf spend a startling proportion of their day on a question that carries no information: where is my order. The customer is not being difficult. They have no visibility, the delivery window they were given was three hours wide, and asking is the only lever they have. Every one of those calls interrupts someone who was routing the next drop.
The instinct is to buy a tracking platform, and for a fleet of two hundred vehicles that is right. Below that, the platforms cost more than the problem and require drivers to adopt an app they resent. What most operations actually need is narrower: the customer knowing, unprompted, when something changed, and the driver being able to record that change in under three seconds while double-parked.
There is a caveat worth stating before anyone builds this. Tracking makes your delivery performance legible. If your two-hour window is really four hours, customers currently suspect it and will shortly be able to prove it. Operators who install tracking without fixing the underlying scheduling usually see complaints rise before they fall. That is the system working, but it is not what was expected.
How the build runs
The consignment enters from whatever system already creates it
Your order system, spreadsheet, or ERP posts the consignment with the customer contact and the address. The bot does not want to become your order system; it wants to be told when one exists.
webhookThe customer opts in with a single tap
A link in the confirmation message opens the bot and subscribes them to that consignment. A bot cannot message someone who has never contacted it, so this step is not optional and cannot be skipped by importing numbers.
deep-linkThe driver sees only the next action
Drivers get a list of assigned jobs and, for each, one button that advances it. Not a form, not a dropdown, not a required note. Anything more elaborate is filled in wrongly at speed or not at all.
inline-keyboardEach state change pushes to the customer immediately
Picked up, out for delivery, arriving, delivered. The customer never polls and never asks. This is the whole return on the build, and it works only if the driver flow is fast enough that drivers actually use it.
broadcastA failed delivery is captured with its reason at the door
Nobody home, refused, wrong address, access denied. Recorded in the moment rather than reconstructed at the depot that evening, which is the difference between data you can act on and a shrug.
inline-keyboardProof of delivery attaches to the consignment
A photo at the door or a typed recipient name. Telegram accepts uploads up to 50 MB from a bot, so a phone photo is never a problem, and the file is stored against the job for dispute handling.
file-transfer
What Telegram will and will not let you do
A bot cannot initiate a conversation with a user who has not messaged it first.
Every customer must tap a link once before any status update can reach them. Uploading a customer list and messaging it is not possible, and any proposal that assumes it is describes a ban.
Live location sharing in Telegram is user-initiated and lasts at most 8 hours.
Continuous vehicle tracking is not something a bot can switch on. Drivers share live location per shift if you want it, and a driver who forgets produces a gap you cannot backfill.
A bot may send roughly 30 messages per second in total.
A depot pushing five hundred "out for delivery" notifications at 08:00 spreads them over about twenty seconds. Fine in practice, but it means the notification time is approximate.
Bots can send files up to 50 MB and download files up to 20 MB.
Phone photos for proof of delivery are comfortably inside the receive limit. Video proof usually is not, and asking drivers for video is a false economy anyway.
Telegram does not guarantee delivery order for messages sent in rapid succession.
Two status changes within the same second can arrive out of order. Each message carries its own state and timestamp rather than reading as an increment, so an out-of-order pair still makes sense.
When not to build this
- You already run a proper TMS with a customer portal. A second tracking surface fed from the same data adds a synchronisation problem and no new information.
- Your drivers are subcontracted and will not adopt anything. Tracking accuracy is entirely a function of driver compliance, and a bot cannot manufacture it.
- Your delivery performance is genuinely poor and unaddressed. Making it visible without fixing it converts private dissatisfaction into documented complaints.
- You deliver fewer than about thirty consignments a day. The dispatcher time saved does not justify the build, and a group chat will cover it.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with separate driver and customer conversation trees. |
| Cloudflare Workers | current | Runtime. Status pushes are bursty and this scales to them without provisioning. |
| Cloudflare D1 | current | Consignments, state transitions and the subscriber map. |
| Cloudflare R2 | current | Proof-of-delivery images, kept out of the database. |
| TypeScript | 5.9 | Strict mode. State machines are exactly where types pay for themselves. |
Questions people ask before committing
Can it track the vehicle continuously on a map?
Not in the way a fitted telematics unit does. Telegram live location is user-initiated and capped at eight hours, so it depends on the driver starting it each shift. If continuous tracking is the requirement, a hardware tracker feeding the bot is the honest answer.
How do customers end up subscribed to their consignment?
They tap a link, usually in the SMS or email confirmation you already send. There is no way around this — Telegram does not allow a bot to message someone first, and that rule is enforced rather than advisory.
Will drivers actually use it?
Only if each update is one tap and the list shows the next job without scrolling. That is the design constraint the whole driver side is built around. Where operators add mandatory notes or photos on every stop, compliance drops within a fortnight.
Can it feed our existing order system rather than replace it?
That is the intended shape. Your system remains the source of truth for what exists; the bot owns where it currently is and who was told. Consignments arrive by webhook and status flows back the same way.
What happens if a driver has no signal at the door?
The update queues on the device and sends when signal returns, so the sequence survives a basement car park. The customer sees the change late rather than never, and the timestamp recorded is the moment the driver tapped.
Is proof of delivery admissible for a dispute?
It is evidence, not a legal instrument. A timestamped photo with the consignment id and the driver identity resolves the overwhelming majority of "it never arrived" disputes, which is the practical bar.
How many languages can the driver interface run in?
As many as you need, and in most GCC fleets three is the realistic minimum. Language is per driver rather than per fleet, so the same job list renders differently for different people without any duplication.