Google Calendar Busy Slots Not Being Detected

Questions
, , ,
1

:bullseye: What is your goal?

My goal is to identify why my AI receptionist isn’t detecting busy time slots from Google Calendar/Cal.com and to fix the scheduling workflow so it only offers and books genuinely available appointment times.

:thinking: What is the problem & what have you tried?

I’m building an AI receptionist using Bland.ai, Make.com, Google Calendar, and Cal.com. The AI checks availability through Google Calendar/Cal.com and books appointments, but I’m having issues with the scheduling workflow. Although events are created in Google Calendar and appear correctly in Cal.com, the availability and booking logic aren’t behaving as expected. Specifically, no matter what date and time the caller requests, the available time slots returned for that time frame never appear as busy, even when there are already existing events in Google Calendar. I need help identifying where the workflow is breaking and ensuring appointments are checked and booked reliably across all services.

3

I had something similar a few times, so here’s my two cents

Before changing anything, try this to debug:

  1. Put a real event on the target calendar
  2. Run just the availability node, not the whole flow
  3. Look at the output log. If it comes back busy, your read is fine and the problem’s
    downstream (how you parse it, or Cal handing the slot).
    If it comes back free, the check itself is blind

Don’t forget to make sure the Google Calendar those events sit on is toggled for conflict checking. If it’s not ticked, Cal will keep offering times that are already booked.

Let me know what you find out.

4

Hey there,

could you please share some screenshots of the scenario you have so far and what the inputs and outputs look like? Is it an agent and is the agent calling the google calendar tool at all? Or is it a deterministic scenario?

6

this is almost always one of two things in my experience, and both are annoying to spot.

first thing id check is timezones. bland, make, google cal and cal.com can each be sitting in a different tz and it only takes one mismatch for the whole thing to read a booked slot as free. if the caller asks for 2pm and make is reading the calendar in UTC, your 2pm busy block looks empty to it. make sure every module is explicitly set to the same tz, dont trust the defaults.

second, and this is the bigger one, you probably have two sources of truth fighting each other. if google calendar AND cal.com are both deciding availability they drift. pick one as the boss. if cal.com does your booking, let cal.com own availability too and read google in as an external calendar, dont have make separately querying google and trying to reconcile. thats usually where the “books times that arent free” bug actually lives.

also if youre using a search-events module and eyeballing overlap, swap it for the actual freebusy query. its built for exactly this and handles all-day/recurring stuff that breaks manual overlap checks.

last thing, add a re-check right before it books. the availability you read at the start of a call is stale 3 min later when the person is still talking. query again at the moment of booking so two callers cant grab the same slot.

i build these voice receptionist setups so ive hit this exact one, happy to look at your scenario blueprint if you want a second pair of eyes.

7

This exact issue usually boils down to how the date-time string is being parsed between Bland.ai and your Make.com routing logic. If Google Calendar doesn’t receive a perfectly formatted ISO 8601 string (YYYY-MM-DDTHH:mm:ssZ), the ‘List Events’ or ‘Check Availability’ module defaults to a blank check, making the system think every slot is wide open.

Here is exactly how to fix the routing architecture in Make.com:

  1. The Parsing Fix: Inside your Make.com Webhook intake module, wrap your Bland.ai date variable in a format formula to force compatibility. It should look like this: {{formatDate(webhook.date; "YYYY-MM-DDTHH:mm:ssZ")}}.

  2. The Buffer Trap: Ensure you are checking primary as the Calendar ID. If you are accidentally pointing to a secondary calendar ID string, it will return 0 busy blocks even if your main calendar is completely full.

  3. The Data-Type Split: Ensure Bland.ai isn’t sending a generalized text string like “tomorrow at 5.” Use Bland’s structured data extraction tools to isolate the exact appointment_time integer before hitting Make.