In the UAE, if your customer wants to know where their order is, they do not log into a portal and they do not check their email. They open WhatsApp and they type a message to whoever they last spoke to.
That is not a habit you are going to change, so the practical question is whether those messages have to be answered by a person one at a time.
The shape of the problem
A delivery business in Dubai moves a few hundred jobs a day. Each one has a customer who would like to know three things: that it was collected, that it is on its way, and that it arrived.
Nobody sends those updates, because nobody has time. So instead the customer asks. The messages land on a shared phone, or worse, on a driver’s personal phone, and someone switches to the operations system, looks up the job, switches back and types a reply.
Each answer takes a minute or two. The volume is the problem, not the difficulty. And the information the customer wanted was sitting in the system the whole time.
What gets automated, and what does not
The automation is simple to describe. When a job’s status changes in your system, a message goes out. Collected. Out for delivery. Delivered, with the time.
That is it. One trigger, one message, no cleverness.
What we do not automate is anything that commits you to something. A message that says “your delivery will arrive by 4pm” is a promise, and a promise generated by a rule will eventually be wrong in front of a customer who screenshots it. Status updates describe what has happened. Predictions and commitments stay with a person who can see the day’s actual situation.
The same line applies to complaints. An automated reply to an angry customer is worse than silence. Route it to a human and do it fast.
The part nobody mentions until you have paid for it
You cannot do this properly from a normal WhatsApp account. Business messaging at any volume runs through the WhatsApp Business Platform, and that brings rules that change what is possible.
Outside a 24 hour window you can only send approved templates. If a customer has not messaged you in the last 24 hours, you cannot send them free text. You send a template that Meta has approved in advance, with variables slotted in. This is the single biggest constraint and it shapes everything else.
Templates take approval time and get rejected. Anything that reads as marketing when you said it was a utility message will come back. Write them plainly and submit them early, because discovering this during go live week is painful.
Messages are charged per conversation. The pricing is not large per message, but it is not zero, and a business sending three updates per job at a few hundred jobs a day should put a real number on it before building. Occasionally the arithmetic says to send two updates rather than three.
Opt in is required, and it is also just correct. You need the customer’s agreement to message them. Capture it at the point of order, store when and how it was given, and give them a way to stop.
None of this is a reason not to do it. It is a reason to design around it from the start rather than discovering it halfway through.
How it connects
The chain is short. A status changes in your operations system or ERP. That change fires a webhook. An orchestration step decides whether this status deserves a message, picks the right template and the right language, and sends it. The send result is written back against the job, so you can see what the customer was told and when.
That write back matters more than it sounds. Without it, the first time a customer says “nobody told me anything”, you have no way to check whether they are right.
Language selection is worth building in on day one in this market. English and Arabic at minimum, often Hindi or Urdu as well, chosen from the customer record rather than guessed.
Where it goes wrong
Status changes that are not real. If your team marks jobs as delivered in a batch at the end of the day, automating messages off that status sends a pile of “delivered” notices at 7pm for parcels that arrived at 11am. The automation exposed a data habit rather than creating a problem, but the customer does not care about that distinction. Fix the habit first.
Too many messages. Three updates on a one day delivery is useful. Seven is noise, and noise gets you blocked, which costs you the channel entirely.
No route back to a person. If the customer replies to an automated message and nothing happens, you have made things worse than before. Every automated conversation needs a visible, fast way to reach somebody.
Beyond deliveries
The same pattern fits anything with a status a customer cares about. A tailoring order moving through fitting, cutting and finishing. A service job scheduled, attended and completed. An invoice issued, due and settled.
Payment reminders are a particularly good fit, because they are repetitive, mildly awkward for a person to send, and much more effective on WhatsApp than by email in this market. The same care applies: state the fact, name the amount and the due date, and leave the negotiating to a person.
Is it worth it
Count the “where is my order” messages you answered last week. If answering them is a real part of somebody’s day, the automation pays for itself quickly, and the second benefit is usually larger than the first: the team stops being interrupted, and interruptions cost more than the minutes they consume.
If you handle a handful of jobs a day and you know every customer by name, leave it alone. A personal message from a person is better than anything we would build, and we would rather tell you that than take the project. More on how we decide what is worth automating.
Common questions
Can we send WhatsApp messages from our normal business number?
Not at volume, and not reliably. Automated sending from a standard account risks the number being restricted, which takes away the channel your customers actually use. The Business Platform exists for this and is worth the setup.
How long does approval take?
Business verification and template approval are measured in days rather than hours, and templates do get rejected and resubmitted. Start that process at the beginning of the project rather than at the end.
Can the automation answer questions as well as send updates?
It can, and you should be careful about where you draw the line. Answering “what is my order status” from live data is safe, because there is one correct answer. Answering “can you deliver to Fujairah tomorrow” is a commitment, and that belongs to a person.
What about customers who do not use WhatsApp?
Keep a second channel. SMS for the same status events is cheap to add once the logic exists, since only the sending step changes.
Does this need a new system?
No, but it needs your existing one to have real statuses that change at the real time. If the status is updated in a batch at the end of the day, fix that first, because the automation will simply broadcast the inaccuracy.