WhatsApp & SMS Alerts for Operations
In Kenya an alert that is not on WhatsApp or SMS has not arrived. Both work, both need your own credentials, and WhatsApp has one rule about approved templates that catches everybody. Three SMS providers, one active sender, and the honest limit: these are notification channels, not conversation channels.
Email notifications in a Kenyan SME are a filing system. The storekeeper does not have an email habit, the supervisor reads mail twice a day, and an approval that waits for someone to open Outlook waits until tomorrow. Anything that needs to be acted on within the hour has to arrive on WhatsApp or as an SMS, and any vendor who has not noticed this has not worked in this market.
Both are supported, both run on your own credentials, and both have specifics worth knowing before you promise anyone that alerts will work.
WhatsApp, and the template rule
WhatsApp works through the Meta Cloud API with your own access token and phone number identifier. The rule that catches every first-time implementation is not ours and cannot be worked around: a business-initiated WhatsApp message must use a template that Meta has approved. You cannot send arbitrary text to someone who has not messaged you first.
So the notification text is injected into an approved template as a parameter. Practically, that means one approved template with a single body parameter covers every alert you will ever send, and getting that template approved is a prerequisite rather than a nice-to-have. Until it exists, the connection tests successfully against Meta's built-in greeting template and sends nothing useful.
The WhatsApp setup order
- Get a WhatsApp Business account and a phone number identifier from Meta. This is the slow part and it is nothing to do with us.
- Create and submit one template with a single body parameter — something like "AWRA OpsHub alert: {{1}}". Generic is deliberate; a template per alert type is a template per approval cycle.
- Wait for approval. Plan for days, not hours.
- Paste the access token, phone number identifier and the approved template name and language.
- Add recipients in international format, and test to your own number first.
- Then decide which alerts route here. Restraint matters more than configuration — see below.
Message length is capped
Alert text is trimmed to fit within what a template parameter will carry. Design your alerts to be short and to contain a link rather than a report — "PO-1042 needs approval" plus a link beats a paragraph that gets cut mid-sentence.
SMS: three providers, one sender
Africa's Talking, Twilio and Infobip are all supported and each takes your own credentials. All three can be connected simultaneously; one is the active sender at any time. That is a more useful design than it sounds — it means switching provider after a bad month of deliverability is a setting rather than a project.
When SMS is the right channel
- The recipient is a customer, a supplier or a casual worker rather than a member of staff with a login.
- The message must arrive on a feature phone.
- You need delivery on the worst connection in your network — SMS degrades better than anything else.
- Statutory or contractual notice where you want a record of sending.
When it is the wrong one
- High-volume operational alerts. You are paying per message and people stop reading at about four a day.
- Anything with detail. A stock report does not fit and a truncated one is worse than none.
- Anything needing a reply. SMS here is outbound only.
- Internal team coordination — a chat channel is free and threaded.
The discipline that decides whether any of this works
The technical setup is an afternoon. What determines whether alerts are useful is a decision nobody wants to make: how few of them there should be.
What happens at each alert volume, per person, per day
The failure mode is silent and irreversible, which is what makes it dangerous. Somebody mutes a WhatsApp group in March, and in July an approval sits for four days and everyone concludes the workflow engine is broken. Route by role rather than to everyone, and put anything informational in a report somebody opens rather than a message somebody receives.
What these channels are not
What AWRA OpsHub does today
- WhatsApp through the Meta Cloud API with your own token, phone number id and approved template.
- SMS through Africa's Talking, Twilio or Infobip — all three connectable, one active sender, your own credentials.
- A platform SMS fallback if you have not connected a provider of your own.
- Failures that fail soft — a message that cannot be delivered does not break the operation that triggered it.
- Per-category routing, so you choose which kinds of event go to which channel.
More we can add to your workspace
- An inbound path — these are outbound only today. Inbound message handling, a conversation view, and a ticket created from a customer's WhatsApp message are what a reply would need somewhere to land.
- A WhatsApp as a helpdesk channel. If your customers support themselves over WhatsApp today, that is not something this replaces.
- A delivery-report dashboard aggregating what was sent and what landed.
- Per-recipient quiet hours or throttling, so restraint is configuration on your side rather than a limit on ours.
The outbound-only point is the one that surprises people, because a WhatsApp notification looks like a conversation. Tell your team explicitly that replies are not read — otherwise somebody will answer an alert helpfully and assume it was received.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsChoosing between the two, and email
Which channel for which message
Approvals, blocked payments, a delivery refused at the door. Free per message and read fastest.
SMS
The same urgency to someone without a smartphone or a login. Costs money per message, which is a useful natural limit.
Chat channel
Team-level operational awareness. Threaded, free, and nobody has to be individually addressed.
Anything with detail or an attachment, and anything that needs to be findable in six months.
A report somebody opens
Everything informational. If nobody must act today, it is not an alert — and routing it as one is how alerts die.
Our take
Get one generic WhatsApp template approved before you need it, connect an SMS provider of your own so deliverability is your relationship rather than ours, and then spend your effort on restraint — one must-act alert per person per day. Both channels are outbound only, so tell your team that replies are not read before somebody discovers it the expensive way.
Alerts where people actually look
WhatsApp through the Cloud API and SMS through Africa's Talking, Twilio or Infobip — your own credentials, per-category routing, and failures that never break the operation that triggered them.
See plans & pricingFrequently asked questions
Can the system send WhatsApp notifications?
Yes, through the Meta WhatsApp Cloud API with your own access token and phone number identifier. The rule to plan around is Meta's, not ours: a business-initiated message must use a template Meta has approved, so the alert text is injected into an approved template as a parameter. One generic template with a single body parameter covers every alert you will send.
Can customers reply to a WhatsApp alert?
No. WhatsApp and SMS here are outbound only — a reply goes nowhere, there is no inbound message handling, no conversation view and no ticket created from a customer message. Tell your team explicitly, because a WhatsApp notification looks like a conversation and somebody will eventually answer one helpfully and assume it was received.
Which SMS providers are supported?
Africa's Talking, Twilio and Infobip, each with your own credentials. All three can be connected at once with one active sender, which makes switching provider after a bad month of deliverability a setting rather than a project. There is also a platform fallback if you have not connected a provider of your own.
How many alerts should one person receive?
One a day that they must act on. Between four and eight they are skimmed; above about nine they get muted in the phone's own settings, permanently, and nobody tells you. That failure is silent and effectively irreversible — somebody mutes a group in March and in July an approval sits for four days and everyone blames the workflow engine.
Can we use WhatsApp as a support channel for customers?
No. There is no inbound WhatsApp handling and no WhatsApp ticket channel, so if your customers currently support themselves over WhatsApp, this does not replace that. Outbound notification to a customer works; a conversation does not.
How long can an alert message be?
Short. Text is trimmed to fit what a WhatsApp template parameter carries, and SMS has its own limits. Design alerts as a subject and a link rather than a summary — "PO-1042 needs approval" with a link beats a paragraph that gets cut mid-sentence, and it also loads faster on a bad connection.
