Why connect it at all
A WhatsApp interface on its own is a shared inbox with a nicer app.
Connected to your business system, it becomes something different:
Messages send themselves. An order is confirmed, and the customer hears about it. Nobody types anything.
Agents see who they are talking to. Orders, invoices, deliveries, previous conversations.
Conversations become records. A support message creates a ticket rather than living in somebody’s chat.
That is the difference between using WhatsApp and integrating it.
The two directions
Outbound. Your system sends. An order confirmation, a delivery update, a payment reminder, a document.
Inbound. A customer replies, and the message reaches the right place — a ticket, a record, a person.
Most projects start outbound. It is simpler, the value is immediate, and it does not require rethinking how support works.
FIGURE 1: THE OUTBOUND CHAIN
Something happens
- An order is confirmed
Your system triggers
- A webhook, or a scheduled check
Template is filled
- Name, order number, date
Message sent
- And the send is logged back
What outbound needs
Four things.
A trigger. Your system tells the messaging platform something happened. Either it calls a webhook directly, or a middleware layer polls for changes.
Customer phone numbers, formatted consistently. See the section below — this causes more failures than anything else.
An approved template for the message type.
The variables. Name, order number, date, amount — pulled from the record.
And one thing people forget: log the send back onto the record. So a person looking at the order can see the customer was told, and when.
The phone number problem
The single most common cause of integration failure, and it is entirely avoidable.
Phone numbers in most business systems are inconsistent. Some with a country code, some without. Some with spaces, brackets, dashes. Some with a leading zero, some without.
WhatsApp needs a specific format. Numbers that do not match simply fail to send, often quietly.
What to do:
Clean the existing data. Normalise every number to include the country code with no spaces or punctuation.
Validate at entry. Stop new bad numbers being created.
Handle failures visibly. If a send fails because of a bad number, somebody should see it — not just a silent gap.
Do this before you build anything else. A perfect integration on top of messy phone data does not work.
FIGURE 2: DO THIS FIRST
Normalise existing numbers
- Country code included, no spaces or punctuation.
Validate at entry
- Stop new bad numbers being created.
Log every send on the record
- So a person can see the customer was told, and when.
Make failures visible
- A silent gap is the worst outcome.
What inbound needs
Harder, and worth doing properly.
Matching the sender to a customer. By phone number — which is why the formatting work matters in both directions.
Deciding where it goes. A support ticket? A note on the customer? A sales enquiry?
Giving the agent context. Their orders, their invoices, their history. Otherwise you have a chat app with extra steps.
Handling unknown senders. Somebody messages who is not in your system. Create a record? Route to a general queue? Decide this before go-live, not when it happens.
Where Odoo helps
If your business system is Odoo, one thing makes this easier.
Everything is in one database. When a message arrives and the sender is matched to a customer, the agent can see their orders, their invoices, their deliveries and their previous tickets — without any additional integration.
A messaging platform connected to a separate helpdesk sees support history only. Connected to Odoo, it sees the whole relationship.
And outbound triggers are straightforward. Odoo’s automated actions can call a webhook when an order is confirmed or a delivery is validated.
How to connect it
Three approaches, in order of effort.
A ready-made connector. Some messaging providers offer Odoo integrations. Check first — a configured connector beats a build.
A workflow tool. N8N or similar sits between, receiving Odoo events and calling the messaging API. Visual, flexible, and something a colleague can read.
Custom integration. Direct code between your system and the messaging API. Most control, most build effort, cheapest to run at high volume.
Check for a connector first. It is the same rule as any integration — somebody else maintaining it is worth a great deal.
FIGURE 3: WHAT MAKES THESE PROJECTS WORK
Working
- Phone numbers cleaned before building
- Sends logged on the customer record
- Unknown senders handled deliberately
- Failures alert a named person
Struggling
- Built on inconsistent phone data
- Nobody can see whether a message was sent
- Unknown senders fall into a gap
- Silent failures for weeks
Failure handling
Messages fail. Numbers change, people block you, the API has an outage.
Four things to have:
Retry for temporary failures.
Record permanent failures on the customer record. A number that no longer works is information somebody needs.
Alert somebody if failures spike — that usually means something systemic.
Never let a failed message be invisible. If a customer was supposed to be told their order shipped and was not, somebody should know.
Consent, in the integration
Not just a policy question — it has to be built in.
Store consent as a field on the customer record. Separate flags for utility and marketing.
Check it before every send. Not at the campaign level — at the individual send.
Handle opt-out automatically. A customer replying “stop” should update the record, and every system should respect it immediately.
If opt-out is manual, it will be missed. That is how businesses damage their quality rating without meaning to.
A sensible build order
- Clean phone numbers. Everything else depends on it.
- Add consent fields to your customer records.
- Build one outbound message — order confirmation is the usual choice.
- Log the send on the record.
- Test with real orders, including awkward ones.
- Add more message types once the first is stable.
- Then build inbound, with a decision about unknown senders.
Do not build both directions at once. Outbound first, proven, then inbound.
The short version
Connecting WhatsApp to your business system is what turns it from a shared inbox into automation.
Clean your phone numbers first. Inconsistent formatting causes more failures than anything else, and no amount of good integration work fixes it.
Log every send on the record, store consent as a field, and check it at the individual send.
Start outbound with one message type, prove it, then expand.
Want order updates going out automatically on WhatsApp?
Get in touch. We start with your phone number data, because that is what decides whether the rest works.
