The messaging APIs are the easy half. Each one is a POST with a token. What actually costs you time is that the four channels disagree about who the user is, how long you may speak, what a message can contain, and whether anyone is listening. Build as if those are the same and you get a bot that works beautifully in the browser and behaves strangely everywhere else.

Here is the comparison I wish I had seen before starting, and the shape of code that survives it.

The comparison that matters

Four rows in that table cause nearly all the work.

1. Identity: the hardest one, and it is not technical

On the web the user is anonymous. On WhatsApp you have a verified phone number. This sounds like a straight upgrade, and it is also a trap: a phone number is personal data, and the same person on two channels is two different users to you.

Decide early what a "contact" is in your system, because it determines whether you can join conversations later:

• A conversation belongs to one channel and one channel identity. Always.
• A contact is a person, and may link several channel identities.
• Linking happens only when the person tells you — they give an email in web chat that matches a contact, they message from a number you already hold. Never infer it.

Do not skip the contact layer because you launched with one channel. Adding it later means backfilling every conversation you ever stored, and guessing at links you no longer have evidence for.

And store the phone number the way personal data should be stored: scoped to the tenant, out of logs, out of analytics events, deletable on request.

2. The reply window is a design constraint, not an API detail

Web chat has no concept of being "allowed" to reply. The other three do, and WhatsApp's is the strictest: a customer's message opens a 24-hour window in which you may send free-form text, and outside it you may only send a pre-approved template. Messenger has its own 24-hour rule with a set of tagged exceptions. Telegram, pleasantly, just lets you message.

Two consequences worth designing for rather than discovering:

Human handover breaks across the window. Your bot escalates at 11pm, an agent replies at 10am — on WhatsApp that reply is outside the window and will be rejected. The whole escalation flow needs a template path, or your agents will send messages that silently never arrive.

Anything proactive is a different feature per channel. An appointment reminder is free text on Telegram, a template with an approval queue on WhatsApp, and a tagged message on Messenger. Build it as one feature and you will build it three times anyway; better to know that up front.

So the send path has a gate, and the gate is per channel:

// Each adapter answers for itself. The core never reasons about windows.
const canSendFreeForm = {
  web:       () => true,
  telegram:  () => true,
  whatsapp:  c => Date.now() - c.lastInboundAt < 24 * 60 * 60 * 1000,
  messenger: c => Date.now() - c.lastInboundAt < 24 * 60 * 60 * 1000
};

Evaluate it immediately before sending, never when queueing — a reply that waited forty minutes in a queue may have been legal when it was created and illegal by the time it goes out.

3. Formatting: write once in a neutral form, render per channel

The answer your model produces is Markdown. Nobody accepts Markdown.

Telegram wants HTML or MarkdownV2 — and MarkdownV2 requires escaping a long list of characters, so an unescaped . or - in an answer returns a parse error and the message never sends. WhatsApp has its own asterisk-and-underscore convention. Messenger is plain text with structured attachments beside it. Web chat can render whatever you like.

The mistake is letting channel formatting leak into the generation prompt — "reply in Telegram HTML" — because then the answer is wrong for every other channel and you cannot reuse it.

Generate neutral, render at the edge:

// The model returns Markdown. Each adapter is the only thing that knows
// what its channel accepts.
const render = {
  web:       md => markdownToHtml(md),
  telegram:  md => markdownToTelegramHtml(md),   // and escape < > &
  whatsapp:  md => markdownToWhatsAppText(md),   // *bold*, _italic_, the rest flattened
  messenger: md => stripToPlainText(md)
};

Two details that bite: links, which web chat renders inline but plain-text channels need spelled out in full, so a bare URL is safer than [click here](...); and length, since a 3,000-character answer is fine on the web, over the limit on Messenger, and unreadable on a phone anywhere. Cap the answer in the prompt and split long ones in the adapter.

4. The adapter boundary that keeps this sane

Everything above points at the same structure. One core that knows nothing about channels, and a small adapter per channel that knows everything:

// Every adapter normalises inbound to the same shape...
// { channel, channelUserId, conversationId, text, attachments, receivedAt }
//
// ...and takes outbound in the same shape:
// { text (markdown), quickReplies?, handoff? }

async function handleInbound(msg) {
  const conversation = await findOrCreateConversation(msg);
  const answer = await generateAnswer(conversation, msg.text);
  const adapter = adapters[msg.channel];

  if (!adapter.canSendFreeForm(conversation)) {
    return adapter.sendTemplate(conversation, 'reopen', { topic: answer.topic });
  }
  return adapter.send(conversation, adapter.render(answer.text));
}

The test for whether you have the boundary right: generateAnswer contains no if (channel === ...). If it does, the channel has leaked into the brain, and every new channel will mean touching it.

Two more things that belong in the adapter and nowhere else: retries and deduplication. WhatsApp and Messenger both redeliver webhooks when you are slow to acknowledge, so every adapter needs to ack fast and drop message ids it has already seen. Telegram's long-polling has its own version of the same problem. The core should never see a duplicate.

5. What each channel is actually good at

Worth being honest about, because "be everywhere" is not a strategy:

• Web chat is the only one where the visitor is already looking at the thing they want to ask about. The best context, the worst retention — close the tab and they are gone.
• WhatsApp is where the customer already is, and the conversation persists for years in a thread they will scroll back through. It costs money and it has the strictest rules. Worth it when the customer base lives there.
• Messenger matters if the business's audience arrived through a Facebook page. If it did not, it is effort for nothing.
• Telegram is the easiest to build on by a wide margin — generous API, no fees, no windows — and the smallest audience for most businesses. It is a great first non-web channel precisely because it will teach you the adapter boundary cheaply.

If you are adding your first extra channel, add Telegram to learn the shape, then WhatsApp because that is where the customers are.

The short version

The APIs are not the work. The work is identity, the reply window, formatting, and keeping all three out of the part that writes the answer. Get the adapter boundary right and the fourth channel takes an afternoon. Get it wrong and the second one takes a week and the third never ships.

I build ChatNory, which runs one chatbot — trained on a business's own content — across a website, WhatsApp, Messenger and Telegram. The adapter boundary above is the second version; the first had channel checks in the answer generator and it was exactly as pleasant as it sounds.

That column is now the only thing standing between your two customers' data. One forgotten WHERE clause and customer A's chatbot answers a question using customer B's internal pricing document. You will not get a second chance to explain that.

This is what I would set up on day one of a multi-tenant product, in the order the risk actually appears. It is written around a chatbot — vector search makes one of these problems unusually sharp — but most of it is the same for any SaaS.

1. Never pass the tenant id as an argument

The single highest-value change, and it is architectural rather than clever.

If getDocuments(tenantId, query) takes the tenant as a parameter, then every call site is a chance to pass the wrong one, or to forget it in a new function written at 1am. Humans do not reliably remember a rule 400 times.

Instead, resolve the tenant once, at the edge, from the authenticated session — never from a request body, a query string, or a header the client controls — and carry it in a context the data layer reads for itself:

// One place turns a session into a tenant. Nothing downstream takes it as an argument.
app.use(async (req, res, next) => {
  const session = await getSession(req);
  if (!session) return res.sendStatus(401);
  // The tenant comes from the session, never from req.body.tenantId.
  tenantContext.run({ tenantId: session.tenantId }, () => next());
});

// The data layer reads the context itself. There is no overload without a tenant.
function documents() {
  const { tenantId } = tenantContext.getStore() ?? {};
  if (!tenantId) throw new Error('No tenant in context — refusing to query');
  return db('documents').where({ tenant_id: tenantId });
}

That throw matters more than it looks. The failure mode you want for a missing tenant is a loud crash, not a query that quietly returns everything.

In Node this is AsyncLocalStorage. Most ecosystems have an equivalent. The point is not the mechanism — it is that the safe path is the only path, so a new developer cannot write the unsafe one without noticing.

2. Put the same rule in the database

Application-level filtering is one bug away from failing. A second, independent layer means a bug needs two mistakes to become a breach.

In Postgres that is row-level security:

ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents FORCE ROW LEVEL SECURITY;   -- applies to the table owner too

CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

with the setting applied per transaction from the same context as above. FORCE is the line people miss: without it, the owner role bypasses the policy, and your application often connects as the owner.

This is defence in depth, not belt-and-braces theatre. The two layers fail for different reasons — one to a forgotten clause in code, the other to a misconfigured role — and it is unlikely you make both mistakes in the same hour.

3. Vector search is where isolation quietly breaks

Here is the chatbot-specific trap, and it is the one I would check first in anyone else's system.

A vector index does not have a WHERE clause in the way a SQL table does. Approximate nearest-neighbour search walks a graph and returns the k closest vectors it finds. If you then filter those results by tenant, two bad things happen:

• Correctness: you asked for 20 and got 20 from across all tenants; after filtering, you might have 3 for this tenant, or none. The bot answers badly for no visible reason.
• Safety: every piece of filtering logic between the index and the answer is a place to get it wrong.

Post-filtering is the wrong shape. The two shapes that work:

An index per tenant. Simplest to reason about, and the cross-tenant bug becomes structurally impossible — a query against tenant A's index cannot return tenant B's rows, whatever the code does. The cost is many small indexes, which is fine for hundreds of tenants and painful for a hundred thousand.

Pre-filtered search, where the tenant is a condition the index applies during the search, not after. pgvector does this naturally, because it is a Postgres query and row-level security already applies:

SELECT id, content, 1 - (embedding <=> $1) AS score
FROM   documents                      -- RLS already scopes this to the tenant
ORDER  BY embedding <=> $1
LIMIT  20;

Managed vector databases support metadata pre-filtering too — but read their documentation carefully and test it, because "filter" in some engines means post-filter, and the difference is exactly the one that matters here.

Write a test for this and never delete it. Two tenants, two documents, one query that would match the other tenant's document far better than its own:

test('a tenant never retrieves another tenant\'s content', async () => {
  await seed(tenantA, 'Our refund window is 30 days.');
  await seed(tenantB, 'Our refund window is 90 days.');

  const hits = await asTenant(tenantA, () => retrieve('how long is the refund window'));

  expect(hits).not.toHaveLength(0);                     // it still works
  expect(hits.every(h => h.tenantId === tenantA)).toBe(true);
  expect(hits.map(h => h.content).join(' ')).not.toMatch(/90 days/);
});

That last assertion is the one that catches a post-filter regression where the leak reaches the prompt but not the response object.

4. Secrets belong to one tenant each

Customers will give you API keys — their own model provider key, a WhatsApp token, an SMTP password. These need handling that plain columns do not give you:

• Encrypted at rest with authenticated encryption, AES-256-GCM or equivalent, so a database dump is not a credential dump.
• Decrypted only at the moment of use, never loaded into a general-purpose settings object that gets logged or serialised into an API response.
• Masked everywhere they are displayed. Show the last four characters. There is no screen that needs to show the whole key, including the owner's own settings page — they have it already.
• Scrubbed from errors. A provider's error object will happily include the request headers you sent.

5. Make the tenant visible in everything you operate

Isolation that you cannot observe is isolation you are only assuming.

• Logs carry the tenant id on every line. Debugging a cross-tenant issue without it is guesswork.
• Metrics and rate limits are per tenant. One customer's traffic spike should not degrade everyone, and a per-tenant limit is also your defence against a runaway loop in someone's integration costing you a fortune.
• Background jobs carry the tenant explicitly, because they run outside the request that had the context. This is the most common place the whole scheme leaks: a cron job with no session, written months later.
• Caches are keyed by tenant. A cache key of answer:${hash(question)} will serve tenant A's answer to tenant B, and it will do it intermittently, which makes it nearly impossible to reproduce.

That cache bug deserves emphasis. It is the one that gets shipped by careful teams, because the cache is added later as an optimisation, by someone who is thinking about latency rather than tenancy.

What it costs to do this on day one

Perhaps two days of work: the context plumbing, the RLS policies, the per-tenant index decision, the isolation test, the encrypted-secrets helper.

Retrofitting it onto a live product with real customers is weeks, because every query, job and cache written in the meantime has to be found and re-checked, and you cannot be sure you found them all. The second system is also the one where you are reading your own code wondering whether an untested path ever leaked.

The work is not hard. It is just much cheaper before the second customer than after the twentieth.

I build ChatNory, a multi-tenant AI chatbot that answers from each business's own content. The isolation test in section 3 exists because the post-filtering version looked completely fine until it did not. If you run vector search across tenants, go and check whether your engine pre-filters or post-filters — it is a five-minute check and it is worth doing today.

People budget for the indexing — the "training on your content" part — because that is the part that sounds expensive. It is the cheapest line on the bill. The money goes somewhere else entirely, and if you do not know where, you will optimise the wrong thing for a month.

Here is the actual shape of it, with a method you can run on your own numbers. I am deliberately not quoting per-token prices: they change every few months, and a blog post with 2026 prices in it will be wrong by the time you read it. Go to your provider's pricing page, take today's numbers, and substitute them into the formulas below.

The four lines on the bill

Every answer your bot gives costs you four things, in wildly different proportions:

1. Indexing — embedding your content. Paid once per change.
2. Query embedding — turning the customer's question into a vector. Paid per question.
3. Generation — the LLM writing the answer. Paid per question, by input and output tokens.
4. Everything that is not AI — hosting, the vector store, bandwidth, your time.

Let me take them in order of how much people over- and under-estimate them.

1. Indexing is rounding error

Embedding is priced per token and embedding models are the cheapest thing in the stack, typically one to two orders of magnitude cheaper per token than a generation model's input.

A mid-sized business site — say 200 pages averaging 800 words — is roughly 210,000 tokens. Embedding that whole site, from scratch, costs a few cents at any current embedding price. Even re-embedding it nightly for a year is less than a single month of generation on a modestly busy bot.

The practical conclusion is a design decision, not a saving: stop treating re-indexing as expensive. Re-crawl nightly. Re-index the moment a page changes. The reason people's bots quote last year's prices is almost never cost — it is that nobody built the refresh.

2. Query embedding is also rounding error

A customer's question is 10–30 tokens. Embedding it costs a fraction of a fraction of a cent. You can safely ignore this line. I mention it only because people sometimes try to cache query embeddings, which is effort spent saving nothing.

3. Generation is the whole bill

Here is where it all is, and the number that drives it is not what people expect. It is not the answer length. It is the context you send.

A typical RAG request looks like:

So you are paying for roughly 4,500 input tokens and 200 output tokens per message. Input tokens are cheaper than output per token, but there are twenty times more of them — on most models' pricing, input is still the majority of the cost of a RAG answer.

And a "conversation" is not one message. Real support conversations run 3–6 messages. So:

cost per conversation
  = turns × (input_tokens × input_price + output_tokens × output_price)

Plug in your provider's current per-million-token prices and you have your number. Do this before you price your product, not after.

Why history is the sneaky one

Notice what happens as a conversation goes on. Turn 1 sends 4,500 tokens. Turn 2 sends those 4,500 plus turn 1's question and answer. Turn 5 can be sending 8,000. Naive conversation handling makes cost grow quadratically with conversation length.

Two fixes, both cheap:

// 1. Cap history by tokens, not by message count, and always keep the
//    first user message — it usually holds the actual intent.
function trimHistory(messages, maxTokens = 1200) {
  const first = messages[0];
  const rest = [];
  let used = estimateTokens(first);
  for (const m of messages.slice(1).reverse()) {
    const t = estimateTokens(m);
    if (used + t > maxTokens) break;
    rest.unshift(m);
    used += t;
  }
  return [first, ...rest];
}

2. Re-retrieve per turn instead of accumulating chunks. If turn 3 is about shipping, you do not need turn 1's pricing chunks still sitting in the prompt. Retrieve fresh for each question and the input size stays flat instead of climbing.

The three levers that actually move the number

Prompt caching. Most providers now let you mark a stable prefix — your system prompt, your few-shot examples — as cacheable, and charge much less for cached input tokens on subsequent calls. Structure your prompt so everything stable comes first and everything variable comes last, or the cache never hits. This is the single largest saving available and it costs you one afternoon.

Fewer, better chunks. Going from 10 chunks to 5 halves the largest part of your input. Re-ranking makes this safe — the five you keep are better than the ten you had. Cheaper and more accurate is a rare combination; take it.

A small model for small jobs. Not every call needs your best model. Classifying "is this a greeting, a question, or abuse?", rewriting a follow-up into a standalone query, deciding whether to escalate — these run fine on the cheapest model in the family. Route by job, not by habit.

What does not move the number much: shortening your system prompt by a few sentences, trimming the answer length, or switching embedding models. People spend days there.

4. The costs that are not tokens

For a small deployment these often exceed the AI bill, and they get forgotten in every estimate I have seen:

• The vector store. Hosted vector databases charge for storage and for the pods or units that keep the index warm, and that is a monthly floor whether or not anyone chats. At the scale of a single business's website, pgvector on a Postgres you already run, or SQLite with a vector extension, is genuinely enough — a few hundred thousand vectors is not big data. A managed vector service is a decision to make at scale, not at launch.
• Egress and hosting for the widget, the admin, the webhooks.
• WhatsApp, if you use it, is billed by Meta on its own per-message schedule, entirely separately from your AI costs. It is quite capable of being the largest line on the bill.
• Your time. Thirty minutes a month reading the unanswered-questions log costs more than the tokens.

Two numbers worth writing down

Cost per conversation tells you whether the unit economics work. Compute it from the formula above and sanity-check it against a real week of traffic.

Cost per resolved conversation tells you whether the thing is worth running at all. If 40% of conversations end in a human being involved anyway, your real cost per deflected ticket is 2.5× the headline — and you should compare that against what the ticket would have cost in staff time.

That second number is the one to put in front of whoever approves the spend. It is also the one that improves when you fix your content, which brings everything back to the same place: the bot's economics are mostly a property of how well your website answers questions.

The useful summary

• Indexing: ignore it, and re-index far more often than you do.
• Generation: all of the cost, and most of it is input tokens, not output.
• Conversation history: the thing that quietly makes turn 5 twice the price of turn 1.
• Prompt caching, fewer chunks, cheaper model for small jobs: the three levers that matter.
• The vector store's monthly floor can beat your token bill at small scale. Start with Postgres.

Work out the per-conversation number before you quote a client a monthly price. It takes twenty minutes and it is the difference between a margin and a surprise.

I build ChatNory, an AI chatbot that answers from a business's own content on its website, WhatsApp and Telegram. These numbers come from running it, including the month I spent optimising the wrong line. If your cost shape looks different, I would like to hear why — especially if you are at a scale where the managed vector store starts paying for itself.

A RAG-style chatbot works the other way around. You give it your existing material. When a visitor asks a question, the system retrieves the relevant passages and writes a reply from them. It can answer questions you never wrote a flow for, and it stays current as you publish. If the delivery policy is in the knowledge, it can handle "do you deliver to Salt Lake on Sunday if I order after 6?" You update the source instead of redrawing a tree.

The trade-off is honesty. A scripted bot fails loudly, because it has no path. A generated bot can fail quietly if it is allowed to guess. Prefer a tool that says it does not know, and offers a person, over one that always sounds confident.

What to feed it

Answers are only as good as the sources. Feed the bot what a good support person would open:

• Published pages and posts — about, shipping, returns, services, and booking instructions.
• Product data — names, prices, stock status, SKUs and categories.
• PDFs, office files and a clean price list — rate cards, menus, policy handbooks, a spreadsheet or catalogue.
• Past questions — old chats or a short Q&A list, in the phrasing people actually use.

Leave out drafts, internal cost sheets, unpublished discounts, staff records, and other people's personal data. If a document is half-public, split it first. A plugin that syncs published WordPress content is worth more than a one-off paste.

Languages your visitors actually type

People ask in the language they think in — Bangla, English, Hindi, Arabic — and they expect the reply in the same one. A bot that only answers in English will miss a large share of those questions.

Look for a bot that replies in the language the visitor typed, rather than a separate tree per locale. ChatNory, used in the walkthrough below, does that. It supports 11 languages, including Bangla, English, Hindi and Arabic.

Feed it sources in the languages you care about, or at least a clear canonical policy. A bot cannot invent your Sunday delivery rule in Bangla if that rule exists nowhere in the knowledge.

Human handover, WhatsApp, Messenger and Telegram

Some questions should never be left to a model: a complaint, a payment dispute, or anything the bot flagged as unknown. The useful pattern is live handover. Your team can step in; when a person starts typing, the bot steps aside so the visitor is not answering two voices at once.

Many customers never open your site widget. They already message you on WhatsApp, Messenger or Telegram. One chatbot, trained once, should answer in those channels. The WordPress plugin keeps site content in sync; the apps are connected in the product dashboard, not in wp-admin.

Check the plan before you promise this. On ChatNory, live chat and human handoff are on the Starter plan ($10 per month) and above. WhatsApp, Messenger and Telegram are on the Pro plan ($35 per month). Connect only channels you actually monitor.

Privacy, before you paste a site key

A chatbot that "knows your business" stores your business, and your visitors' questions, on someone else's server. Read the plugin disclosure and the product's privacy policy before you connect a site.

The ChatNory plugin sends the title, URL and plain text of published pages, posts and WooCommerce products (including price, stock, SKU and categories), plus your site address. Draft, private and password-protected content is not sent. Visitor messages and the page they are on go to the host. Nothing moves until you paste a server URL and site key.

Do not upload customer lists, invoices with personal data, or internal documents as training material. If visitors chat on your site, you are the controller of that conversation data. Use a host that lets you export or delete it, and mention the chat in your own privacy policy. Developers can limit the sync with the chatnory_post_types and chatnory_sync_limit filters if a custom post type should stay off the record.

Step by step: WordPress, no code

This uses ChatNory because it has a free WordPress plugin, a free plan, and it is built around training on your own content. The same checklist works with another host; only the setting names change.

1. Install the plugin. In wp-admin go to Plugins → Add Plugin, search for ChatNory, or install ChatNory – AI Chatbot, Live Chat & Customer Support from WordPress.org. Activate it (WordPress 5.8+, PHP 7.4+). You also need a ChatNory account, because the bot runs on a hosted model, not on shared hosting. The free plan is enough to try this.

2. Create the chatbot. Sign up at chatnory.com, create a chatbot, and give it a role and tone. Add sources the plugin will not sync: PDFs, a price list, Word or Excel files, or a short Q&A.

3. Connect the site. In the ChatNory dashboard open Settings → General → WordPress plugin and copy the Server URL and Site key. In WordPress go to Settings → ChatNory, paste both values, and click "Save & connect."

4. Ask it something awkward. The plugin trains the bot on published pages, posts and, if you use it, WooCommerce products. In a private window, ask what a real customer would ask, including one question you know is not documented. The right behaviour is "I don't know" plus a path to a human, not a guess.

5. Choose how it appears. Placement, devices and published state are set in the ChatNory dashboard, not by editing your theme. To embed the chat inside a page, use the shortcode [chatnory]. Optional attributes are height (default 560) and width (default 100%).

There is a free plan; paid plans start at Starter for $10 per month and Pro for $35 per month.

If ChatNory is not the right fit

Tidio is a strong choice if you want a familiar live-chat widget first, with automation and an AI layer on top, and you are happy in a large, established product.

Crisp is a shared inbox that also does chatbots. If your team already runs support from Crisp, adding a bot there is usually better than introducing a second inbox.

If the problem is "the bot should answer from our pages, PDFs and price list, in the language the customer typed," a content-trained tool with a WordPress sync is the shorter path. If the problem is "five agents need one shared inbox tomorrow," start with the helpdesk you will actually live in.

Before you publish, train the bot only on public content, test a question it cannot answer, and match handover and channels to your plan. Keep a human in the loop, and do not let the model bluff.

I'm D. Raju, founder of ChatNory, based in Kolkata.