The Channel That Can Only Talk
This product can send a WhatsApp message and cannot receive one. For a market where WhatsApp is how customers actually reach a business, that is not a missing integration — it is an integration pointed the wrong way.
A support channel is two directions. Almost every conversation about integrations is about the first one, because sending is the half that is easy to build and easy to demonstrate.
Our own internal notes recorded this product as having no WhatsApp integration at all. That was wrong, and the way it was wrong is the interesting part: there is one, it works, and it only goes outwards.
What exists
A tenant configures their own WhatsApp business account, and notifications can be forwarded to it. Workflow rules can send to it. There is a connection test. It goes through the official cloud interface rather than an unofficial bridge, which matters for anything you intend to rely on.
There is one constraint inherited from the platform and it shapes everything: a business cannot start a WhatsApp conversation with free text. It must use a pre-approved template. Ours has a single slot, and the notification text is injected into it.
So the outbound channel is not a conversation. It is a notification pipe with one variable in it.
What does not exist
Anything inbound. There is no webhook route, no verification endpoint, no message handler, and nothing anywhere that turns a received message into a ticket.
A customer who replies to one of those notifications is replying into nothing. The message arrives at the business account and no part of this product ever sees it.
The two halves of one channel
Outbound
Built
- Official cloud interface
- Tenant's own business account
- Workflow rules can send
- Notifications can be forwarded
- Template-gated — one variable, not free text
Inbound
Absent
- No webhook route
- No verification endpoint
- No message handler
- No ticket created from a message
- A reply goes to the account and no further
Nobody decided the channel should be one-way. Outbound was built because a notification needed somewhere to go, and inbound was never the problem anybody was solving that day.
The desk can talk on WhatsApp and cannot listen. That is a worse position than no integration at all, because the customer has been given a channel that looks open.
Why this is sharper in Dakar than in Dublin
In markets where WhatsApp is a personal messaging app that businesses occasionally use, a one-way notification channel is a minor convenience and nobody expects to reply to it.
In markets where WhatsApp is the business channel — where a customer's first instinct is to message the number on the invoice, and a support desk's real inbox is a phone on a desk — a one-way integration actively misleads. It teaches customers that the channel is live, and every reply lands somewhere the system cannot see.
And the ticket that never gets created is not a small loss. It is the ticket that never gets an SLA clock, never appears in a backlog, never counts in a first-response figure, and never shows up in the report saying how the desk performed.
The other channel, and why the total is one
The ticket model declares an email source. Nothing writes it. There is no mailbox poller, no inbound webhook and no reply parser anywhere in the codebase, so email intake does not exist either — external requesters receive a signed link to a tracking page, and a customer who replies to that email is also replying into nothing.
Put the two together and the desk has exactly one way in: somebody fills in a form. That is a real and defensible product position — a form produces structured, categorised, routable requests, which an inbox does not. What it is not is what most people assume when they see a WhatsApp integration on a settings page.
Four questions about any support channel
Does this channel receive, or only send?
A good answer sounds like
A direct answer, per channel.
What it actually means
The question that corrected our own notes. Ask it of each channel separately — the answer is often not the same.
What happens to a reply?
A good answer sounds like
It becomes a ticket update.
What it actually means
If the answer is vague, the reply is going somewhere nobody reads, and the customer thinks it was received.
Is outbound free text or template-gated?
A good answer sounds like
Template, for business-initiated.
What it actually means
A vendor who says free text has either not built it or does not know the platform's rules.
How many ways can a request enter the system?
A good answer sounds like
A number.
What it actually means
Ours is one. That is defensible and it is worth knowing before you print a WhatsApp number on an invoice.
What AWRA OpsHub does today
- Outbound WhatsApp through the official Meta cloud interface, against the tenant's own business account, with a connection test.
- Notification forwarding to WhatsApp, and workflow rules that can send to it.
- Outbound email notification on ticket events, and a signed tracking link so an external requester can follow a ticket without an account.
- A public request form as a first-class intake path, producing categorised and routable tickets.
- Several other outbound notification channels for internal use.
What it does not do
- Any inbound WhatsApp path. No webhook, no verification endpoint, no message handler, no ticket created from a message.
- Any inbound email path. No mailbox poller, no inbound webhook, no reply parser — the email source on the ticket model is a dead value.
- Conversational outbound on WhatsApp. Business-initiated messages are template-gated with one variable.
- Any channel that both sends and receives. There are none.
Not ours, by choice
- Our own gap file said there was no WhatsApp integration. That was wrong and is corrected — there is one, and it is one-way. We would rather publish the correction than quietly fix the sentence.
- One structured intake channel is a defensible position and we argue it elsewhere. This page is about the gap between that position and what a WhatsApp settings screen implies.
- Nothing here is Senegalese or Ivorian. Dakar and Abidjan are here because WhatsApp is the default commercial channel in those markets, which turns a one-way integration from a curiosity into a lost ticket.
What is not built for Senegal today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Senegal. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If DGID declarations, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
DGID declarations and e-invoicing
Declaration output in the format the administration expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Wave, Orange Money and bank feeds
Mobile money settlement files and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement.
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.
Payroll and statutory returns
IR, IPRES and CSS schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Use the WhatsApp channel for what it is — a way to push a notification to somebody who does not check email — and do not publish the number as a support address. If inbound WhatsApp is how your customers actually reach you, that is an integration build and it should be scoped before a trial, not discovered after you have trained a market to message a number nobody is watching.
Ask which direction the arrow points
For every channel on every integrations page you are shown, ask whether it receives. It is one question per channel and it is the one that separates a support system from a notification system.
Talk about support channelsFrequently asked questions
Can I at least see that a customer replied?
Not in this product. The reply reaches your WhatsApp business account, and whoever has access to that account sees it — which is a person and a phone, not a queue with a clock on it.
Is inbound WhatsApp difficult to add?
It is a well-understood piece of work: a verified webhook, a message handler, and a rule deciding when a message opens a new ticket versus updating an existing one. That last decision is the part that needs thought rather than code.
Why is one intake channel defensible?
Because a form produces a category, a priority and a requester you can route on, and an inbox produces prose. Desks that accept everything by email spend the first minute of every ticket doing data entry. The position is real; the problem is a settings page that implies otherwise.
