Four kinds of WhatsApp tool, and why the category matters more

CodeWords sits in one of the categories below, so read this knowing that. It is not a ranking, and a vendor-by-vendor comparison lives on tools for building WhatsApp agents if that is what you came for.

This is the decision that sits above that one. Tools in this space fall into four categories that do genuinely different jobs, and most of the expensive mistakes are people choosing the wrong category and then blaming the vendor. Swapping one flow builder for another is a fortnight. Discovering that your problem was never a flow builder problem is a year.

What we'll cover

• The mistake that costs the most
• The shared inbox
• The flow builder
• The general automation platform
• Framework and code
• Building it with CodeWords
• Which category your problem is in
• Combinations that work
• What moves, and what does not
• Making it survive
• Limits worth knowing about
• What to decide first
• Frequently asked questions

The mistake that costs the most

Comparison tables line up vendors on features, which quietly assumes they are alternatives to each other. Frequently they are not.

A business whose real problem is that four people need to answer the same number buys a conversation builder and spends six months building flows nobody needed. A business that needs one thing to happen when an order status changes buys a shared inbox and finds it cannot do that at all. Both blame the product.

So the first question is what kind of problem you have, and the four categories below answer to genuinely different ones.

The shared inbox

Usually sold by a Business Solution Provider, and the job is letting several humans work one number.

You get an agent view, assignment and routing, canned replies, tags, and the onboarding and template management handled for you. Automation exists and is normally simple: keyword rules, menus, an out-of-hours reply.

It suits a business where the answer is more people rather than fewer conversations. A team of five sharing one number, needing to see who is handling what, with human replies as the point.

It stops when you want something conditional on data held elsewhere, or state that survives a week, or generated rather than selected replies.

The failure mode is a business that needed a small amount of automation paying per seat forever and building the automation somewhere else anyway.

The flow builder

A canvas of nodes and branches, and the job is designing a conversation explicitly.

You get a visual representation of what happens, decision points, data capture into fields, and usually some integration nodes. Non-technical people can follow the picture, which is the main attraction.

It suits conversations with genuine structure and a fixed set of outcomes. Booking something, qualifying a lead, taking a structured order, triaging an enquiry to a department.

It stops at complexity. A canvas stays readable up to a point, and that point arrives when several branches need to rejoin, or when the same subflow is wanted in six places, or when someone answers three questions at once and the flow only knows how to ask one.

The failure mode is a diagram nobody dares change, maintained by whoever drew it, with a dozen near-identical branches that were copied because reusing one was harder.

The general automation platform

Trigger and action wiring across many services, and the job is moving data between systems.

You get hundreds or thousands of connectors, scheduling, conditional logic and usually a code step. WhatsApp is one connector among many rather than the centre of the design.

It suits anything whose centre of gravity is other systems. A message arrives, something happens in a CRM, a ledger, a calendar, a spreadsheet, and a reply goes back. Most of the work is the integrations.

It stops at conversation. Built around discrete events, these platforms handle multi-turn state awkwardly, and they usually have no concept of the 24-hour window or template requirements, which becomes your problem to model by hand.

The failure mode is a run for every inbound message with no idea the messages belong to one conversation.

Framework and code

Libraries and a service you host. Maximum control, maximum responsibility.

It suits cases where the conversation is the product, where volume makes per-unit platform pricing dominate, where the domain requires you to explain any individual answer, or where the behaviour is genuinely unlike anything a product assumed.

It stops at maintenance. Somebody has to hold the webhook handling, retries, duplicate delivery, template management, ordering, storage and deployment. That is ongoing work by people who can do it.

The failure mode is a good system built by one person who then leaves.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, including the systems involved and what has to reach a person.
3. Authorize the connections to those systems and your WhatsApp Business Platform account.
4. Describe the exceptions, which is where category differences show up most sharply.
5. Try the same awkward case in two categories before committing, since an afternoon spent that way is worth more than any comparison table.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Which category your problem is in

Four questions, and the answers point clearly.

What is the bottleneck? Humans not keeping up points at a shared inbox. The same question asked repeatedly points at generation. Data living in the wrong place points at an automation platform.

Does a conversation carry state across days? If yes, anything built around discrete events will fight you.

How much of the work is integration? If most of it, the tool with the connectors wins regardless of how good its conversation handling is.

What happens when it is wrong? Where you must be able to explain any individual answer, you need inspectability, which narrows the field sharply.

Answer those honestly and the category is usually obvious. The trouble comes from answering them about the system you would like to have rather than the one you need next month.

Combinations that work

Most real deployments use two categories, and some pairings are much better than others.

Inbox plus automation platform. Common and sensible. Humans work the inbox; the platform handles the data movement behind it.

Flow builder for structure, escape hatch for the rest. Workable where the flow builder has a genuine code step rather than a webhook to something you now also run.

Conversation layer plus automation platform. What most businesses with both real conversations and real integrations end up at.

Two flow builders. The one that does not work. Split conversation logic across two canvases and nobody can answer what happens to a given message.

The rule worth holding is that conversation state should live in one place. Two tools each believing they own it produces failures nobody can reproduce.

What moves, and what does not

Changing vendor inside a category is manageable. Changing category is not, and the cost is not where people expect.

The number moves, with effort. It is yours, on your business portfolio.

Templates do not really move. They are approved per account, and the ones that work are the product of real iteration.

History moves badly, and where you have retention obligations that matters.

Flow definitions do not move at all. Every canvas format is proprietary.

The knowledge moves worst of all. Which wording works, which questions confuse people, which exceptions actually occur. It lives in the heads of whoever ran the thing, and it is the most valuable asset you have.

Which is the argument for keeping content, wording and business rules somewhere outside whichever tool you pick, so a change of category moves configuration rather than everything you have learned.

Making it survive

Write down which category you chose and why. In a year, somebody will ask.

Keep conversation state in one place, whichever tool owns it.

Hold content and rules outside the tool where the format allows.

Re-ask the four questions annually, since your bottleneck moves.

Export periodically, rather than discovering the format when leaving.

Limits worth knowing about

No category is better in general, they answer different questions.

Feature comparisons hide category differences, because a feature list flattens tools that are not alternatives.

The right category changes as you grow, most often from inbox towards automation as volume rises.

Two tools owning conversation state produces unreproducible failures.

Every category has a ceiling, including writing it yourself, where the ceiling is how much your team can maintain.

What to decide first

Whether your bottleneck is humans not keeping up, the same question being asked repeatedly, or data sitting in the wrong system. That one answer selects the category, and the category matters more than anything inside it.

Two habits make the difference. Keep conversation state in exactly one place, because the failures produced by two tools disagreeing about it are the ones nobody can reproduce. And hold your content, wording and rules outside whichever tool you choose, since that is what makes a future change of category a migration rather than starting again.

Frequently asked questions

What are the four categories of WhatsApp tool?

Shared inboxes for several humans on one number, flow builders for explicitly designed conversations, general automation platforms for moving data between systems, and frameworks or code for full control.

Why does the category matter more than the vendor?

Swapping vendors inside a category takes a fortnight. Discovering your problem was never that category's problem takes a year, and most expensive mistakes are that second kind.

When is a shared inbox the right answer?

When the bottleneck is humans keeping up rather than conversation volume: a team sharing one number who need assignment, visibility and canned replies, with human replies as the point.

When does a flow builder stop working?

At complexity. Canvases stay readable until branches need to rejoin, the same subflow is wanted in several places, or somebody answers three questions in one message.

Why do general automation platforms struggle with conversation?

They are built around discrete events, so multi-turn state is awkward, and they usually have no concept of the 24-hour window or template requirements, which you then model by hand.

When is writing it yourself justified?

When the conversation is the product, volume makes per-unit pricing dominate, the domain requires explaining any individual answer, or the behaviour is genuinely unlike anything a product assumed.

Which combinations work?

Inbox plus automation platform, or a conversation layer plus an automation platform. The pairing to avoid is two flow builders, because conversation logic split across two canvases becomes unanswerable.

What transfers if I switch?

The number, with effort. Templates, history and flow definitions transfer badly or not at all, and the hardest loss is the knowledge of which wording works, which lives with whoever ran it.

How do I choose between vendors once I know the category?

Run your own awkward cases through each, ask where conversation state lives, what happens when the 24-hour window closes, and what you can export if you leave.

Does the right category change over time?

Yes, most often from an inbox towards automation as volume rises. Re-asking where the bottleneck sits once a year is worth the hour.

Related reading

• Where no-code stops on this channel
• The vendor-by-vendor comparison
• What a WhatsApp chatbot costs