Arranging one meeting by email takes a little over eight messages and usually runs across days, and most of those messages settle nothing. The move that collapses it is to put the decision in the first message: offer real times from a calendar you have already checked, so the only reply anybody owes you is a choice.
- The eight is measured rather than guessed. A year-long deployment that ran scheduling for 178 people handled 15,659 emails across 1,894 meeting requests.
- Almost none of that cost is typing. What it costs is elapsed days, and the work of picking the thread back up each time.
- One round trip is most of a working day even when the other person has nothing to write.
- Two of the eight messages are load bearing. The other six exist because the first one asked a question instead of making an offer.
Eight messages, and what each one is for
The number comes from Calendar.help, a scheduling assistant built and deployed by Microsoft Research and written up by Justin Cranshaw, Emad Elwany, Todd Newman, Rafal Kocielnik, Bowen Yu, Sandeep Soni, Jaime Teevan and Andrés Monroy-Hernández in Calendar.help: Designing a Workflow-Based Scheduling Agent with Humans in the Loop, presented at CHI 2017. People cc’d an assistant called Cal on a meeting request and Cal took the thread from there.
In the final field study, running from 5 April to 25 August 2016, 178 participants delegated 1,894 meeting requests involving 1,981 invitees, and Cal sent and received 15,659 emails doing it. That is a little over eight messages per request. It is a real count of real correspondence, from an era of ordinary mail clients and ordinary calendars, and the meetings were mostly small: 84% were one to one, and 15% had three or more people.
Eight is also what you get if you write out the ordinary version by hand.
- You ask whether they have time in the next couple of weeks.
- They say yes, and ask what suits you.
- You offer Tuesday or Thursday morning.
- They can do Thursday, but not before ten.
- You suggest half past ten.
- They confirm.
- You send the invitation.
- They accept it.
Read down that list and notice how little of it is information. Messages one and two establish that two people who already wanted to meet still want to meet. Message three is the first that contains a time. Messages four and five are a negotiation that could have been avoided by knowing one fact about their morning. Only six carries a decision, and seven and eight are bookkeeping.
The same paper puts a number on the effort inside all this, and it is small. When a request went smoothly, the whole of it consumed 2.6 minutes of an assistant’s working time. So the problem was never that scheduling is laborious. Two and a half minutes of attention, spread over eight arrivals across four days, is a different thing from two and a half minutes.
Why it takes days rather than minutes
A round trip in email is not fast, and it is not fast even when the reply requires no thought.
Doodle, the scheduling company, published the State of Meetings Report 2019 (checked 19 August 2026), built from a survey of 6,500 professionals in the US, UK and Germany alongside 19 million meetings arranged on its own platform. Buried in it is the most useful measurement in the whole subject. Across more than 19 million responses to invitations sent in 2018, Doodle worked out how long people took to confirm or decline. The three fastest countries averaged between five and a half and six hours. The three slowest averaged between ten and eleven.
Hold on to what that measures. A Doodle invitation asks nothing of the recipient except to tick the times they can make. There is no message to compose, no calendar to reason about, no politeness to get right. And the average turnaround is most of a working day. It is a vendor reporting on its own users, who opted into a poll and were therefore already cooperating, which if anything makes the number generous.
Now put your eight messages on that clock. Four round trips at half a day each is two working days if everything lands cleanly, and there is no reason it should. Message three arrives at four in the afternoon and gets answered the next morning. Message five arrives on a Friday. The Calendar.help engineers say it plainly in their own implementation notes, describing why the system had to keep old versions of its workflow running: meeting requests, they write, “typically take days to complete”.
The other cost is the one nobody counts. Each of those eight arrivals lands in a different hour of a different day, and each time you have to remember what was proposed, what was ruled out and whose turn it is. The thread is a small amount of state you are storing in your head across half a week. That is why a scheduling chain feels heavier than its two and a half minutes, and why three of them running at once feels heavier still.
The move: decide in the first message
There is one structural change, and everything else is detail. Stop asking when somebody is free and start telling them when you are.
- You: “Happy to talk this through. I have Thursday at 10:30, Thursday at 2 or Friday at 9, all UK time. Say which and the invite will follow.”
- Them: “Thursday at 10:30.”
Then the invitation goes out, which is not a negotiation and does not need a reply to be useful.
The reason this works is not politeness or brevity. It is that an open question cannot be answered with a decision. “When are you free?” can only ever produce information, which you then have to compare against your own calendar, which produces a proposal, which they then have to accept. That is three round trips before anybody has agreed to anything, and it is three even when both people behave perfectly. A proposal needs one. You are not making the messages shorter, you are removing the rounds in which nothing is settled.
Three times is about the right offer. Jaeyoon Song at MIT, Zahra Ashktorab at IBM Research and Thomas W. Malone at MIT set out the constraint precisely in Togedule: Scheduling Meetings with Large Language Models and Adaptive Representations of Group Availability, published in Proceedings of the ACM on Human-Computer Interaction in 2025: “the number of choices that can be effectively handled in a single email is limited, often resulting in multiple email threads going back and forth until an acceptable meeting time is agreed upon and details are finalized”. One option is an instruction and invites a counter-offer. Ten options is a spreadsheet, and their experiments found that people asked to consider a long list simply stop reading part way down. Three is enough that a no is unlikely and few enough that it reads as an offer.
What makes the move hard is not writing it. It is that a proposal has to be true. The moment you name three slots you are asserting that you are free in all three, which means you have to know what is in your calendar, including the calendar you keep separately from work and the appointment you agreed to on the phone and never wrote down. Guessing produces the worst outcome available: they accept a time you cannot make, and now you are rescheduling, which costs more messages than the ones you saved. If your availability is spread across more than one calendar, that reconciliation is the actual bottleneck, and two calendars is about closing it.
Two neighbouring pieces carry the rest. How the proposal is worded, and what belongs in the invitation so nobody has to write back asking, is writing the invitation. Naming the times in a way that survives the recipient being three time zones away is time zones.
Where the eight messages actually go
Here is the part most advice about this leaves out. The eight messages do not vanish. They get moved.
Cal, in the field study, sent and received all 15,659 of them. What changed for the 178 participants was not the volume of correspondence but their share of it. The authors are direct about the design goal: “Although Cal may send many emails in the process of scheduling a meeting, individuals only see a small slice of the total communication.” The chain still happened. Somebody else was in it.
That gives you three honest options, and they differ in who absorbs the traffic.
You write a better first message. Costs nothing, works immediately, and depends entirely on you knowing your own availability at the moment you write. This is the one that turns eight into two, and it is available today with no tool at all.
You publish your availability and let people pick. A booking page moves the negotiation out of the mailbox altogether: they see times you are genuinely free and choose one. It is the strongest version of deciding in the first message, because the decision mechanism travels with the message. It also carries a social cost that varies a great deal by who is receiving it, and booking links is where that judgment gets made properly.
You delegate the thread. To a person, or to software that runs the correspondence on your behalf. This is what Calendar.help was, and it is what a meeting scheduler working inside your mailbox is trying to be. The traffic stays roughly the same size. You stop being the one holding it.
Notice that only the first of those is free. The other two are asking somebody or something else to carry state across days, which is precisely the part that was expensive.
When somebody still has to arrange it by hand
Calendar.help was built by a competent team with a real budget, ran for eighteen months, and the honest headline from the field study is this. Of the requests it received, 39% were completed entirely inside its automated and structured workflows. The remaining 61% needed a human being to step in somewhere before the meeting was booked.
The reasons they recorded are worth reading, because they are not a list of bugs.
- An attendee replied in a way the workflow did not expect, or replied more than once: 32%.
- None of the proposed times worked for everybody: 27%.
- The system timed out waiting for somebody to answer at all: 26%.
- The organiser’s calendar could not be read: 7%.
Every one of those is a moment where a judgment is owed. If nobody can make any of your three times, somebody has to decide what gives: the week, the attendee list, the length of the meeting, whether it needs to be a meeting. If an invitee has gone quiet, somebody has to decide whether to nudge, wait or telephone. If a reply says “Thursday works but can we make it 45 minutes and can Sarah join?”, that is not a parsing problem. It is three decisions arriving in one sentence.
The Togedule authors, writing eight years later with far better language models available, reach the same conclusion and give the reason: “there is yet no tool that fully automates the whole scheduling process since it is often difficult for agents to understand all the nuances and complexities of what people want”. Their more specific version is the one that will be true for a long while yet. “Online calendars may lack comprehensive information, such as unrecorded appointments or undisclosed preferences, necessitating human participation to finalize the meeting time.” Your calendar does not know that you do not take client calls before ten on a Monday, or that this particular prospect gets the good slot.
So the target is not a system that never involves you. It is a system where the ordinary case costs you nothing and the awkward case arrives already worked out. Calendar.help measured that gap too: a request handled inside the workflow took 2.6 minutes of work, while one needing a person took 19.3 minutes, roughly seven times as much. The seven-fold cases are the ones with a decision in them. Being handed those, with the constraints gathered and the options laid out, is the good outcome rather than the failure. It is what a competent assistant does, and it is what you would want from a person.
What collapsing the chain does not do
It does not make a slow correspondent fast. If somebody takes three days to answer their mail, they will take three days to answer a well-formed proposal. What you have removed is the two further three-day waits behind it.
It does not make the meeting worth having. A proposal that lands cleanly can book something that should have been four sentences of email. The Doodle survey found professionals spending around two hours a week in meetings they considered pointless, and none of that is a scheduling problem.
It does not survive somebody changing their mind. An agreed time is a decision with a short shelf life, and the messages you saved arranging it can all come back when it moves. That is a different job with its own repair, covered in moving a meeting and, from the other side, when they ask to move.
It does not suit every recipient. For a prospect deciding whether to work with you, three named times read as attentive. For somebody who has just been referred to you by a client, a bare link can read as though their time is the cheaper of the two. Same mechanism, different room.
How Point handles the back and forth
Point is a full email client, so the thread and the calendar are the same surface rather than two applications you reconcile by hand.
When a meeting needs arranging, you say so on the thread in plain words. Point checks your calendars, reconciles them, and proposes times you are actually free, so the first message out already carries a decision rather than a question. From there Point runs the back and forth itself: the replies come to Point, and you are brought in when there is something to settle rather than at every leg. Once a time is agreed you approve it and the invitation goes out with everyone on it, written to your real calendar. Point works across time zones, and picks up a request to move something even when it is buried three paragraphs into a reply about something else.
If you would rather people booked you directly, Point can publish a page showing times you are genuinely free, so a client picks a slot without a message being written in either direction.
Scheduling has its own autonomy setting, separate from everything else Point can do. Out of the box it sits on review, so the times Point proposes and the invitation Point writes both come to you first, and you raise the setting once you have watched a few threads run. At the top of the dial the correspondence is handled outright. What Point did is recorded in order as it happens, and undoing works from that record, with the ordinary limit that an invitation already sitting in somebody else’s calendar has to be withdrawn rather than erased. The benefits page covers what Point does with the rest of a mailbox.
Common questions
How many emails does it take to schedule a meeting?
A little over eight, on the only large public count of it: a Microsoft Research deployment that arranged 1,894 meetings for 178 people and handled 15,659 emails doing so, in 2016. Write out the ordinary version by hand and you land in the same place. Two of those eight carry a decision. The rest exist because the opening message asked when somebody was free instead of telling them when you were.
What is the fastest way to schedule a meeting without going back and forth?
Put the decision in the first message. Offer three specific times you have already checked against your calendar and say the invitation will follow, so the only reply needed is a choice. This is not a matter of writing more briefly. An open question cannot be answered with a decision, so it costs three round trips before anything is agreed, and a proposal costs one.
Should I propose times or send a booking link?
Both put the decision in the first message, which is the part that matters. A link does it more completely, because the calendar check and the confirmation travel with it. What differs is what the recipient reads into it, and that varies with who they are and how the introduction happened, which is a real judgment rather than a preference.
Can a meeting scheduler work inside Gmail rather than as another app?
It has to, if the point is to remove messages. Scheduling is a conversation, so a tool that lives beside the conversation removes the step where you copy times out of one window and into another, and it is the only place the constraint sitting in paragraph three of somebody’s reply can be seen at all. A scheduler that is a separate site can still publish your availability, but it cannot read the thread.
Why do I still end up arranging some meetings myself?
Because roughly six requests in ten contain something a workflow cannot decide. In the Calendar.help field study, 39% completed entirely inside the automated workflows and 61% needed a person somewhere along the way, most often because an attendee replied unexpectedly, because none of the offered times worked for everybody, or because somebody never answered. Those are decisions rather than defects, and the work is being handed to you at the point where your judgment is what is missing.
Does this remove the eight messages or just move them?
Mostly it moves them. When a booking link or an assistant takes the thread, the correspondence still happens, it just stops being yours to hold. The Calendar.help team designed for exactly that, writing that although their assistant sent many emails per meeting, people “only see a small slice of the total communication”. The one version that genuinely removes messages is the first one: a proposal that leaves nothing to negotiate.
The short version
Arranging a meeting by email costs about eight messages and a few days, and the cost is not the typing. It is that four round trips at half a working day each spread a two-minute task across a week, and that you rebuild the thread’s state in your head every time it comes back. Six of those eight messages exist because the opening one asked a question. Replace it with an offer of three real times drawn from a calendar you have actually checked, say the invitation will follow, and the ordinary case ends in two.
The rest is deciding who carries the messages you did not remove, and accepting that six requests in ten will still contain something with a judgment in it. Being handed those with the work already done is the goal, not a shortfall. Which meetings are awkward depends on the work. A first call with a prospect for a consultancy is not the same animal as a recurring session for a coaching practice, and the trades Point is built for each have their own version of it.