The meeting is in your calendar, the client was never told

Someone books a consultation through your website. The booking tool does its job: the slot is taken, the event is on your calendar, the client's email address is sitting there in the guest list.

Thursday at two, nobody arrives.

The reconstruction afterwards is the confusing part. The event is there. The email address is correct. There is no error anywhere. And when you finally ask, the client says they never got anything.

This is a documented default rather than a fault, and it is worth understanding exactly, because both of the obvious conclusions about it are wrong.

The event was created. That is the only thing the answer means

When software creates a calendar entry, what comes back is confirmation that an entry now exists. Guests listed, times set, identifier assigned.

Nothing in that response is a claim that anybody was told.

Google's own guide for developers makes the split explicit:

"The event you create appears on all the primary Calendar calendars of the attendees you included with the same event ID. If you set sendUpdates to "all" or "externalOnly" in your insert request, the corresponding attendees receive an email notification for your event."

Google, Create events

Two separate outcomes in two sentences. The event lands in guests' calendars. The email goes out only if you asked for it.

Somebody in Zapier's community described the resulting confusion better than any documentation could: "... i create succesfully an event and have correct email adresses in attendees. on my end i can see the correct event but why the attendees dont get any emails? i was thinking if i add the email adress of the attendees, they will get some sort of notification or invitation. Its not happening."

That is the expectation almost everyone brings, and it is not what the system does.

Not telling anybody is the default

The parameter that controls this is called sendUpdates, and the reference page for creating an event describes it like this:

"Whether to send notifications about the creation of the new event. Note that some emails might still be sent. The default is false."

Google, Events: insert

Its accepted values are all (everyone is notified), externalOnly (only guests outside Google Calendar), and none. The word false is not among them, which is a wrinkle in the documentation rather than a setting you can use. What matters for a business is the likely effect, and that is plain enough: unless the software explicitly asks for notifications, the client is very probably not emailed.

So the invitation is a decision somebody has to make, in code, on purpose. If whoever built your booking flow did not make it, the default made it for them.

This is worth holding next to the ordinary experience of using a calendar by hand, where saving an event with a guest on it puts the question in front of you. The interface asks. The automation does not, unless told.

Silence is not guaranteed either

Here is where it stops being a simple story, and where an article that stopped at the previous section would mislead you in the other direction.

Read that quote again: "Note that some emails might still be sent." The deprecated older parameter spells it out further, saying some emails might still be sent "even if you set the value to false."

So the vendor's own position is that not asking for notifications does not guarantee nobody gets one - and the reverse, an explicit "none" that still produces an email, is the kind of report that turns up whenever enough people use the parameter.

Both halves matter, and together they say something quite specific. Leaving the parameter alone does not mean "nobody will know" and does not mean "everybody will know". It means the outcome is not yours, and the likeliest version of it is that your client hears nothing.

Notifying the guest is not a thing that happens by default. It is a thing you decide, in writing.

A Google guest may see the event, everyone else sees nothing

The default hurts unevenly, and it hurts your clients more than your colleagues.

A guest who uses Google Calendar may find the meeting has quietly appeared in their calendar. Annoying, mysterious, but visible. A client using Outlook, iCloud, or a work address on some other system has no such calendar in this picture at all. For them, there was no event and no email. There was nothing.

A developer using an automation platform reported exactly this split: internal Workspace addresses "receive notifications", external addresses "do not receive notifications". That is one person's observation rather than documented behaviour, so treat the mechanism as unconfirmed. The shape of the complaint, though, matches the documented design: internal guests have a calendar the event can appear in, and external ones have an inbox that was never written to.

Your team tests the booking flow among themselves. It works, because they can all see the event. The first person for whom it genuinely fails is a customer.

Even a correct invitation can fail at the guest's end

Suppose the automation does ask for notifications. There is a second gap, and it lives in the guest's settings.

Google Calendar has a preference governing which invitations get added automatically, and one of its options is "Only if the sender is known: Events are automatically added to your calendar if the sender is in your contacts, part of your organization, or someone you previously interacted with. ... If an event isn't added to your calendar, you get an invitation email."

For a brand new client, you are by definition an unknown sender. That option is not the default, but it is the one anybody who has been spammed with unwanted invitations goes and switches on. Where it is in force, the event will not appear in their calendar on its own: the invitation email is all they get, and opening it is the step that makes the meeting real for them.

Which leads to a trap that catches thoughtful builders specifically. It is tempting to mark the guest as having accepted, so the booking looks confirmed rather than pending. Google warns against it directly:

"Warning: If you add an event using the values declined, tentative, or accepted, attendees with the "Add invitations to my calendar" setting set to "When I respond to invitation in email" or "Only if the sender is known" might have their response reset to needsAction and won't see an event in their calendar unless they change their response in the event invitation email."

Google, Events resource

Set it to accepted on their behalf, and they may end up with no calendar entry and a dependency on an email you might not have sent.

Rescheduling and cancelling have the same gap

Everything above concerns creating a meeting. The riskier half is what happens afterwards, because the same parameter appears on updating and deleting an event

• and on those pages, no default is documented for it at all.

The pattern shows up in real tools. A calendar client that has no way to pass the notification parameter on an update reschedules the meeting without telling anyone, and the workaround its users arrive at is to delete the event and create it again, so that the invitation goes out - which is not ideal. A connector for a major automation platform has the same gap in the other direction: a person added to an existing meeting through the update action is not notified.

Put those together with cancellation, where the notification parameter exists and its default is likewise undocumented, and you get the two worst outcomes in this whole area:

• The time moved and the client did not hear. They arrive at the old time, or worse, do not arrive at the new one.
• The meeting was cancelled and the client did not hear. They travel to you for a meeting that no longer exists.

Both are more expensive than a missed invitation, and both are far less likely to be tested. Booking flows get tested at the happy path. Rescheduling and cancellation get tested by customers.

Microsoft made the opposite choice

If your calendar lives in Microsoft 365, none of the above describes your default, which is a useful thing to know before you assume the habits transfer.

Microsoft's documentation for creating an event states: "When you create an event that includes attendees, the server sends invitations to all attendees. This ensures consistency between the organizer's and attendees' views of the event and can't be configured."

	Google Calendar API	Microsoft Graph
Invitation on creating an event	only if explicitly requested	always
Can that be turned off	off unless asked for; Google warns that forcing none "can have significant adverse effects"	"can't be configured"
Risk it creates	guest is never told	guest is told about things you meant to keep quiet
Where it bites	client no-shows	test data and bulk imports emailing real people

Neither choice is wrong; they protect against opposite mistakes. What is dangerous is carrying an assumption from one to the other, which is exactly what happens when a business changes email provider or connects a tool that was written against the other platform.

Two actions that look the same in your tool

Most small businesses never touch any of these parameters directly. They pick an action from a list inside an automation tool, and the choice has already been made for them by which action they picked.

Zapier documents one of these pairs plainly, in a page about common problems. Under the heading "I've added attendees using the Quick Add Event, but they didn't receive invites to the event", it answers: "With this action, invitees will be added directly to it, and no invitation is sent. If you'd like to send the user an invitation that they can accept/reject, use the Create Detailed Event action instead."

Two actions, both of which create a meeting with your client on it. One tells them. The other does not. Nothing in the name of the first one suggests that the guest will be left in the dark, and the person building the workflow reasonably picks the simpler-sounding option.

Whatever tool you use, this is the question to ask of it: does this action send an invitation, and where is that written down?

What to check in your own setup

Book yourself as a stranger. Use a personal address on a different provider, one that is not in your contacts and has never emailed you. Go through your own booking flow and watch what arrives. This single test answers most of this article for your particular setup.

Then move it, then cancel it. Reschedule the test booking and see whether that address hears about it. Then cancel and see the same. These are the paths that go untested, and they are where the damage is.

Look at responseStatus instead of the event. Every guest on an event carries a response status, and needsAction means literally that they have not responded. A guest who is still needsAction the day before is a much better warning sign than an event that exists.

Do not confirm on the client's behalf. Whatever the temptation to make the booking look tidy, marking a guest as accepted can leave them without a calendar entry at all.

Decide what the confirmation email is for. A separate "you are booked for 2pm" email is a message, not a meeting: it does not sit in their calendar, does not move when you move the appointment and does not disappear when you cancel. It is a fine addition to an invitation and a poor replacement for one - and it carries its own trap, since the time in it has to be the client's time.

Count no-shows before blaming the customer. If your rate is worse than it should be, the cause may be sitting in a parameter rather than in customer behaviour, and the usual advice about reducing no-shows assumes the invitation arrived in the first place. It is the same class of problem as a green run that did nothing: everything reports success, and the outcome never happened.

When this stops being a settings question

For a single calendar and one booking form, this is a settings question, and the tests above settle it in an afternoon.

It stops being that when the booking has to survive real life: the client reschedules, you move things around, somebody is added to the meeting, the appointment is cancelled and rebooked, and each of those events has to reach a person who does not use your calendar system. At that point the question is no longer which checkbox to tick but what your system guarantees a customer will know, and how you would find out if it stopped being true.

Working out which of those two situations you are in is what a process audit settles: $299, three business days, and a written map of every point where your booking flow assumes the customer was told something.