Comparison · 5 min read
Who Started It: The Two Kinds of WhatsApp Conversation
There is one distinction on this channel that explains more than any other, and most pricing pages bury it under a table. It is not marketing versus utility. It is this: did the customer speak first, or did you?
Once you know the answer for a given thread, you know roughly what you are allowed to send, whether you need something pre-approved, and which side of the bill it lands on. Get it wrong and you will design a system around a permission you do not have.
The two kinds
They messaged you
You messaged them
Everything else is detail hanging off that split.
The inbound case is a conversation you were invited into. The platform treats it accordingly: it is permissive about wording because a human being just asked you something, and the tightest constraint is time. The outbound case is an interruption, and the platform treats it accordingly too — pre-approved text, declared purpose, and a charge.
An inbound thread is a question you are answering. An outbound one is a door you are knocking on. The platform can tell the difference and prices it that way.
Why the billing follows the same line
It would be reasonable to expect a messaging platform to charge per message. This one has not, and the reason is the split above.
If a customer asks four questions and you answer four times, that is one interaction from the customer's point of view. Charging it four times would push businesses to compress helpful answers into fewer, worse messages. So the billable unit has been a conversation — a window opened by something, with messages inside it not each charged again.
Which means the pricing question that matters is not "how many messages" but "how many windows did I open, and who opened them?" Two businesses sending identical message volumes can have very different bills if one of them is mostly answering and the other is mostly initiating.
The window is the part people design badly
Inbound conversations run on a clock. That clock is the reason WhatsApp automation is a different engineering problem from email.
Two failure modes, both common:
Assuming your reply restarts it. On messaging channels of this shape the clock is generally reset by the customer's activity rather than the business's. Sending three more messages does not buy you three more hours. If a customer asks something at 11pm and your team answers at 2pm the next day, whether that reply is still permitted as free text is a question about elapsed time, not about effort.
Building a nurture sequence inside it. A window is not a campaign slot. It exists so you can finish a conversation somebody started, and a business that uses it to run a drip is converting goodwill into blocks.
What this means for the way you actually work
Three consequences, in order of how much money they move.
- Answer fast, and the expensive half of the problem shrinks. Every question resolved inside the window that a customer opened is a question you did not have to reopen later with an approved template. Response speed is a cost lever on this channel, not just a service metric.
- Earn the reply on outbound. If you are going to open a thread, the message worth sending is one that invites an answer rather than one that pushes a link. A reply moves the thread into the permissive, conversational mode where you can actually be useful.
- Count windows, not messages, when you forecast. Your monthly estimate should be built from orders, bookings and campaigns — the things that open threads — rather than from a guess at message volume.
The honest limitation
None of this makes an unwanted message wanted. A business-initiated conversation is chargeable and permitted and still capable of costing you far more than its rate, because the person receiving it has a block button next to the reply button and no obligation to be reasonable about it.
That is why consent is not a compliance chore on this channel — it is the thing that decides whether the money you spend opening a thread does anything at all.
Where we actually stand
PostEngage does not ship WhatsApp. What is above is how the channel works, not a description of a product you can buy from us today.
The same who-spoke-first logic is why the Instagram side of what we build looks the way it does. A comment can be replied to for seven days. A DM window runs twenty-four hours and is restarted only by the other person's message, never by ours — so the automation checks the window before it composes anything, and records a refusal with a reason when the clock has run out.
If you want the reply mechanics in full, the automation post covers both halves. If you want the money view, the cost post has the levers. And if you are wondering where a language model can and cannot operate inside all this, that boundary is here.
