Two to three hours a day of WhatsApp and calendar work, down to about fifteen minutes.

Every booking arrived as a WhatsApp conversation, and every conversation had to be answered by a person.

What time does the therapist arrive. Do you bring the table. How much is the couples ritual. Can you come Sunday. Each one answered by hand, then transcribed into Google Calendar with the right address, the right service, the right therapist, the right duration. Getting any of those wrong means a therapist driving across Medellín to the wrong place.

Deisy Marin, the owner, estimates it cost her two to three hours every day. Not in one block. In fragments, all day, every day, between everything else. The kind of work that never appears on a to-do list and quietly consumes the business.

And the hours weren't the whole cost. Enquiries arriving at 11pm sat unanswered until morning. Someone actively looking for a massage at 11pm does not usually still want one at 9am.

No client-imposed restrictions. The constraint was cost.

Every architectural decision on this project came from the same place: a service business that had just launched, with no budget for enterprise tooling.

• Gemini, because at the time it was among the cheapest viable model APIs to run a conversational agent on.
• Telegram, not WhatsApp, for the agent. WhatsApp's Business API was neither free nor simple to connect. Telegram was both.
• And the constraint I couldn't design around: in Colombia, everyone lives on WhatsApp. Clients were not going to move platforms because it suited my architecture.

That last one shaped the whole system, and it's covered in the next section.

A two-speed front door. This is the decision the project turned on.

WhatsApp couldn't be abandoned. It's where Colombian clients already are. But putting the AI agent there wasn't affordable. So instead of forcing one channel, the client chooses which they want:

• Telegram: instant. A Gemini agent handles the conversation: answers questions about services and pricing, checks real availability, and books straight into the calendar. Any hour, no waiting.
• WhatsApp: human, slower. For clients who want to talk to a person and accept that a reply may take a while.

The trade is stated openly, not hidden. The choice is presented explicitly in both chats and on the website: instant answers from software, or wait a little and talk to a person. Clients decide which they'd rather have.

That's the part most automation projects get wrong. The instinct is to hide the bot, or to funnel everyone into it. Telling people plainly which door leads where means nobody feels tricked. The clients who want a human still get one.

Underneath it:

• n8n orchestrating the whole flow, self-hosted
• Google Gemini as the agent, trained on Wellen's services, pricing and tone
• Google Calendar written to in real time, with automated blocking so two bookings can't land in the same slot
• Google Sheets as a parallel record: a dual write, so a calendar failure doesn't lose a booking
• Automated reminder sequences ahead of each appointment
• A Framer site designed for one thing: getting from landing to confirmed booking without friction
• An email sequence built on the trust objection: the safety anchor first, then clinical authority, then a soft nudge to book.

Why not the alternatives: a paid booking SaaS was out on cost, and would still have needed a human answering WhatsApp questions. WhatsApp Business API was out on cost and setup complexity. Building only in WhatsApp meant no automation at all; building only in Telegram meant abandoning the channel every client already used. The two-speed door was the only option that respected both the budget and the market.

Plenty, and most of it in the first version.

The agent gave wrong answers. Confidently, in a client conversation. The worst possible place. Two causes, and they compounded.

The system prompt had grown too long. Every edge case discovered in testing got appended as another instruction until the prompt became a document. Past a certain length the model stopped reliably honouring any single line in it, including the important ones. More instruction produced less obedience.

And the cheapest model couldn't carry it. The tier chosen on cost grounds didn't have the knowledge or the consistency to complete every task the workflow demanded. It handled the simple path and fell apart on the exceptions, which in a booking system are most of the interesting cases.

The fix was both halves at once. The system prompt was rewritten rather than extended. Instructions tightened, and responsibilities redistributed so each part of the flow handled one job instead of one prompt trying to hold everything. And the model moved up a tier, from the lightest Gemini Flash variant to the standard Flash model. Enough capability to handle the exceptions, at a price close enough to the original that the cost constraint still held.

What it changed in how I work: an agent's system prompt is not a place to accumulate rules. Every exception appended to it dilutes everything already there. Past a certain length, more instruction produces less obedience. Split the work so each step has one narrow job, and pay for the model tier the hardest task needs, not the one the simplest task survives. The cheapest model is only cheap until it fails in front of a client.