The add-on Messaging keeps the dialogues that happen in short messages — SMS, WhatsApp, Telegram and other messengers — right next to email and calls. Customers write where it is convenient for them, the team answers from one screen, and outgoing messages respect consents and budgets. There is no second messaging stack inside the product: the add-on rides the same send rail, consent machinery and stop lists your email campaigns already use.
Why you need it
Customers stopped writing long letters a while ago: a short message is faster and more familiar. But a messenger dialogue that lives on an employee’s personal phone does not belong to the company — the day that person leaves, the history leaves with them. Messages sent in bulk from a personal number raise two questions nobody can answer: who actually agreed to receive them, and how much did they cost? And when a customer complains about spam, there is neither a consent nor a log to show.
Messaging moves this correspondence into the CRM and makes it manageable. Answers go out from a shared place, consents and opt-outs are handled automatically, and every outgoing message passes its checks before it leaves. You see not only “sent”, but what it cost and why some messages did not go out at all.
What it does
- Channels are settings, not separate programs. WhatsApp, Telegram and Viber are assembled from one set of rules: what an address looks like, whether there is a reply window, whether approved templates are required, which consent topic the kind belongs to, how the cost is calculated and how long a message body may be. A channel is switched on with data, the channel row’s kind is validated against the live registry, and adding a new kind of messenger is a row in that registry rather than a new branch in the program. SMS runs beside them through the same dialogue screen.
- A reply inside the customer’s own dialogue. The customer wrote first, so you answer with free-form text right in that conversation. An opt-out — a short “STOP”, for example — stops marketing pushes but never the answer to the customer’s own request: support must not fall silent because the customer refused advertising. The global blocklist is checked before the wire, and a refusal names the recorded reason in its own words.
- The WhatsApp reply window. A customer’s message opens a window in which plain text is allowed: 24 hours by default and 72 hours for Click-to-WhatsApp dialogues. Every new inbound opens it again, and the expiry is derived from that moment, never guessed. Outside the window only pre-approved templates go out, and the refusal says so by name — “window closed, an approved template is needed” — instead of staying silent.
- Templates with honest approval. A template is born “pending approval”: the platform’s verdict is never assumed. A content change returns the template to pending, and a human records the approval. Until that is recorded, a WhatsApp template send is refused by name — both when the send is planned and at the gateway.
- The price before the send and the report after it. Before you send, the add-on answers without writing anything: the window state, the template’s approval, the promised cost, the budget left, the wire’s connection facts and the blocklist verdict. Prices are your own rate cards by country, category and effective date, and the most precise matching row wins. The spend report reconciles one to one with the conversation sends it mirrors, and a send with no rate card standing says “unknown” rather than inventing a number.
- Proactive messages with brakes. A rule says whom to write to, on which channel, with which template, when, and with what caps — per conversation, per contact per week and per day. Stop conditions (the customer replied, bought, opted out, or the owner changed) are read from the journals, and every stop is written down. Each attempt lands in an attempt journal — planned first, then settled exactly once as sent, refused or cancelled — and the digest names every refusal and cancellation next to its count, so “why did this not go out” always has an answer.
- Social networks as an honest minimum. Sources such as VK, OK and Avito-class platforms are data rows, each with its own address grammar and its own honesty note. A public comment and a direct message are told apart on the message itself: a public thread is read by many, a private one by two. An angry public comment can be moved into a private conversation in one action, leaving an internal trace note on the public thread, and private text can never leave through a public reply path — the product refuses by name. The social report counts volumes, escalations and arrival-based first-response times from the journals, and carries no message bodies.
- One door for incoming messages. A message is journaled once under its own external id, so a redelivered platform event changes nothing and the same dialogue never multiplies. A sender nobody recognises births its own unanchored family and waits to be attached, instead of being glued to a random card. Delivery reports seat the outbound message’s own stamps, first verdict wins.
- Telegram as the second kind. Telegram runs through the Bot API: the bot token is encrypted and never served back, replies need neither a window nor an approval gate, and inbound updates journal once per update id, so a redelivered update is a no-op. Nothing about Telegram is a code branch — it is one more row in the same kind registry every other channel reads.
- Platform quality and limits as facts. Each kind carries one active channel row, a monthly send cap counted from the journals for the current UTC month, and the platform’s own quality and tier words, which an agent copies over from the platform’s console. A report landing in the alert zone notifies every workspace administrator, because falling quality is exactly what gets numbers limited or blocked.
- One workplace. The Messaging console is made of five tabs — Channels, Windows & Costs, Kinds, Social and Proactive. The console only reads: changes are made by agent commands, which can be copied straight from the interface.
How it relates to other add-ons
Messaging declares two required add-ons — inbox and marketing — and will not install without them, because a short message needs a dialogue to live in and a send rail to travel on. Inbox provides the one conversation model: a message from any channel becomes part of the customer’s single history. Marketing provides the one send rail, the consent machinery, the suppressions and the cost arithmetic — which is why an opt-out, a quiet hour or a stop list behaves the same for a messenger reply as for a campaign letter, and why there is no second channel stack to keep in sync. Installing Messaging brings both add-ons along, and the product refuses to switch either of them off while Messaging is active, naming Messaging as the dependent. If Messaging itself is switched off, one-way channel sending keeps working exactly as it did — there is simply no two-way dialogue. Contracts between add-ons are core ports with their own fallbacks, so a missing neighbour degrades honestly instead of breaking.
Honest limits
- There are no unofficial WhatsApp modes and there never will be. Working through WhatsApp Web with a wrapper is an unofficial route the platform prohibits and blocks accounts for, and the product does not support it. Four honest modes stand: the official WhatsApp Business API; WhatsApp through a wrapper (unofficial, prohibited); the Telegram Bot API; and Telegram Business API and MAX, which are deferred for now. Aggregators such as Umnico, UIS, Chat2Desk and Wazzup are named deferrals too.
- A Telegram bot answers but cannot write first — it may only message a customer after the customer has written to it. That is the platform’s rule, not a product setting.
- There are no out-of-the-box connectors for social platforms: social facts arrive through the general logging door, which an outside system fills. Direct connections to VK, OK, Avito and the Instagram class are named deferrals, and publishing to any platform from the product is out of scope by design.
- Template approval is recorded by a human: the product does not decide whether a platform accepted a template. Until the approval is stamped, a WhatsApp template send is refused by name — deliberately, so that nobody sends a customer something the platform has not accepted.
- The spend report covers dialogue sends only. Campaign sends on the same WhatsApp rail belong to marketing, with their own economics and their own report; that border is drawn on purpose, because campaigns and conversations have different occasions and different owners.
- Quality and tier are stamped rows rather than a live reading: there is no live platform API client behind them, so the figure is as fresh as the last stamp copied from the platform’s console. An empty quality seat means “never reported”, honestly.
- Escalating a public comment never sends a platform message: the connector is deferred, so the move places the correspondence into a private conversation and says so on the row instead of pretending a reply went out.
- The limits are real and counted from the journals: one active channel row per kind, a monthly send cap for the current UTC month, and the daily maximum of a proactive rule. Once a cap is reached, sends are refused by name rather than quietly throttled or lost.
All add-ons → Add-ons catalogue