Move the thread to a calendar invite

There is a point in a good thread where more writing stops helping. The questions have been answered, the interest is real, and the only useful next step is a time on a calendar. Sending the invitation there asks for something an ordinary follow up never does: an answer the recipient has to give deliberately.

That answer happens to be one of the best specified signals in email. Three standards track documents define what an invitation contains, what a reply may say, and how both travel through a mailbox. Read with what Google and Microsoft publish about their own calendars, they say precisely what an accepted invite means and where a reply goes missing.

A reply with five defined values

RFC 5545, the iCalendar specification, gives every guest on an event an attendee entry, and every entry carries a participation status. For a meeting the permitted values are NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE and DELEGATED. The default, when nothing has been set, is NEEDS-ACTION, and applications are required to treat any status they do not recognize the same way they treat that default.

That is worth sitting with. An unanswered invitation is not a hole in your data. It has a name, it is the specified starting value, and every calendar in the chain agrees what it means. An unanswered email offers nothing that tidy.

The same document defines an RSVP parameter, which an organizer sets to TRUE to request a participation status reply from a guest. Its default is FALSE. If nobody asked for a reply, a guest list sitting at NEEDS-ACTION is the specified outcome rather than a verdict on your meeting.

The invitation is an email, and so is the answer

RFC 6047 is the piece that makes calendars work between companies. It binds the scheduling protocol to ordinary mail: the event travels as a text/calendar body part inside a normal message sent over SMTP, with a method parameter on the content type saying whether this is a request, a reply, a cancellation, or one of the other operations.

RFC 5546 defines those operations. An organizer can send PUBLISH, REQUEST, ADD, CANCEL and DECLINECOUNTER. A guest can send REPLY, REFRESH and COUNTER, the last of which is how proposing a different time is expressed. The same document notes that a guest is free to forward an invitation on, so an organizer may receive a reply from somebody who was never on the original request, which it calls a party crasher.

Two practical consequences follow. The answer you care about lives inside the attachment: RFC 6047 says the organizer and attendee cannot be reliably inferred from the Sender or Reply-To header, and that the relevant address must be read from the text/calendar part itself. And a calendar message can be authenticated only when it has been signed with S/MIME, on which the specification is blunt, since unsigned messages may not be trusted. Very little ordinary business mail is signed.

Only the respondent has the authorization to indicate their status to the organizer. The standard that carries invitations over email puts the whole design into that one sentence.

Where an RSVP goes missing

Google's own guidance for organizers is candid about the limits. Every event carries a setting called Get an email when guests respond. Switch it off and you stop receiving the acceptance mails, and you also stop receiving RSVP statuses from third party users such as Outlook, along with automatic replies such as out of office messages. Google spells out the result: accept, decline and tentative still show in the guest list for guests on Google Calendar, and you cannot check the RSVP status for guests using other calendars.

Microsoft documents a matching set of edges. In its note on meeting responses, external users outside your tenant cannot see responses at all, and responses are not visible in applications other than Outlook. Timing matters too: for meetings under fifty attendees a change can take fifteen minutes to appear, and for larger ones up to a full day. One more wrinkle is worth knowing. A guest can accept while choosing not to send a response, and that choice is still tracked for the organizer in every Outlook client except classic Outlook for Windows.

Then there is whether the invitation reached a calendar at all. Google Calendar lets a recipient decide whether invitations are added from everyone, only when the sender is known, which means somebody in their contacts, in their organization, or someone they have interacted with before, or only once they answer the email. A first invitation to a stranger may therefore sit in a mailbox instead of appearing on a calendar, which is the recipient's setting working as intended.

Sending an invitation people can answer

• Ask for the reply. The RSVP expectation defaults to FALSE in the specification, so confirm your client requests a response before reading anything into a quiet guest list.
• Send from the address the thread is already on, and put that address on the invitation, since a reply is matched to the attendee entry rather than the message header.
• Propose a time rather than asking for one. A guest who cannot make it can counter with a different slot, which Google Calendar offers on events with up to 200 guests that are not all day.
• Keep anything private out of the response note. Google warns that a note added to an RSVP is visible to all invitees.
• Treat a tentative as real information. A person chose a defined value, and it usually says the time is wrong rather than the meeting.
• Check the guest list on the day, not only your inbox. A reply that crossed between two calendar systems may have updated one of them and not the other.

This is the register Fast Mail Tracker works in. It keeps the open, click and reply history for a thread in one place, so you can see when a conversation has warmed up enough to be worth an invitation. What happens after the invite goes out belongs to the calendar, which reports it better than any pixel could.

Most of the measurement trouble in email comes from reading a signal the recipient never chose to send. An RSVP is the opposite case. Somebody looked at a proposed time, decided, and pressed a button built to carry that decision to you. When a thread is ready, that is the message worth sending.