Here is the model, the parts that get billed, and how to estimate your own number before you commit to anything.

Meta bills per message, not per conversation

Until mid 2025, WhatsApp Business pricing was built around 24 hour conversations. That model is gone. Since 1 July 2025 Meta charges per template message delivered, and templates fall into three categories: marketing, utility and authentication.

Ordinary replies are not templates and are not in that list. They are service messages, and they are governed by the rule below, which is the one that matters most for booking.

The 24 hour customer service window is free

When a customer sends a message to your business number, a 24 hour service window opens. Inside that window you can reply freely, as many times as the conversation needs, at no per message charge.

Appointment booking lives almost entirely inside this window. Think about how the conversation actually starts:

Customer: hi, do you have anything friday afternoon for a cut and colour?

Business: Friday I have 2:00 pm and 4:30 pm free. Which one works?

Customer: 4:30 please

Business: Booked, Friday 4:30 pm, cut and colour. See you then.

The customer opened the conversation. Every reply after that is a service message inside the free window. A ten message back and forth about availability, a reschedule request two days later, a cancellation, a question about parking: all of it starts with the customer writing to you, and all of it is free.

This is the single most important fact about WhatsApp booking economics, and it is the one most comparison articles bury.

What you do pay for: messages you start

You pay when your business starts the conversation outside that window. For an appointment business, that is essentially one thing: the reminder you send the day before, when the customer has not written to you in the last 24 hours.

Those are template messages, and they must be pre-approved by Meta. For reminders, the correct category is utility. Utility rates are the cheapest of the billable categories and vary by country. In many markets they land around one to a few US cents per message, but the spread between countries is wide enough that you should not plan on a single global figure. Meta publishes current per country rates on its WhatsApp pricing page, and it is the only number worth quoting.

One more rule works in your favour: under Meta's current pricing, a utility template sent while the 24 hour service window is still open is not charged at all. So a reminder for an appointment the customer messaged you about this morning usually costs nothing, and only the ones sent into silence are billed.

Do the arithmetic on your own volume

Take your monthly appointment count, and assume the worst case: every single one needs a reminder sent from a cold start. A clinic with 400 appointments a month, at a utility rate of roughly one to two cents, is looking at a few dollars a month in Meta fees. Not a few hundred. A few.

The costs that dwarf that line are the ones people forget to count: the AI model you use to understand the messages, and the hosting the software runs on.

Keep reminders in the utility category

One expensive mistake is worth naming, because it is easy to make and it does not announce itself.

If you write a reminder template that also contains a promotion, "Reminder: your appointment is tomorrow at 3 pm. Also, 20% off all treatments this week", Meta can reclassify that template as marketing. Marketing rates are substantially higher than utility rates, and since 2025 the reclassification is automatic. You do not get a warning email. You get a bigger invoice.

The discipline is simple: reminder templates say only what the reminder needs to say. Promotions get their own template, sent deliberately, with the marketing cost understood up front.

The costs that actually add up

Once you accept that the Meta bill for booking is small, three real costs are left:

That last row is where most of the money is decided, and it is the row you have to check yourself rather than take from an article. Hosted booking services price in very different ways: some charge a flat monthly fee, some charge per location, and some add a margin on top of Meta's rates or on the AI usage they run for you. Over a few years that recurring line is often larger than every other cost combined, but the only way to know is to read the specific pricing page in front of you.

A self-hosted script inverts the shape: you pay once, you run it on your own hosting, you use your own API keys, and the per message costs you pay are the raw ones, with no markup in between.

How to sanity check any vendor's pricing

If you are comparing options, three questions separate a straight answer from a marked up one:

1. Do you charge per conversation, on top of Meta's fees? If yes, ask what the markup is. If the answer is vague, that is the answer.
2. Whose AI API key is used? If it is theirs, you are paying their margin on every message, and you cannot see the underlying usage.
3. Who holds the customer data? Appointment histories and phone numbers are your business's asset. Hosted platforms hold them on your behalf.

None of those questions are hostile. They just move the real cost from the pricing page to something you can calculate.

In short

• The booking conversation itself is free, because the customer starts it.
• You pay for reminders sent outside the 24 hour window, at utility rates, usually cents.
• Never mix promotions into a reminder template, it gets reclassified as marketing and costs more.
• Meta's fees are rarely the number that matters. The software's pricing model usually is.

Rates change and differ by country, so treat every figure here as a shape rather than a quote, and check Meta's current pricing for your own market before you budget.

Originally published on the Rendezo blog. Rendezo is a self-hosted script that turns a business WhatsApp number into an AI appointment assistant: how it works or try the live demo.

This is the honest version, written after doing it and getting stuck.

What you need before you start

• A Facebook Business account, or the willingness to create one.
• A phone number that is not currently active on the WhatsApp app. This is the step most people get wrong. A number already registered on regular WhatsApp or WhatsApp Business app has to be deleted from that app first, and you lose that chat history. Use a fresh number if you can.
• A server with HTTPS. Meta will not send webhooks to plain HTTP, and self-signed certificates are rejected.

Nothing here needs a big server. Shared hosting with a valid certificate is enough for a single location business.

The shape of the setup

Meta renames its buttons regularly, so treat the labels below as landmarks rather than exact text. The shape has been stable for years even as the wording moved around.

1. Create a Meta app at developers.facebook.com, of the Business type, and add the WhatsApp product to it.
2. Meta gives you a test number immediately. It can only message up to five recipients that you add and verify by hand, but that is enough to build and check everything before your real number is involved.
3. Note two identifiers from that screen, you will need both: the Phone number ID and the WhatsApp Business Account (WABA) ID. They are different numbers and mixing them up produces confusing API errors.
4. Generate an access token. The one on this screen is temporary, see the warning below.
5. Configure the webhook: a callback URL on your server and a verify token you invent yourself. Meta immediately calls your URL with that token and expects it echoed back. If your endpoint is not live yet, this step fails.
6. Subscribe to the messages field. An unsubscribed webhook is a webhook that never fires.
7. When everything works on the test number, add your real business number and verify it.

The traps

These are the ones that cost real time. None of them produce a useful error message.

The test token expires in 24 hours

The access token on the setup screen is a short lived one. It works perfectly, you build your whole integration on it, and the next morning every call fails with an authentication error that reads like your credentials are wrong.

They are not wrong. They are expired. For anything permanent you need a token generated from a System User in Business Settings, which does not expire on a timer. Do the test with the temporary token, then switch before you rely on it.

The app can be subscribed to the webhook and still receive nothing

This is the worst one, because every screen in the Meta panel looks correct. The webhook is configured, the messages field shows as subscribed, the verify handshake passed, and messages still never arrive.

The subscription on the app configuration screen is not the same thing as the app being subscribed to your WhatsApp Business Account. Check it directly:

GET https://graph.facebook.com/v23.0/{WABA_ID}/subscribed_apps

If your app is not in that list, subscribe it:

POST https://graph.facebook.com/v23.0/{WABA_ID}/subscribed_apps

(Use whichever Graph API version is current when you read this. The endpoint has been stable across versions; only the prefix moves.)

Messages start arriving immediately. There is no error state anywhere in the interface telling you this was missing.

Verify the webhook signature, and fail closed

Your callback URL is a public address that anyone can find and post JSON to. Meta signs every request with an X-Hub-Signature-256 header computed from your app secret. Check it, and reject anything that does not match.

Fail closed, meaning if the signature is missing or malformed, reject. It is tempting to be lenient during setup while you are debugging. Leniency that ships is an open endpoint that lets a stranger inject fake customer messages into your booking system.

Meta will retry, so handle duplicates

If your endpoint is slow or returns an error, Meta retries the delivery: immediately, then with decreasing frequency over the next 36 hours. Store the WhatsApp message ID and ignore an ID you have already processed. Without that, one delivery hiccup turns into a customer being answered twice, or worse, booked twice.

Templates are the only way to message first

Inside the 24 hour window after a customer writes to you, you can reply freely. Outside it, you can only send pre-approved template messages. Appointment reminders are therefore templates, and they must be submitted and approved before your first reminder can go out. Utility templates are usually approved quickly, often within minutes, but do not discover this requirement on the evening you planned to go live.

Keep promotions out of reminder templates. Mixed content gets reclassified into the more expensive marketing category automatically. We covered that in what WhatsApp appointment booking actually costs.

How to test without a real customer

Two things make this far less painful:

• Use the test number for everything until the integration is solid. Add your own phone as an allowed recipient and message yourself.
• Use a tunnel such as ngrok while developing, so Meta can reach your local machine over HTTPS. Remember that a free tunnel gets a new URL each restart, and Meta keeps calling the old one until you update the callback URL. A webhook that worked yesterday and is silent today is usually this.

Is it worth doing yourself?

For a developer, the Cloud API is genuinely well built. It is a normal REST API with normal webhooks, and once the traps above are behind you it is dependable.

What takes the time is not the connection, it is everything after it: deciding what to say, checking real availability before confirming anything, preventing two customers from taking the same slot, storing the conversation, and sending reminders on schedule.

That gap is exactly what Rendezo is. It is a self-hosted script that handles the Cloud API plumbing, the booking logic and the AI conversation, on your own server with your own keys. You still do the Meta setup above once, because that connection belongs to your business and not to a vendor. After that, the rest is configuration rather than code.

Originally published on the Rendezo blog. Rendezo is a self-hosted script that turns a business WhatsApp number into an AI appointment assistant: how it works or try the live demo.

We build a WhatsApp booking assistant, so we have hit these failures on live numbers rather than in theory. Here are three that matter, with what we measured, and the design rules that came out of them.

Failure 1: it says it did something it never did

The customer asks to cancel. The assistant asks for confirmation. The customer confirms. The assistant replies, warmly and clearly, that the appointment has been cancelled.

It never called the cancel function. Nothing was cancelled. The appointment is still there, the customer believes it is gone, and nobody finds out until someone does not show up.

We saw this three separate times in one evening's live testing in July 2026, with a smaller and cheaper model tier. The same four scenarios were then run against a mid tier model, which passed all four on the first attempt. Model versions change quickly and any specific comparison ages, so the lesson worth keeping is not the name of a model. It is this: for an assistant that takes actions, instruction following is worth more than a lower price per message. The cheap model is not cheaper if one missed cancellation costs an appointment slot and a customer's trust.

The structural defence matters more than the model choice:

The AI never writes to the database. It can only call a small set of functions, and deterministic code decides whether each one is allowed to proceed.

If the model does not call the function, nothing happens in the system, which is bad. But the reverse, a model quietly writing a wrong record, is worse and is ruled out entirely. Every state change in the system has a log line with the tool call that produced it. "It said it cancelled" is never evidence, the log is.

Failure 2: it forgets what it just did

This one is subtle and it nearly stopped our launch.

A customer books an appointment. The assistant confirms it correctly. Then the customer sends the most common last message in any booking conversation: "thanks". The assistant re-checks availability out of reflex, sees that the slot the customer just took is no longer free, concludes it is unavailable, and tells the customer their appointment did not go through.

A perfect booking, undone by a thank you.

The cause was not the prompt. We tested that. The model was not being told to persist proof of what it had done: the machine readable result of the booking call was held only in memory during that one exchange, and never carried into the next turn. On the next message, the model saw its own earlier sentence claiming a booking, but no evidence, and it went to verify.

We ran an isolation experiment, one variable at a time, twenty runs per condition:

Rewording the instruction changed nothing. Carrying the actual result of the action into the conversation removed the failure completely.

The lesson generalises well beyond our product. When an AI assistant appears to have a memory problem, look at what state you are actually giving it before you rewrite the prompt. Prompt wording is where these bugs are usually treated and rarely cured.

There is a second distinction hiding in that fix, and it is worth stating, because getting it backwards creates a new bug. Results of questions, such as "which slots are free", are snapshots that go stale within minutes and must not be replayed later. Results of actions, such as "this appointment was booked", are facts that stay true. Only the second kind belongs in the assistant's long term view of the conversation.

Failure 3: two customers, one slot

Two people ask for Friday at 5pm within the same second. Both conversations check availability, both see the slot free, both confirm. One customer arrives to a chair that is taken.

This has nothing to do with AI. It is an ordinary race condition, and it is solved the ordinary way: the availability check and the write happen inside a single database transaction with the relevant rows locked, so the second request finds the slot taken and is refused. The assistant then does what a receptionist does, apologises and offers the nearest alternative.

The reason to mention it in an article about AI is that it is easy to assume the model handles this. It cannot. A language model has no view of what another conversation did a millisecond ago. Anything that must be true for every customer simultaneously has to live in the database layer, not in the prompt.

What "trustworthy" actually means here

After all of the above, our working definition is narrow on purpose, and it separates two things that are easy to blur: what the system makes impossible, and what it merely makes unlikely.

Guaranteed by the code, not by the model:

• It cannot create, move or cancel an appointment that the database did not accept. Every write goes through a function call, and deterministic code decides whether it proceeds.
• It cannot double book, even under simultaneous requests, because the check and the write happen inside one locked transaction.
• Every action is visible in a log with the exact call that caused it, so a disputed appointment has an answer that does not depend on anyone's memory.

Steered, measured, but not guaranteed:

• Services, prices and available times are handed to the model from your data, and it is instructed to use nothing else. That makes an invented price unlikely and it is what we test for, but no prompt makes a sentence impossible. The guarantee is on the booking, not on every word of the chat.
• It hands the conversation to a human when the customer asks, and when it hits a case outside what it is allowed to do. It cannot recognise every situation where a person would have been better.

The first list is the one that matters. A trustworthy assistant is not a cleverer model, it is a model with a smaller blast radius. Be suspicious of any vendor whose two lists are the same list.

What it still gets wrong

Being honest cuts both ways, so here is the current state rather than the marketing version.

Our assistant occasionally asks one confirmation question more than it needed to, when the customer's intent was already clear. It errs toward caution. We have chosen to leave it that way, because the failure mode of an extra question is a slightly longer conversation, and the failure mode of less caution is a wrong booking.

It also handles a customer who changes their mind mid sentence less gracefully than a good receptionist. Real humans are better at conversation. The assistant wins on being awake at 11pm.

The takeaway

Do not evaluate a booking assistant by how well it chats. Evaluate it by what it is structurally incapable of doing wrong, and by whether the vendor can show you a log of what it did.

If you want to see one running, Rendezo is the self hosted script these rules came out of, and there is a live demo of the admin panel where you can read the conversations and the appointments they produced. The tool calls themselves are written to the application log on your own server, which is the point: on a self hosted install, the record of what the AI did belongs to you and not to a vendor's dashboard.

Originally published on the Rendezo blog. Rendezo is a self-hosted script that turns a business WhatsApp number into an AI appointment assistant: how it works or try the live demo.