An invitation is not a summary of the conversation you have just had. It is the only thing the other person will be looking at ten minutes before the meeting, on a phone, three weeks after they agreed to it. Everything they need at that moment has to be inside the event itself, because the thread will not be anywhere near them.
- The email and the event are two different objects travelling together, and only one of them lands on somebody else’s calendar. Most of what people write ends up in the half that does not.
- The empty field that costs the most is not the agenda. It is wherever the joining instruction should have gone.
- A sentence saying what the meeting is for beats a list of topics, and the evidence on that is more lopsided than the usual advice suggests.
- Nearly everything the invitation needs has already been said in the thread. Almost none of it should be pasted in.
What the other person is holding at ten to ten
An invitation gets read at three moments, and whoever writes it is usually picturing only the first.
It is read when it arrives, for about four seconds, while somebody decides whether to accept. It is read again at the reminder, on a lock screen, where roughly six words and a time are all that appear. And it is read at the moment it has to be acted on, when the person needs the room number or the link, and needs it in the next ninety seconds.
Most invitations are written to be accepted. They need to be written to be used.
The reason the event carries all of that weight, rather than the correspondence around it, is worth being precise about, because it is the one thing that explains most of the mistakes. An invitation arrives as an email, but it is not one. It is a structured object with named fields, specified in RFC 5545, the Internet Calendaring and Scheduling Core Object Specification, published in September 2009 and still the format calendars exchange events in. An event carries a SUMMARY, a DTSTART and DTEND, a LOCATION, a DESCRIPTION, an ORGANIZER and a list of ATTENDEEs. Those fields are what get copied into the other person’s calendar.
The covering note you typed in the mail window is not one of those fields. It stops in their inbox, where it will be archived by Thursday. Anything you wrote there, and anything the thread agreed, exists for the recipient only as long as they can be bothered to search for it, which at 09:58 they cannot.
So the working rule is a plain one. If a piece of information matters at the meeting, it goes in a field. If it only matters now, it can go in the message.
What each empty field costs
Every omission below produces a specific, predictable event: usually a message you then have to answer, occasionally a person in the wrong place. They are listed roughly in order of what they cost.
Where, and how to get in. This is the expensive one, and it goes missing for the most ordinary reason there is, which is that the writer already knows the answer. RFC 5545 defines LOCATION as the “intended venue for the activity defined by a calendar component”. For a video call the venue is a URL, and in October 2016 RFC 7986 added a property for exactly that: CONFERENCE, which “specifies information for accessing a conferencing system”, covering a dial-in number with access codes as readily as a video room. Joining detail has had a home of its own in the standard for a decade. Leaving it in the covering email instead produces a message at 09:59 asking for the link, which you answer at 10:02 from inside the empty call. For a physical address, the field wants the part that is not on the map: the door, the floor, the buzzer, and where a car can go.
The end time. An event carries an end, or a duration, and under-booking is the common error. An hour of conversation put into a thirty minute box is not a tidy invitation, it is a decision you have made about somebody else’s afternoon. They arranged their day around your number, so at twenty-eight minutes either you cut the useful part short or you run into whatever they booked next. Book the length you think it will actually take, including the five minutes at the start where nobody says anything useful.
The time zone. Only visible as a problem when it is wrong, and then very visible. It has its own piece: scheduling across time zones.
The title. RFC 5545 asks SUMMARY for “a short, one-line summary or headline for the calendar component”, and headline is the right word for it. It is read in a list of eleven other things, out of context, weeks later, and on a screen that will show about half of what you type. “Call” fails there. “Catch up” fails there. Something closer to “Year end handover: Merrow and Finch” survives, because it says who and what in the space available. The second cost of a vague title is that you look up at the wrong hour; the second cost of a very specific one is that the words are the most widely visible part of your calendar, readable by anyone you have given detail-level access to. A client’s name in an event title is a decision worth making deliberately, for the same reasons set out in using an AI inbox without breaking confidentiality.
Who else is on it. Two omissions live here. The first is the person who should have been invited and was not, which usually surfaces in the meeting itself. The second is quieter: a colleague on the list who cannot tell from the invitation whether they are expected to present, contribute or just listen, and who therefore prepares either nothing or the wrong thing. A line naming what each person is there for costs you eight words.
There is also a fact about the guest list that catches people out. Google’s own help page on sharing events says of the “See guest list” permission that “this is the default setting”, and adds that “Even when the ‘Guests can invite others’ permission is off, people can still add themselves and others as guests through the shared link” (checked 19 August 2026). So the addresses of everyone on an invitation are ordinarily visible to everyone on it, and the list is not a sealed one. Putting two clients who do not know each other on the same event is an introduction, whether or not you meant to make one.
You, and how to reach you in the next four minutes. The invitation is often the only artefact in front of somebody who is lost, late or in the wrong building, and a mobile number sitting in it turns a lost half hour into a two minute call. It matters more than it looks for a second reason. RFC 5546, the iCalendar Transport-Independent Interoperability Protocol of December 2009, is blunt about who owns the event: “Attendees do not make direct changes to the master iCalendar object. They can, however, use the COUNTER method to suggest changes to the Organizer. In any case, the Organizer has complete control over the master iCalendar object.” Every correction routes back through you by design, so being reachable is part of the job you took on when you sent it.
The reply. The same protocol gives an attendee four answers, ACCEPTED, DECLINED, TENTATIVE or DELEGATED, and one more move, COUNTER, described there as “Counter a REQUEST with an alternative proposal. Sent by an Attendee to the Organizer.” An acceptance is the cheapest confirmation you will ever be given and most people never look at it. Silence on an invitation is not proof that nobody is coming, but it is the only early warning you get, and it arrives days before the fact rather than at the hour. What to do about a thread that has gone quiet belongs to unanswered emails, and the threads that come back.
The reminder. Whatever alert the event carries is a default rather than a decision. For a client who agreed to this six weeks ago, a nudge the day before is worth considerably more than one fifteen minutes before, because the day before is when the preparation could still happen.
What they need to have read. If the meeting only works when somebody has looked at a document, the invitation is the last reliable place to put it. An attachment on the event travels with the event. A file linked in message four of a thread does not.
That is the logistics, and it is most of what an invitation is for. The field that decides whether the other person arrives prepared rather than merely present is the description, and it is the one worth spending a minute on.
The one sentence that does more than an agenda
The standard advice is to attach an agenda. The evidence for it is weaker than you would expect, and what is strong instead is more useful to know.
The Chartered Institute of Personnel and Development and the Center for Evidence-Based Management published Productive meetings: an evidence review in May 2023, written by Eric Barends and Denise Rousseau. It screened 618 studies and reduced them to 30, then tabulated the effect sizes for everything anybody has measured against perceived meeting effectiveness.
Two rows of that table sit a long way apart. A formal agenda correlates at r = .14 to .18. Goal clarity correlates at r = .51 to .54. The reviewers state the negative finding plainly: “although the popular literature emphasises the importance of meeting rules/procedures and the advance distribution of a formal agenda, only small correlations between these and perceived meeting effectiveness were found”.
Their definition of the thing that does work is the sentence to carry away. Goal clarity is “the degree to which attendees understand why the topics on the agenda are important, and what the meeting leader wants to achieve by discussing them”. Not the topics. Why they matter, and what you are trying to get out of them.
Two honest caveats, because the review supplies them itself. Of its 30 studies, 25 were graded level D, which the reviewers gloss as “a low level of trustworthiness”, and most were cross-sectional surveys. So this is correlation among self-reports, and the shape is worth more than the decimal. The second caveat rescues the agenda: Cohen and colleagues, in one of the studies reviewed, did find a formal agenda correlating with meeting quality, “but only when the agenda was accessible prior to the meeting”. Which is the entire argument for putting it in the invitation rather than handing it out at the table, since the event is the one document guaranteed to be in front of everybody beforehand.
So the description field wants three things, in about four sentences.
What will be decided or produced. Not the subject, the outcome. “By the end we agree the scope and the fee” is a different instruction to the reader than “Discuss scope and fees”, and it is the difference between somebody arriving with an opinion and somebody arriving with an open mind they had no reason to make up.
What they need to bring or have looked at, named exactly. “The signed engagement letter” rather than “the paperwork”.
What to do if it stops working. One line inviting them to say so is worth having, because the alternative is a person who quietly cannot make it and does not want to be awkward about it. How that conversation goes when it comes is when they ask to move.
Written out, that is short enough to read on a phone:
“Half an hour on the year end. By the end we want a decision on whether to file the extension, so I will bring the draft accounts (attached) and it would help if you have glanced at the two flagged entries. My mobile is in the invitation if anything changes.”
Four sentences. A description that runs to a full screen gets skimmed to nothing, and everything below it gets scrolled past, including the joining link.
Writing it from the thread instead of retyping it
By the time you send an invitation, every fact in it has already been written down by one of you. The work is selection, not composition, and it takes about ninety seconds if you do it while the reply is still open on the screen.
Four things are in the thread, and each has a field waiting for it.
The time you both agreed goes in the start and end fields, and nowhere else. Restating it as a sentence in the description feels helpful and is a trap: if the meeting ever moves, the fields change and the sentence does not, and the sentence is the one a hurried reader believes. That failure has its own repair in moving a meeting, and it is much easier not to plant it.
What they asked for, usually in their own words in the first or second message, goes in the opening line of the description, tightened. Using their phrasing is not flattery. It is the cheapest available proof that the meeting is about the thing they wanted rather than the thing you heard.
The document or the figure somebody mentioned gets attached or named. It was mentioned once, in passing, and neither of you will remember which message it was in.
The constraint that arrived in a subordinate clause. “I have a hard stop at eleven” sets your end time. “Sarah should probably be on this” sets your guest list. Constraints almost never arrive as their own sentence, which is exactly why they are the most commonly dropped thing between a thread and an event.
Three things in the thread should stay there.
The quoted chain. Pasting the correspondence into the description is the most common shortcut and the worst one. That field travels with the event into every attendee’s calendar, onto their phone, and into whatever else they have connected to it. A remark about a third party, a discussion of price, a client’s home address: all of it is now sitting in copies you no longer control. It is a movement of information rather than a saving of typing.
The negotiation. Nobody needs to know that Thursday was the third option offered.
The warmth. Put it in the covering message, which is where it is read anyway. An event description read at 09:55 by somebody hunting for a link is not the place for a pleasant sentence about their holiday.
Two smaller habits save more time than they look like they should. Write the invitation in the same sitting as the reply that agreed the time, because the constraint you can still remember is the one that makes it into the fields. And do not reuse the email subject line as the event title. Threads are named for a request, so they read “Re: quick question about the year end”, while events are named for what they are. Copying the one into the other is the single commonest way a careful invitation ends up with an unusable name.
The covering message itself only has one job left: say that the invitation is attached and what to do if the time no longer works. If you are still making the offer rather than confirming it, that is a different message doing a different job, and it is the one that decides how long the whole thing takes: scheduling without the email chain.
When an invitation is the wrong object
An event on somebody else’s calendar is a claim on their time, and a few things that feel like meetings are not.
A dated commitment that is nobody’s hour. “Accounts to be filed by the 14th” is a real obligation and a bad event. It blocks time that does not need blocking, it teaches everyone to ignore your invitations, and it is invisible at the moment the work would actually be done. That belongs with the rest of the dated work, in email task management, without writing it down.
A block on your own time. Perfectly sensible, but it is not an invitation and it should not be sent to anybody. What matters about it is whether it is marked in a way that stops your availability being sold out from under you, which is dealt with in booking links that show real availability.
A question shorter than the invitation. If the whole exchange fits in four sentences, send the four sentences.
A meeting somebody else’s office is arranging. When a client’s assistant runs the diary, your invitation becomes a second copy of an event they are about to create properly. Two invitations for one meeting is worse than none, because the accepts split across both and neither one tells the truth. Send them the details in a form they can lift, and let the invitation come from where the diary lives.
Sending it from the thread it was agreed on
Point is a full email client sitting on top of the Gmail or Microsoft 365 mailbox you already have, and it puts the correspondence and the calendar in one surface rather than two windows you copy between. That matters here for a narrow, practical reason: the constraint sitting in paragraph three of somebody’s reply is visible to the thing writing the event, not only to you.
Ask for a meeting in plain words on the thread and Point runs the back and forth from there, checking your reconciled calendars and putting real times in front of the other person. Once a time is agreed you approve it, and the invitation goes out with everyone on it and is written into your real calendar as a proper event rather than a note about one. It works across time zones, and a request to move something is picked up even when it is buried in a reply about something else.
Scheduling has its own autonomy setting, separate from the rest of what Point does. Out of the box it sits on review, so the times proposed and the invitation written both come past you before anyone else sees them, and you raise the setting once you have watched a few go out. At the top of the dial the correspondence runs without asking. Everything Point did is recorded in order and undo works back through that record, with the plain limit that an invitation already sitting in a client’s calendar is withdrawn rather than made never to have been sent. The benefits page covers what changes in the rest of a mailbox.
Common questions
What should a calendar invitation include?
The joining detail first, because that omission is the one that costs a message at 09:59. Then a realistic end time, a title that identifies the meeting when read cold on a lock screen, the guest list with a word on what each person is there for, a way to reach you in the next four minutes, and a short description saying what will be decided and what to bring. Everything on that list is a field on the event, which is the test: information that matters at the meeting goes in a field, information that only matters now can go in the covering email.
Where should the meeting link go?
In the event’s own fields, not in the message around it. The standard has had a dedicated property for this since October 2016, when RFC 7986 added CONFERENCE for “information for accessing a conferencing system”, and the location field held it before that. The reason to be strict is that the covering email gets archived while the event stays on the calendar, so an hour before the call the link is either in the thing they are looking at or it is nowhere.
Should I put an agenda in the invitation?
Put the purpose in, and the agenda only if there genuinely is one. The 2023 CIPD and CEBMa evidence review found a formal agenda correlating with perceived meeting effectiveness at r = .14 to .18, while goal clarity, meaning attendees understanding why the topics matter and what you want to achieve, correlated at r = .51 to .54. One sentence naming the decision does more than a list of headings. Where the agenda earned its keep in that literature was when it reached people beforehand, and the invitation is the one place guaranteed to.
Can the people I invite see each other’s email addresses?
Ordinarily yes. Google’s help page on sharing events says the “See guest list” permission is on by default, and that people can still add themselves and others through a shared link even when guests are not permitted to invite others (checked 19 August 2026). So an invitation with two unrelated clients on it introduces them to each other. When that is not what you want, the answer is two invitations rather than one carefully worded description.
Do I need to send an invitation if we already agreed the time by email?
Yes, and the agreement is exactly why. The thread records a decision in a place neither of you will look again; the event puts it on both calendars, blocks the time against everything else that will be arranged this week, and carries the joining detail to the moment it is needed. The acceptance you get back is also the only cheap confirmation available that the other person actually wrote it down.
Is it rude to send someone an invitation they did not ask for?
It depends entirely on whether the time was agreed. An invitation is a record of a decision, so sending one after a yes is bookkeeping and reads as organised. Sending one instead of asking makes the decision on somebody else’s behalf and puts them in the awkward position of declining a thing that is already in their diary. If the time is not settled yet, the message that settles it fastest is a short offer of real slots, not an event.
The short version
An invitation and the email carrying it are two different objects, and only one of them arrives on the other person’s calendar. Everything that will matter at ten to ten belongs in the event’s own fields, because the correspondence around it will have been archived days earlier and nobody searches their inbox while they are already late.
Fill the fields in the order of what an empty one costs. Joining detail first, then an end time long enough to be true, a title that identifies the meeting when it appears cold on a lock screen, a guest list with a word about why each person is on it, and a number that reaches you in the next four minutes. Then use the description for the thing the research is unusually clear about: what will be decided and what to bring, in about four sentences, rather than a list of topics nobody reads.
Nearly all of that has already been written by one of you in the thread, and the job is lifting it rather than composing it, while leaving the quoted chain firmly where it is. A coaching practice running the same session every fortnight can write one good invitation and reuse it forever, so the effort belongs in the reminder and the preparation line. A consultancy meeting four people from a client it has never visited has a different bottleneck entirely, which is the address, the floor and who is expected to speak. The rest of the trades this is built for sit somewhere between the two.