Your systems
Your system already knows. It should be the one sending the message.
The order is confirmed in your software at 11am and somebody types it into WhatsApp at 4pm, if they remember. That gap is the whole opportunity, and closing it is usually the part of this that pays for itself.
The shape of it, end to end
Where it starts
Your own system
- Calls a URL
- API or database
- File or sheet
What we build
The bridge
Your event becomes an approved template, addressed to the right customer, sent from your own number.
Where it lands
Your customer, on WhatsApp
In the app they already have open, in the same conversation as every message before it.
Replies come back the same way. At the start they land in the shared inbox and write very little into your system, and we widen that once you trust it.
The events worth sending
These are not features to switch on. Each one is a moment in your business where a customer is currently either waiting or phoning to ask. We pick the ones that matter to you at the demo, usually three or four to start, and add more once your team sees them working.
Order received, order confirmed
The customer stops wondering whether the message got through, and your sales desk stops answering "did you get my order?" all morning.
Ready, dispatched, on the way
With the vehicle or the waybill number where you have one. This is the message that removes the most phone calls in a distribution business.
Delivered, and a proof of delivery
Sent to the customer the moment your driver or system marks it. A picture or a document attaches to the same conversation.
Invoice issued, payment due, payment received
A quiet reminder three days before a due date collects money that a monthly statement does not. The receipt afterwards ends the argument about whether it was paid.
Quotation sent, quotation about to expire
A quotation that nobody chases is a quotation that dies. This is the cheapest follow-up your sales team will ever run.
Low stock, or back in stock
Outbound to a customer who asked, or inbound to your own team as an alert on the same number.
Illustration. The event names and messages are examples; yours are written with you and approved by Meta.
How the bridge is actually built
There are three ways in, and almost every business has at least one of them. What your software is called matters far less than which of these it can do.
- Your system can call a URL when something happens
- The cleanest and the fastest. Your software posts the event to us at the moment it occurs, and the message goes out in seconds. Most modern ERP and e-commerce systems can do this out of the box.
- Your system has an API or a database we can read
- We poll for what changed on a schedule you set, usually every few minutes, and send from that. Slower than a webhook by minutes, and invisible to the customer.
- Your system exports a file, or your team keeps a sheet
- A daily export dropped in a folder, or a spreadsheet your dispatch team already maintains. Not elegant, and it works. A large number of real businesses run on exactly this and there is no reason they should be locked out.
What we look at before we promise anything
At the demo we ask what your system is, whether it can call out, whether anyone has the credentials, and who owns it. If the honest answer is that the bridge is not worth building this quarter, we will tell you that and start with the inbox and templates instead.
One example, in full
A packaging manufacturer in the UAE runs its orders in its own ERP. Before, a coordinator worked through the day’s dispatch list and messaged customers by hand from a phone on the desk, and the ones sent late in the afternoon were often not sent at all.
Now the ERP calls a URL each time an order changes state. Three templates are approved: confirmed, dispatched with the waybill number, and delivered. The customer’s replies land in the shared inbox, where the coordinator answers the ones that need a person, which is far fewer than before because most of the replies used to be “where is my order”.
Nothing about that required new software in the factory. It required one URL, three approved templates and an afternoon.
Messages coming the other way
The bridge runs both directions. A customer reply can create a record in your system, update an order note, or raise a ticket, so the conversation is not stranded in a chat app while your system stays ignorant of it.
We keep this deliberately narrow at the start. Writing into a system of record is where integrations go wrong, so the first version reads a lot and writes very little, and we widen it once you trust it.
What we need from your side
- Someone who knows the system
- Your own IT person, or your software vendor's support contact. One call with them is usually enough to know exactly what is possible.
- A test environment, if one exists
- We build against test data first. Nobody's real customer gets a message from a half-built bridge.
- The wording you want customers to see
- You know your customers. We turn your words into templates Meta will approve, which sometimes means changing them, and we will show you exactly what changed and why.
Bring your system to the demo
Tell us what you run and what your team types by hand today. We will tell you in the call which of the three routes fits, and roughly what it takes.
Book a demo