WhatsApp and Telegram bots that customers do not resent

What this actually solves

In most of the world, email is not where customers are. They are in WhatsApp, and they have been all day. They will not open an email, they will not notice a chat widget on your website, and they will not install an app to talk to you. They will send a message to the number they already have, and they expect the same responsiveness they get from everyone else in that app.

Which means somebody in your business is holding a phone all day. That person is good at it, and they also sleep. A customer messages at eleven at night asking whether you are open tomorrow and what a service costs. By morning they have asked someone else and booked with them. Nothing was mishandled — there was simply nobody there, and in a channel that feels instant, a twelve-hour reply reads as indifference.

The other half of the value runs outward, and it is often the larger half. Messages sent to this channel get read. Appointment reminders, delivery updates, payment reminders and order confirmations perform in a way the same content does not when it is emailed, which turns them from a courtesy into an operational tool — fewer no-shows, fewer "where is my order" calls, fewer chased invoices.

What decides whether this works is not the technology. It is the conversation design. A bot that answers three things well and hands over cleanly on everything else is an asset. A bot that tries to handle everything and traps people in a loop actively damages the business, and it does so publicly, in front of the customer, in a thread they can screenshot.

What we do, and in what order

1. Choose the platform and start the paperwork immediately. For WhatsApp that means Meta Business verification, selecting the number that will be dedicated to the platform, and choosing a provider. Verification runs on Meta's schedule, not ours, so it begins on day one and everything else is built alongside it. A day of work, then a wait of several days to a couple of weeks.
2. Design the conversation. This is the actual craft, and it is not coding. Every step: what the bot says, which replies are possible, and what happens on each. Buttons wherever buttons will do, open-ended questions as rarely as possible, and every point marked where the bot must stop and fetch a person. Two to four days.
3. Write and submit the message templates. Business-initiated messages on WhatsApp require pre-approved templates — booking confirmation, day-before reminder, cancellation notice — each under the platform's 1,024-character limit with variables in the required placeholder form. Submitted early, because they are reviewed too. One day plus approval time.
4. Build the flows and connect the backend. The bot has to touch something real to be useful: a calendar for bookings, an inventory or price table for questions of fact, a CRM or Airtable base for the record. Anything factual is answered from that data rather than generated. Three days to two weeks.
5. Test with ten real people who are not told what to ask. This is a separate step and it is non-negotiable. Internal testing only covers the paths the builder already had in mind. Real people ask whether you are open on Sunday in the middle of a booking flow, send a photo with no text, and write two requests in one message. Each of those needs a defined response. Two to three days.
6. Launch with monitoring. Error alerts to a channel someone watches, a run log of what the bot did, and a review of the real conversation logs after the first weeks — which is where you learn what to build next. One day.

Typical stack: Telegram Bot API for internal and staff-facing work, WhatsApp Business Platform through Twilio, 360dialog, Wati or Interakt for customers, Make or n8n as the logic layer, Airtable for records, and Google Calendar or Calendly for bookings.

What moves the price

Whether the bot talks or only announces. Outbound notifications — confirmations, reminders, updates — are the cheaper end and can be live in about a week. A bot that holds a two-way conversation and completes a transaction is a different job, because the cost is in the number of situations that must be handled rather than the number of messages.

How deeply it connects to your systems. A bot that answers from a fixed script is simple. One that reads live availability, reserves a slot, writes to your CRM and triggers a confirmation is doing real work against real state, with all the failure handling that implies.

The WhatsApp setup itself. Verification, number selection, provider onboarding and template approval are a distinct piece of work with their own timeline, largely governed by Meta rather than by anyone on the project. It is quoted separately for exactly that reason.

What usually goes wrong

It goes live before the wrong paths were tested. A customer types "are you open Sunday" and the bot launches the full booking menu. Every untested route damages the business's reputation, and unlike an internal system failure it happens in front of the customer. Ten real people, told nothing about what to ask, catch more than a week of structured testing.

The bot is allowed to invent answers. A language model asked about price, availability or whether something can be delivered by Friday will produce a confident answer, and a confident wrong answer sent from a business number is a commitment. Those three categories are answered from data or handed to a person. The model's job is to work out what the customer means, not to decide what is true.

There is no way out. The single sentence that separates a useful bot from a hated one is that a person can always reach a human — one word, from any point, and the automation stands down. Related and just as damaging is the dead end: "Sorry, I didn't understand that" ends the conversation and the relationship. Telling the customer that their message has been passed to a named person who will respond shortly, and offering something useful in the meantime, keeps them. You may never think to ask for this. Your customers decide on it.