Order tracking bots and privacy: who should see what
An order-status bot must never accept an order number as proof of identity, because numbers run in sequence and can be guessed. Show orders only to the phone number or email they were placed with, or to someone who supplies the order number together with that matching email or phone.
- Sequential order numbers make brute-force browsing trivial if the bot trusts them.
- An address and a tracking link are personal data under India's DPDP Act.
- Channel identity (a WhatsApp number) is strong proof; a typed order number is not.
- Log what was shown and to whom, so you can answer questions later.
The mistake that looks like good service
The natural way to build an order bot is to let the customer type an order number and show what comes back. It feels helpful and it demos beautifully.
It is also a data leak. Shopify order numbers increment: #1001, #1002, #1003. Anyone who buys once from you learns the format and the neighbourhood of current numbers. Twenty minutes of typing will return other people's items, delivery addresses, phone numbers and live tracking links.
Nobody has to hack anything. The bot simply answers the question it was asked.
It is worth being precise about the harm, because "data leak" sounds abstract. What leaks is a name, a full delivery address, a phone number, a list of purchases and a live tracking link. That is enough to intercept a parcel, to impersonate your brand convincingly in a follow-up call, or simply to know when a house is receiving deliveries.
The people most exposed are the ones you least want exposed: customers who bought something private, and customers with a reason to keep an address quiet.
What counts as proof, and what does not
| Signal | Strength | Why |
|---|---|---|
| WhatsApp number the customer is writing from | Strong | Controlled by the person, verified by WhatsApp, hard to fake casually |
| Email address on a signed-in account | Strong | Authenticated by your store |
| Order number typed into a chat | Weak | Sequential and guessable |
| Customer name | Weak | Often public, frequently shared |
| Order number plus matching email or phone | Adequate | Two independent facts; this is what order-status pages use |
The practical rule: one strong signal, or two weak ones that have to agree.
Beware of signals that feel strong but are not. An email address typed into a chat proves nothing, because anyone can type anyone's email. It becomes proof only when it has to agree with something else, which is why the order-number-plus-email combination works and either half alone does not.
The same goes for a customer's name and the last four digits of a phone number. Both are widely known, and both are commonly used by support teams as verification. They are better than nothing and a long way short of adequate.
How Convo360 handles it
Convo360 applies exactly that rule. When a customer writes from a phone number or email that matches an order, their recent orders are shown straight away. When they give only an order number, the bot refuses and asks for the email or phone used at checkout, then checks the two against each other before showing anything.
A website visitor with only a random session identity is never looked up at all, because a session id proves nothing about who the person is. They are asked for both pieces before the bot goes near the store.
None of this is configurable, which is deliberate. A privacy control that can be switched off for convenience eventually will be.
Web chat deserves a specific mention. A visitor to your site is identified by a session id that the widget generates, which says nothing about who they are. Convo360 never looks up an order against a session id, and it also makes those ids long and random rather than derived from the clock, since a guessable session id would let one visitor read another's transcript.
What the DPDP Act expects of you
India's Digital Personal Data Protection Act treats a delivery address, a phone number and an order history as personal data you hold as a fiduciary. Two obligations matter for a bot.
- Purpose limitation. You collected the address to deliver a parcel, not to show it to whoever asks. Disclosing it to the wrong person is a breach regardless of intent.
- Reasonable safeguards. "The bot answered what it was asked" is not a safeguard. A documented identity check is.
Keep a record of what was shown and to which conversation. Convo360 logs lookups, so if a customer ever asks who saw their order, there is an answer. See the compliance docs for what is retained.
Retention is the other half of the obligation. The DPDP Act expects you to keep personal data no longer than the purpose requires, which means a chat transcript full of addresses should not sit in your inbox forever by default. Decide a retention period, write it into your privacy notice, and make sure the platform can honour it.
If you use a third-party AI provider with your own key, say so in your privacy notice as well. Customers are entitled to know that the message they sent was processed by a model, and which company operates it.
Testing your own bot in ten minutes
Whatever platform you use, run these four checks before going live:
- From a phone number that has never ordered, type a plausible order number. The bot must refuse.
- Give a real order number with the wrong email. It must refuse.
- Give a real order number with the right email. It should answer.
- Ask it to list recent orders for a name rather than a number. It must refuse.
If any of the first, second or fourth returns real data, stop and fix it before the next customer finds it by accident. This is a ten-minute test that has saved brands a very uncomfortable conversation.
Run the same four tests after any change to your bot's prompt. Language models are steerable, and a prompt edit meant to make replies friendlier can quietly make the model more willing to be helpful about things it should refuse. The checks take ten minutes and they are the only way to know the guard is still there.
If you are buying rather than building, ask the vendor to demonstrate the refusal live rather than describing it. A platform that cannot show you a refusal on request has probably not implemented one.
Example conversation
Build an order bot that cannot leak
Start free in minutes — no code, no credit card. Bring your own AI keys and pay no per-message markup.
Frequently asked questions
Is an order number really enough to find other orders?
Usually yes. Most stores number orders sequentially from a single counter, so one genuine order number reveals the range in use. A bot that trusts numbers alone can be walked through hundreds of them.
What about a one-time password instead?
An OTP to the phone on the order is the strongest option and worth it for anything beyond status, such as changing an address. For read-only status it usually adds friction customers will not accept.
Does this apply to website chat as well as WhatsApp?
Especially to website chat. A visitor there is anonymous, so there is no strong signal at all until they provide one. Always require the order number and the matching email before showing anything.
Can I show partial information without a check?
Being vague is safer but still leaks. Confirming that order #1002 exists and shipped on Tuesday tells a stranger more than it should. Refuse politely rather than answering partially.
Who is responsible if a bot leaks an address?
You are. Under the DPDP Act the business collecting the data is the fiduciary, and the platform is a processor acting on your instructions. Choosing a tool with the check built in is part of meeting that duty.
Related reading
Available across India — see WhatsApp & AI calling automation by state and city.