Calendly and CodeWords: the work either side of a booking
Preparing before the meeting, routing bookings to the right person, handling no-shows, and making sure what was agreed reaches the systems that need it.
Rebecca Pearson11 min read
On this page
Calendly solved the scheduling problem completely. Nobody exchanges six emails about Thursday any more, and that was worth solving.
What it left untouched is everything either side of the booking. Somebody still researches the person before the call, still types notes afterwards, still updates the CRM, and still notices — or does not — that four people booked and two never turned up. A booking is a small event that creates several obligations, and Calendly's job ends when the slot is taken.
What we'll cover
- What a booking actually creates
- What the Calendly API reaches
- Connecting it to CodeWords
- Seven automations worth building
- No-shows, which are a process problem
- Building it so it survives
- Limits worth knowing about
- What to build first
- Frequently asked questions
What a booking actually creates
A research task. Somebody should know who this person is before the call: their company, their role, whether they are already a customer, whether they have spoken to anyone here before.
A preparation task. For a demo, the right account set up. For a support call, the ticket history to hand. For an interview, the CV read.
A record. The meeting should exist against the right contact in the CRM, with whatever the booking form captured.
A follow-through. Notes, next steps, and whatever was promised, reaching the systems that will act on them.
A signal, if nothing happens. A no-show is information, and it is information that is invisible unless somebody records it.
All five happen for every booking, and in most teams three of them depend on somebody remembering.
What the Calendly API reaches
Scheduled events can be listed and read, including the event type, time, location, and status.
Invitees carry the name, email, timezone, and the answers to any questions on the booking form, which is the useful payload.
Event types can be listed, which is how an automation knows what kind of meeting this is and therefore what preparation it needs.
Cancellations are readable, including the reason where one was given, which matters for anything analysing why bookings fall through.
Routing forms and their submissions can be read, for setups that qualify before offering a slot.
Webhooks fire on invitee created and invitee canceled, which is what lets automation react at the moment of booking.
Organization membership can be read, which is how a team-wide automation knows whose calendar a booking landed on.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: which event types, what preparation, and where the record should go.
- Authorize the connection with a Calendly personal access token or OAuth, scoped to the organization.
- Describe the exceptions: a booking from someone with no matching CRM record, a cancellation, a reschedule.
- Test with real bookings on a test event type before anything runs on customer-facing slots.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Seven automations worth building
Pre-meeting briefing. On booking, assemble what you know — the company, the person's role, existing account status, past conversations, open support tickets — and deliver it to whoever is taking the call, timed to arrive shortly before rather than at the moment of booking.
CRM record creation and linking. Create or find the contact, log the meeting against them, and attach the booking form answers. This is the step most commonly done by hand and most commonly skipped.
Qualification routing. Where the booking form captures qualifying information, route the booking to the right person or flag it for reassignment. Calendly's own routing handles some of this, and anything depending on data Calendly does not hold needs to come from outside.
Preparation tasks. Create whatever needs to exist before the call: a demo environment, a document, a checklist assigned to somebody.
No-show detection and follow-up. Covered in its own section below.
Post-meeting follow-through. Prompt for notes shortly after the call, and route whatever was agreed into the systems that will act on it.
Booking pattern reporting. How many bookings, from which sources, how many cancel, how many no-show, by event type. Useful for deciding whether a particular funnel is producing meetings worth having.
No-shows, which are a process problem
Every team with a booking link has no-shows, and most handle them by feeling mildly annoyed and moving on.
Record them deliberately. Calendly knows a meeting was scheduled; it does not know whether anybody attended. That has to come from somewhere — a calendar integration, a conferencing tool, or a person marking it — and without it the rate is unmeasurable.
Measure the rate by source. No-shows from a paid campaign, from an outbound sequence, and from your website will differ substantially, and that difference is worth knowing before spending more on any of them.
Follow up once, warmly. A single message offering to rebook recovers a meaningful proportion and costs nothing. Assuming disinterest costs you the ones who simply forgot.
Look at the reminder timing. Most no-shows are forgetting rather than avoiding. Whether a reminder arrives the day before or an hour before changes the rate more than anything else you can adjust.
Watch the gap between booking and meeting. Bookings made three weeks ahead no-show far more than ones made for tomorrow. If your rate is high, the available window may be the cause.
Do not automate anything punitive. A message implying somebody wasted your time closes a door that a warm rebooking offer keeps open.
Building it so it survives
Make it safe to run twice. Webhooks retry. Creating a duplicate CRM activity or sending a briefing twice is untidy and visible.
Handle reschedules properly. A reschedule arrives as a cancellation and a new booking, and an automation treating them independently will send a cancellation follow-up to somebody who simply moved the meeting.
Time the briefing to be useful. Delivered at booking, three weeks before the call, it will be forgotten. Delivered the morning of, it gets read.
Match contacts conservatively. An ambiguous match should create a flagged record rather than attaching the meeting to the wrong company.
Report the outcome. A daily line with bookings processed, briefings sent, and anything that could not be matched.
Limits worth knowing about
Rate limits apply, which matters mainly for automations backfilling historical bookings.
Webhook subscriptions are scoped to a user or an organization, so a team-wide automation needs the organization scope rather than one person's.
Booking form answers are free text unless you configured them otherwise, so anything parsing them should handle variation rather than assuming a format.
Cancellation reasons are optional, so an automation analysing them is working with a subset.
Calendly does not know about attendance. Whether anybody actually joined has to come from another system, which is the central constraint on no-show automation.
What to build first
The pre-meeting briefing, delivered the morning of the call. It is immediately valued by whoever takes the meeting, it is easy to check because they will tell you whether it was useful, and it forces you to establish the contact matching that everything else here depends on.
Two habits make the difference. Ask the person receiving it what is missing after a week, since the first version always includes something nobody reads and omits something they look up anyway. And have it report when it could not match a booking to a contact, because those are the ones where the CRM record silently never got created.
Frequently asked questions
When should the briefing arrive?
The morning of the meeting, not at the moment of booking. A briefing sent three weeks ahead is read and forgotten, and the point is for the information to be present when somebody is about to walk into the call.
How do I handle reschedules?
Treat the cancellation and the new booking as one event rather than two, matching on the invitee. Otherwise the automation sends a we-are-sorry-you-cancelled message to somebody who simply moved the meeting to Thursday, which reads badly.
Can it route bookings to the right person?
Calendly's own routing handles what its forms capture. Where the decision depends on data Calendly does not hold — existing account, territory, current load — that needs an external automation, which can reassign or flag after the fact.
How do I track no-shows?
Calendly cannot tell you, so the attendance signal has to come from your conferencing tool, your calendar, or a person marking it. Without one of those, the no-show rate is unmeasurable, which is why most teams have a vague impression rather than a number.
Should the automation send the follow-up?
Prompt the person to write it rather than writing it for them. A follow-up after a real conversation should reference what was actually discussed, and a generic one sent automatically is worse than a late personal one.
Can I use the booking form answers?
Yes, and they arrive as text, so handle variation rather than assuming a format. They are the most useful part of the payload for routing and briefing, which is a good argument for asking one or two well-chosen questions rather than none.
What about meetings booked outside Calendly?
They will not appear, which is worth knowing before building reporting on booking volume. An automation reading the calendar as well as Calendly gives a complete picture, at the cost of distinguishing meetings from everything else in a calendar.
How do I handle bookings from existing customers differently?
Check the CRM at booking and branch on what you find. An existing customer booking a sales call is usually an expansion conversation or a problem, and either deserves different preparation from a new prospect, which is a distinction Calendly cannot make on its own.
What should the briefing contain?
Enough to walk in informed and not so much that nobody reads it. Company, role, relationship status, anything open elsewhere, and what they said when they booked. One screen. The temptation is to include everything, which produces a briefing people skim and then look things up anyway.
Can it help with interview scheduling?
Yes, and the preparation half is where the value is: the CV attached, the interview guide, and confirmation that the panel has what they need before the call. Scheduling was never the hard part of interviewing.
Should cancellations trigger anything?
A short, warm offer to rebook, once. Most cancellations are timing rather than disinterest, and a single message recovers a meaningful proportion. What it should not trigger is a sequence, since somebody who cancelled has already told you something about their availability.
How do I know a briefing was useful?
Ask, after a fortnight. The person taking the calls will tell you immediately which parts they read and which they skip, and that conversation improves it more than any amount of guessing. A briefing nobody reads is worse than none, because it looks like the problem is solved.
Can this work across a whole team's booking links?
Yes, with organization-scoped access rather than one person's token. The thing to decide is whether preparation should be uniform across the team or differ by event type, since a demo, a support call, and an interview need very different things in front of the person taking them.
What should happen if the contact cannot be matched?
Create a flagged record rather than attaching the meeting to the nearest plausible company. A meeting logged against the wrong account is harder to find and unpick later than one sitting in a review queue, and the queue is short enough to work through daily.
Should preparation differ for repeat meetings?
Yes, and briefly. A second or third call with the same person needs what changed since last time rather than the full background again, which is a different automation with a much shorter output and considerably more value per word.