Automation · Customer service and scheduling
Book a Cal.com meeting on the right calendar
An AI agent books Cal.com meetings from chat: it picks the right account and event type, offers real open times and creates the booking.
How do I make sure a meeting booked from chat lands on the right person's calendar?
A Met connected to Cal.com makes two decisions before it talks about times. First it looks at which Cal.com accounts are connected: each one arrives with its label and a description of what it is for, and that description decides which calendar the meeting belongs on when the team runs several. Then it reads the event types on that account, with their title and duration, and picks the one that matches what the person asked for instead of putting everything into a thirty minute call. Only then does it read the open times, offer them in the time zone of the person writing, and create the booking with the exact value of the chosen slot. Three things to know first: Cal.com requires an attendee email, it does not reschedule (moving a meeting means cancelling it and creating another) and a booking can only be looked up or cancelled with its code, which the Met hands over in the conversation.
What starts it
When the customer writes
Nothing is scheduled. Somebody writes asking to talk to the team, over WhatsApp or the website chat, and the Met assigned to the channel resolves it in the same conversation. It works the same for a cold enquiry and for someone coming back after reading a proposal who wants half an hour with whoever wrote it.
Nothing to set up. The Met assigned to that channel picks up the conversation and runs the procedure inside it.
Who runs it
Meeting intake Met
Customer service team
Not a named, seeded Met: it is the same Met that already answers your channel, with Cal.com connected. Its job is not to close the sale, it is to route. Work out what the person wants, send them to the calendar of whoever can actually take it, and get the meeting created before the conversation cools off, which is what happens when the answer is "we will write to you to coordinate".
Channels: WhatsApp · Website chat
What you need connected
- Cal.com Sell and serve
6 steps · 6 tools
The procedure, step by step
Each step shows the tool that runs. They belong to the real connector: if one of them stopped existing, this page would not build.
- 1
Pick the calendar before picking the time
The listing returns the Cal.com accounts connected to the workspace, each with its label and a description of what it is for. That description is the instruction: "product demos", "support for customers under contract", "the partner who covers healthcare". The Met reads the intent of whoever is writing and picks the account, instead of sending everything to the first calendar it finds. When only one is connected, the same response says so and the rest of the steps never name it again.
- 2
Decide what kind of meeting this is, at its real length
The event types on that account arrive with their identifier, their title and how many minutes each one runs. This is where the size of the meeting is decided, which is the decision nobody makes and everybody pays for: a twenty minute first conversation is not the same appointment as a one hour technical review, and putting both into the same type is how a week fills up with badly measured meetings. The Met picks from the types that already exist in Cal.com; creating a new one happens there, not from chat.
- 3
Offer times that exist, in the time zone of whoever is writing
The query takes the local date the person wants, not a converted one, along with their time zone, and returns the open times for that event type between the two dates. The Met offers two or three concrete options instead of asking when suits you best, which is the question that stretches the conversation and lands on a time that was already taken. If the range they asked for has nothing open, it says so and proposes the next one instead of stretching the calendar.
- 4
Ask for the email, because without one there is no booking
Cal.com requires three attendee fields to create the booking: name, email and time zone. On WhatsApp what arrives is a phone number, not an email, so the Met asks for it, and it should ask once the person has picked a time rather than as a greeting. The phone can be attached as well, but it does not replace the email. The time is sent as an exact copy of the one the previous call returned, never rebuilt and never converted to UTC.
- 5
Hand over the code so "what time was it again?" has an answer
The booking comes back with a code, and that code is the only key there is: the connector does not list anybody's bookings, so whatever did not stay in the conversation cannot be found again. The Met hands it over as soon as the booking exists and later uses it to answer the usual questions, retrieving the booking details rather than trusting what was said twenty messages earlier.
- 6
Cancel with the reason, and book again if it has to move
Cal.com does not reschedule in one step: moving a meeting means cancelling the one you have and creating another. The Met does it in that order and writes the reason into the cancellation, which the API treats as optional and the business should not: "a trip came up" and "they lost interest" are two different things, and at the end of the month they can only be told apart if somebody wrote them down. Then it reads the open times again and creates the new booking, which for Cal.com genuinely is a new booking, with a new code.
Before you start
What you need ready
The Met solves none of these for you. If one is missing, the automation stops there.
-
A Cal.com account with a v2 API key
The key is generated in Cal.com under Settings, Developer, API Keys, and pasted into the Meteor panel. On connecting, Meteor asks each account for its event types to validate it, so a key copied badly shows up right there and not during the first meeting.
-
Event types already created in Cal.com
You define them in Cal.com, with their duration and availability. The Met reads them and picks among them; it does not create them. If the team has a single generic thirty minute type, this recipe has nothing to decide and the conversation resolves fine without it.
-
A label and a description for every connected calendar
When several accounts are connected, each one gets a label and a description of what it is for. That description is exactly what the Met reads in order to route, so writing it well is half the setup: if they read "account 1" and "account 2", there is nothing to decide with.
-
A channel with the Met assigned to it
A WhatsApp Business API line or the website chat, with the customer service Met assigned to the channel. The whole recipe happens inside the conversation, so with no channel there is no trigger.
The limits
What this automation does NOT solve
Better said here than discovered halfway through the rollout.
-
It does not configure Cal.com. Event types, durations and availability are defined there; the Met reads and uses them. A time Cal.com does not offer will never show up in the chat.
-
It does not reschedule in one step. Moving a meeting means cancelling the one you have and creating another, and that has consequences: the code changes and Cal.com holds two bookings.
-
It does not send reminders. None of the six tools schedules an advance notice. If your team relies on a nudge the night before, that is solved in Cal.com or by a separate automation.
-
It does not list anybody's bookings. Lookups and cancellations go by the code of each booking, so a booking made outside the chat, whose code nobody has at hand, cannot be touched from here.
-
It does not charge for the meeting or take a deposit. No tool in the connector touches payments; if you sell hours, the money runs through whichever gateway you have connected.
-
It does not convert times to UTC inside the conversation. It uses the exact value the availability call returned, because rebuilding a time is how bookings land on the wrong slot.
FAQ
Questions about this automation
Yes. The account step becomes a single call that reports there is only one, and from then on nothing has to name it. What remains is everything else, which is most of it: picking the right event type, offering times that exist and creating the booking with the exact value. With one calendar the routing is redundant, not the question of what kind of meeting this is.
Because Cal.com requires it to create the booking: the attendee goes in with name, email and time zone, and without all three the call fails. The phone can be attached as well, but it does not replace the email. It is the field that adds the most friction on a messaging channel, so it is worth asking once the person has already chosen a time.
The Met cancels the one that exists, with the reason, and books another on an open time. It is not one step because Cal.com does not offer it in one. If a single step reschedule matters to your operation, Meteor's native scheduling does it, requires nothing to be connected and has a recipe of its own.
By the description each account carries in Meteor, not by guesswork. If they read "pre sales", "support under contract" or "the partner who covers healthcare", the routing works. If they read "main" and "the other one", the Met has nothing to decide with and will end up asking, which beats getting it wrong but is not what you set this up for.
Availability is read at the moment of offering and the booking is created against that exact time. The second one finds the space gone, and what the Met does is the right thing: read availability again and offer the closest alternative, rather than confirming a meeting Cal.com rejected.
The event types it reads belong to the user who owns the key, and the availability call accepts filtering by user or by team. What works best today is connecting one account per calendar you want to use, with its own label: it is explicit, it can be described and it reads clearly in the conversation.
Keep going
Other automations built on the same tools
Customer service and scheduling
Book optometry appointments over WhatsApp with Softix
How can patients book an optometry appointment over WhatsApp at the right location?
Customer service
- Starts:
- when the customer writes
- Steps:
- 6, with 7 real tools
- Needs:
- Softix
Customer service and scheduling
Book, remind and reschedule appointments over WhatsApp
How do I let customers book over WhatsApp without double-booking anyone?
Customer service
- Starts:
- when the customer writes
- Steps:
- 5, with 10 real tools
- Needs:
- Meteor Scheduling · Meteor CRM
Customer service and scheduling
Reserve a vehicle over WhatsApp with HQ Rental
How do I reserve a vehicle over WhatsApp using live HQ Rental availability?
Customer service
- Starts:
- when the customer writes
- Steps:
- 5, with 5 real tools
- Needs:
- HQ Rental Software
Customer service and scheduling
Answer "where is my order?" for Mercado Libre sales over WhatsApp
How do I answer the status of a Mercado Libre order without opening the seller panel?
Customer service
- Starts:
- when the customer writes
- Steps:
- 5, with 10 real tools
- Needs:
- Mercado Libre · Meteor CRM
Want this automation running on your own data?
We will show it to you with your accounts connected, not with a canned demo.