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