Can you build your own AI receptionist? An honest answer

Yes, you can build one, and a working demo takes about a weekend. Read Instagram messages through Meta's Messaging API, pass them to a language model with your services and opening hours in the prompt, write the result into Google Calendar. It will answer a message and book an appointment on the first try, and it feels finished.

It is not. The demo is the easy fifth of the work, and the gap between it and something you would let talk to paying customers unsupervised is where DIY projects in this category stall. What follows is a description of that gap, written by people who sell the alternative, so weigh it accordingly. We have tried to be specific enough that you can check each claim yourself.

What the weekend build looks like

The shape is genuinely simple:

1. A webhook receives the message from Meta.
2. You load the conversation history, your service list, durations and prices.
3. A model turns "can I come in Thursday afternoon for a cut and colour" into a structured intent.
4. You check the calendar, pick a slot, write the event, and reply.

Every piece of that is documented and none of it is exotic. If you have a developer, they will get it working. The reason to keep reading is that none of the following four problems show up in the demo, and all four show up in week one.

Problem one: the booking is a race, not a conversation

Two people message you at 20:14 on a Sunday. Both want Thursday at 15:00. Your model handles each conversation independently, because that is what conversations are, and it offers the slot to both. Both accept. You now have a double booking, and one you will not discover until Thursday.

The fix is not a better prompt. It is a lock: a reservation held against the slot the moment it is offered, released if the customer does not confirm within some window, and a calendar write that fails safely if the slot went while the customer was typing. That is ordinary backend engineering, it is unglamorous, and it is the actual product. Every hour spent improving the model tone is an hour not spent here, and tone is not what loses you a Thursday.

Problem two: you cannot always reply later

Meta gives you 24 hours to respond after a user messages you, on both Instagram and WhatsApp. Inside that window everything is easy. Outside it your options narrow sharply, and this is where a self-built system quietly starts failing. The customer who messaged on Friday night and needs a confirmation on Sunday afternoon is outside the window. So is every appointment reminder, by definition, because a reminder sent the day before an appointment is almost always more than 24 hours after the customer last wrote to you.

On WhatsApp the path is defined: Meta moved to per-message billing on 1 July 2025, and reaching someone outside the service window means sending a template message, billed by category and country. Replies inside the window and non-template messages are free. So your reminder architecture has a cost per customer, and you need to know it before you design the flow, not after.

Problem three: people cancel in ways your parser has never seen

Booking is the easy direction. A customer who wants an appointment is cooperative and says roughly what you expect.

Cancelling and rescheduling are not like that. Real messages look like "sorry cant make it", "can we do the week after instead", "actually no", and a voice note. Some arrive at 23:40. Some reference an appointment from two messages ago rather than the most recent one. Some are ambiguous in a way a human would resolve instantly and a model resolves confidently and wrongly.

The failure mode is expensive in a specific way: a booking system that occasionally deletes the wrong appointment is worse than no booking system, because now you distrust the calendar. Once staff start double-checking every entry by hand you have added work rather than removed it, and the tool gets abandoned regardless of how good the happy path was.

Handling this properly means confirmation steps on destructive actions, an audit trail of what changed and why, and a bias toward asking rather than guessing. All of which makes the demo feel slower, which is why it rarely survives a weekend build.

Problem four: knowing when to stop talking

The most valuable behaviour is not answering. It is recognising the message it should not answer: a complaint, a question about a medical condition, a regular customer asking for something unusual, someone clearly upset.

A model with no explicit boundary will attempt all of these, fluently and with confidence. That is the single worst outcome available, because a wrong answer delivered smoothly is harder to catch than an obvious failure. You need an explicit escalation path, a rule for what triggers it, and a way for the human to take over mid-conversation without the customer noticing a seam. That is a product decision as much as an engineering one, and it takes iterations against real messages to tune, because you cannot guess the boundary from your desk.

So when should you build?

Your rules are genuinely unusual. Overlapping resources, staff-specific skills, equipment that has to be free at the same time as a room, deposits that change the rules. If your logic does not fit any product model, you will fight the product forever, and building is cheaper than fighting.

You already have the engineers. Not we could hire someone, but a team that will still be there in eight months when Meta changes an API.

The booking flow is your product. If you are building a marketplace or a platform where booking is the thing you sell, this is core and should not be outsourced.

And the honest inverse: if you run one salon, your rules are ordinary, you have no engineers, and you want this working next week, building it is the expensive option. Not because it is hard to start, but because you have signed up to maintain a piece of infrastructure against a platform that changes underneath you, in exchange for saving a subscription.

What we would actually do in your position

Build the demo. Seriously. Spend the weekend, connect the API, get it answering messages. You will learn more about your own booking rules in two days than in any amount of vendor calls, and you will know exactly which of the four problems above matters most for your business.

Then decide with that knowledge. If your rules turn out to be ordinary and the hard parts are the four above, buy something, because those four are the same for everybody and someone has already paid for them. If your rules turn out to be strange, you now have a working prototype and a clear specification, which is a much better starting point than a procurement process.

We would rather you made that decision informed than have you buy Avenos because a comparison table told you to. If you want to see what the bought version costs, there is the cost breakdown, and the flow itself is on how it works.