Reconciling your calendars settles the reading. Every calendar you keep gets consulted before anything is offered. New events are created in one of them. None of them is a copy you keep by hand. Reconciling more than one calendar is where that gets built, and everything below assumes it.
What stays open is which one. That’s a bigger question than it sounds, because reading a calendar and writing to one work differently.
Reading adds up, and you can undo it. Connect a fourth calendar and your open hours get a little thinner. Disconnect it and they come back, with all four calendars exactly as they were. Writing settles. An event lands on exactly one calendar, inside exactly one account. From that moment the account is part of the meeting. It’s the address the invitation came from. It’s the mailbox the answers arrive in. It’s the only place a change to the meeting can properly start. Decide later that the event should have gone somewhere else, and you’ll find that moving it runs in one direction only.
So this part is about the write. Where a set of times comes from when it leaves your outbox. Where a hold has to sit so the same hour goes out once. Which calendar a meeting gets created on when you have three that could take it.
What an emailable calendar has to do
The request usually arrives in one of two sentences. “Send me your calendar.” “Can you email me your availability?” They sound like the same ask. Three different objects can answer them, and that’s most of why this feels harder than it should.
Times typed into a message. Two or three hours, written out by hand. This is what finding a slot without the email chain produces. On its own it goes stale, stays open to everyone, and settles nothing, for the reasons the last part sets out. It’s also the only one of the three that costs nothing to make accurate across several calendars, because you’re the one doing the reconciling.
A copy of the calendar. A file attached to a message, or a picture of next week. It’s accurate at the instant you send it and never again. It has a second problem people notice too late: it shows events. They asked what hours you’re free, and you sent them a list of who you’re meeting.
A live set of times inside the message. A block of hours the reader can choose from, still connected to a calendar, which books when they pick one. This is the object people are picturing, and it’s the one worth having.
The test for whether yours is worth sending is what composed it. A live set of times drawn from one of your three calendars is a confidently wrong answer that stays wrong all week. A photograph you knew was a photograph leaves you better off than that.
Take the word calendar in the request literally for a second. What the person wants is about one sentence of it, aimed at them, still true on Thursday.
The built-in ones answer for one account
Both large mailboxes now ship a version of the third object. What each one covers is written down, so you can check it before you rely on it.
Google’s help page for offering times to meet in a Gmail message states three things plainly. “You can only schedule meeting times on your primary calendar.” “When you offer time slots you’re available to meet, others can book them for 30 days through the booking page.” And “You can use this for 1:1 meetings. If your email has multiple recipients, only the first person who books can join the event” (all checked September 6, 2026).
Read in order, those give you the shape of the instrument. It writes to one nominated calendar. The offer stays live for a month. It’s first past the post.
The first sentence is the one that matters here. Primary calendar means the calendar that came with the account you’re composing from. Say your practice runs on a Google account and your second business sits on a Microsoft tenant. Times offered from the first speak for part of your week, in a message that reads like it speaks for all of it.
Microsoft’s mobile apps carry an equivalent. Its page on sending your availability by email describes choosing blocks of time and says the result “will be included when you send the email”. It stays quiet about which calendars those blocks were checked against (checked September 6, 2026). That silence is the useful part. The question you most need answered about a sendable calendar is what it consulted. From inside one account there’s one calendar to consult, so the documentation leaves the question where it lies.
Sharing a calendar comes up as an answer to the same request, and it’s a different object. It’s a standing subscription rather than something you send. That suits a colleague or an assistant who needs to see your week every week. A client who asked one question on a Tuesday gets nothing from it. The permissions that govern it are covered properly in the reconciliation piece.
The built-in tools are well made and they’re free with the mailbox. What’s at stake is scope. Each one answers from where it’s standing, and if you keep one calendar, where it’s standing is the whole truth.
The account that wrote it owns it
This is the choice worth making carefully, because you get one attempt at it.
Once a meeting exists it belongs to the account that created it. Both platforms will hand that role to somebody else, and both draw the same line around where it can go.
Microsoft’s page on changing the organizer of a meeting says “You can only select one new organizer and they must be within the same organization or tenant”, that “The new organizer must accept the request before the organizer changes”, and that “Currently you cannot change organizer for online meetings”. Google’s page on transferring calendars or events says “For work or school accounts, the new calendar owner must be in the same organization”, and separately that “You can’t transfer your primary calendar” (all checked September 6, 2026).
Both were written for the case they were designed for, which is a colleague leaving or a project changing hands. Read them as somebody holding a personal account, a business account and a seat on a client’s system, and they say something narrower and more useful. The transfer works inside an organization, and not between them. Your accounts are different organizations. A meeting created from the wrong one stays on the wrong one. If it’s a video meeting, which most first conversations are, Microsoft says it can’t be transferred at all.
There’s a remedy and it’s a manual one. Cancel the meeting. Send a fresh invitation from the account you meant to use. The client gets a cancellation notice, then an invitation ten seconds later, which is a small and specific impression to make on somebody who hasn’t met you yet. On their side it reads as a cancel and a rebook, and what that costs you in acceptances is set out in moving a meeting without restarting the negotiation.
So the decision about where to write happens before the event exists. That’s the moment it’s yours to make.
Hold where the meeting will be created
The last part ended on a hold sitting on one calendar while the rest of your week carried on somewhere else. There’s a second version of that, and it lands after the client says yes rather than while they’re deciding.
Watch the sequence. You place a tentative block on Thursday at ten on your business calendar, because that’s the calendar you were looking at. The offer goes out. The client picks it. The booking tool, or the other mailbox, or your phone with the wrong account open, creates the meeting on the personal calendar. You take the hold off the business one, because the hold has done its job.
Your business calendar now says Thursday at ten is free. The meeting is over on the personal one. Everything that answers from the business calendar, including you on Friday, offers that hour to the next person, and your memory is the only thing standing between that and a double booking.
The rule is one line and it survives any number of calendars. Hold on the calendar the event is going to be created on. When those are two different calendars, the hold does about half of what you think. It keeps you clear during the wait, then hands the hour back at the exact moment it stopped being available.
This slips past people because a hold and a booking usually come from two different actors. You place the hold by hand. Something else writes the meeting. Each works alone, and the mismatch goes unreported. There’s a check that takes ten seconds and finds it. Next time a booking lands, open the calendar you expected it to skip. If it’s there, your holds and your writes have been going to different places for a while.
Give the hold its expiry when you place it, which the last part argues for on its own terms, and the mismatch ends on its own, even the times you miss it.
Choosing which calendar answers for which person
Four questions decide it. You answer them once per kind of relationship, rather than once per meeting.
Which address should this arrive from? The invitation carries the account that sent it. Write a client meeting from a personal address and the client has your personal address. Write a coaching session from an account your household also uses and that client’s name lands somewhere it was meant to stay out of. For a practice this is a data question as much as a presentation one, and what confidentiality asks of an AI inbox is the same question at full size.
Who is going to need to change it? If a colleague, an assistant or a co-director may have to move this meeting, it lives where they have permission. If the answer is only ever you, write it where your access is permanent, which means a calendar of your own rather than a seat on somebody else’s system.
Where is the reply going to land? Acceptances go to the writing account. So does the sentence that actually matters, which is somebody asking on Wednesday whether Thursday could become Friday. If that arrives in an account you open twice a week, your meeting is being renegotiated in an inbox you visit twice a week. What to do when they ask to move it assumes you saw the request.
Who else has to be able to see it? A working session written on a client’s calendar is visible to their people, which is often the entire point. The same session written on yours shows as a private block, and somebody on their side books over it.
For most people the answers settle into something like this. One business calendar takes everything client-facing. The personal calendar writes only what involves you alone. A seat on a client’s system writes the meetings that are internal to that client. The household calendar writes what the household needs to see, which is usually a block with no name on it.
If you answer all four the same way every time, that’s worth noticing. You have one writing calendar, plus some calendars that are read. That’s a simpler thing to run. The reconciliation piece is the whole of what you need, and the rest of this section is overhead you can put down.
Everything else that can write in your name
The calendars are the easy inventory. The harder and more useful one is the list of things allowed to create an event with your name on it. That list runs longer than most people’s estimate, and it’s where the surprises live.
The booking page. It writes to one calendar you nominated, possibly two years ago, possibly on a laptop you’ve since replaced. Whether it also checks your other calendars is a separate setting from where it writes, and the two get confused constantly. The wider case for and against publishing one at all is booking links that show real availability.
The video platform. Some of them create their own entries, and a few create a calendar of their own to put them in, which then arrives in your week looking like something you set up.
The practice or coaching software. A client books a session in a system of its own, and the session appears on whichever calendar that system was connected to. This is the commonest source of a meeting that exists, is real, and sits out of sight from the place you look.
A delegate or an editor on a shared calendar. In Outlook these are two different jobs. Microsoft’s page on sharing a calendar with edit or delegate permissions says “Delegates can not only edit your calendar, but they can also schedule and respond to meetings on your behalf”, and that “Delegates can only be assigned to your primary calendar”. Editors, it says, “can be assigned to your primary calendar (named “Calendar”) or to any additional calendars that you created”. It also notes that “Messages sent with Send on Behalf permissions include both the delegate’s and your names next to From” (all checked September 6, 2026). Two things follow if you share calendars this way. Somebody scheduling for you writes to your main calendar, wherever the meeting logically belongs. And the client can see who typed it.
You, on a phone. In whichever account the app happened to open in, at the end of a call, while walking.
Take twenty minutes and write down every one of those you have, and next to each the calendar it writes to. Most people find at least one they had wrong, and the one people have wrong is almost always the one a client booked through.
Then the useful shape becomes visible, and it leans one way. Many readers, few writers. A reader costs you a slightly thinner week, and it buys you a clash you’d otherwise have walked into. A writer costs you a direction of visibility that has to be covered, a place a booking can land unseen, and one more account that might turn out to own a meeting you need to move. Where a writer earns none of that, disconnecting it is a real option, and the calendar itself stays exactly as it is.
What none of this reaches
Four limits, and the first is the one with a genuine exception in it.
Systems you can write to but nothing else can read. A client tenant that keeps availability inside itself is common, and it leaves you creating real events where your own tools can’t see them. The one repair is a plain block on the calendar that does answer for you, entered at the moment you create the meeting, carrying the hour and nothing else. That comes close to the hand-maintained copy the reconciliation piece warns against. The difference is the scope: one block per meeting, written once and left alone, rather than a second calendar you keep in step. Keep it to that and it stays honest.
Calendars you can only read. A client’s internal schedule, a co-director’s calendar, a partner’s work account. You can see that somebody is busy, and the writing still has to happen elsewhere. Where all three have to give way, the job turns into a negotiation.
Video meetings, once created. Microsoft’s own limit above is the flat one. If the account was wrong, the meeting gets canceled and reissued, and that’s the whole of the repair.
The gap between a decision and an event. Somebody replying “Thursday works” has decided something a calendar can’t see, whichever calendar it would have been. That gap belongs to the last part, and it stays the same size however many calendars you keep. It gets more places to hide in.
Writing to the right calendar without deciding every time
Point is a full email client sitting over the Gmail or Microsoft 365 mailbox you already run, and Point works on your live calendars rather than a copy of them. The reading side follows from the reconciliation. Your calendars are checked together before anything is offered, so a set of times leaving in a message is a set that survived all of them.
The writing side is the part this piece has been about. Ask for a meeting on the thread, in plain words, and Point runs the exchange. Point proposes real openings and reads whatever sentence comes back. Once a time is agreed and you approve it, the event is created on your real calendar with everyone on it. If you’d rather people booked themselves, a shared page draws on the same reconciled week, so the page and the offers agree about your Thursday.
If you run more than one business, the boundary between them is held. Each business keeps its own mail and its own record. A single switch narrows the app to whichever one you’re in, and a reply leaves from that business’s address. That’s the writing-account decision again, made once at the level of the business instead of once per meeting. Where that line runs is keeping one business isolated from another.
How much of this happens without you is a scheduling setting, held apart from the rest of your mail. It starts in the middle, so the first proposals and the first invitations wait for you before they reach anybody. Watch a few events land on the calendar you meant them to land on, which is the specific thing you’d be worried about here, and raise it when you’re ready. Wound to the top, Point carries the exchange to the limit you set, and how far the dial goes describes each position. What Point did is kept in order and undo runs off that record, reaching as far as your own systems. An invitation already sitting with a client can be withdrawn, and the client saw it arrive. Everything else Point does is the longer list, and the trades this is built for is where the shape of a practice changes the answer. A coaching practice running standing sessions from two accounts is mostly a writing-target problem, while a consultancy with seats on two client systems is dealing with organizations somebody else runs.
Now take the version where all of this went right.
The hold went on the calendar that was going to take the meeting. The invitation left from the business account, so the client has your working address and the reschedule request arrives somewhere you look. The event is on the one calendar that answers for you, and the other two show the block and keep the name to themselves. Thursday at ten is correct in every system that has an opinion about it.
Then the client writes back to say ten is fine, and that they’ll be in Denver that week.
Thursday at ten is agreed, written and visible everywhere it needs to be, and it’s still a label. What hour it names depends on where each of you is standing, and on a setting that lives on an account rather than on a person. Getting the write right is one job. Getting the hour right is the next one, and it turns on something other than the arithmetic.