General Features

From the Organizer’s Point of View

Address Book

Unsubscribing

When You Invite People

The Invitation

Follow-ups

From the User’s Point of View

What's Wrong with Evite

If you're a host or organizer with a large invitation list like I am, you probably spend a lot of time thinking about invitation systems. I've been hosting parties since November 2002. Initially I and my secretary processed responses manually until June 2005, when I switched to Evite. (In retrospect, I cannot believe I did not use an invitation earlier than that. We were processing thousands of responses a month.) Evite was OK for a while, but over time more and more problems developed.

In 2006, I switched to Going.com (formerly known as HeyLetsGo). Various technical problems surfaced, and thus starting in May 2007, I will be trying different invitation systems. Before looking at the various system out there, I made a list of the features an ideal invitation system would have. It's amazing how inadequate literally every system on the market is. So it's not a matter of choosing a good system but rather which system sucks the least.

These are my desired features for a great system. Admittedly, it is a wish list. If you know of a system that comes reasonably close, please send me (James Mitchell) an e-mail at JMitchell@KensingtonLLC.com. If you are writing an invitation system and you are serious about designing a world-class system (one that, in the words of Steve Jobs, is insanely great), one that is much better that what is currently available, I would happy to be a consultant at no cost to you. (As my friend Brad Feld suggested, such a site could boast, "We suck less".) I have an unusually good background for this — not only do I run the most successful "high end' social group in Boston (Boston Convivium), but I have extensive experience designing and programming large commercial systems, both internal and Web-based.

When I mention “organizer,” I mean the person who is hosting the party and sending out the invitations. When I mention “user” or”guest,” I mean the person being invited who is responding to an invitation sent through the invitation system.)

General Features

• Assuming the organizer allows this, both the organizer and the user can easily view the guest list and see who is coming and who is not, with full names displayed. Ideally one could sort by last name as well as first name.
• The system is smart enough to prevent an invitation from being sent twice to the same e-mail address — e.g., if on Monday the organizer sends an invitation to jsmith@gmail.com, and a week later he adds the same e-mail address to the invitation list for the same event, the system will realize that and not send the invitation again. Ideally the system would tell him that jsmith has already been invited.

From the Organizer’s Point of View

• The organizer can change responses for guests for a particular invitation or for all invitations. This is needed because some guests have technical problems and it is easier to just record their response for them.
• The organizer can see who has viewed the invitation but not responded.
• The organizer can easily remove a guest from a particular invitation or from all invitations. At the same time, the organizer would have the choice of initiating a block which would prevent that e-mail address to be added to future invitation lists.
• The organizer should be able to easily check if someone has RSVPed to a particular event and what their response is.
• The organizer should be able to easily check the date and time someone has RSVPed to a particular invitation. If one wanted to get really fancy, the system would keep track of all responses by any particular person to a particular invitation, so you could tell if someone changed their response, and if so, when.
• The organizer should be able to check for a particular person their responses to all events he has been invited to by that organizer.
• The system should keep track of bounced e-mails, which the organizer can download. Ideally the system would keep a running total of bounced e-mails, so you could say, for example, give me all of the e-mail addresses that have bounced five time or more in a row, over more than a 30 day period. (The reason for this is that one bounceback by itself is not enough to remove someone from your list. If you receive five bouncebacks in a row, over several weeks, you can be reasonably certain that that e-mail address is no longer valid.)
• For bouncebacks, the organizer could place them on hold for a certain amount of time, say one month, and then try again. Sometimes people go away for, e.g., the Summer and then their e-mail address is good when they return.
• The site offers good technical support, including telephone support. They actually answer their phone.
• Ideally the site would be free. If not, it would be have a reasonable monthly cost, not based on the number of invitations sent.

Address Book

The system would have an address book which can store an unlimited number of names. In this address book, the organizer can track:

• Nickname
• sex (male/female, not how often you have slept with that person)
• Birth date
• Alternative e-mail addresses
• Physical address, including zip code
• Telephone numbers (mobile, home, work, work extension, other)
• Date they were entered into the address book
• Last date any information was changed
• Internal comments about the person
• Flagged for follow-up, and if so, a follow-up date
• Photos (more than one)

The organizer could maintain a master database and then have various separate invitation lists which a particular person could be assigned to or not assigned to. That way, for example, you could invite Wendy to dances and art gallery openings but not book signings, while Tom could be invited to book signings and sporting events but not dances or art gallery openings.

The organizer can place someone on hold until X date, and after that date, they would automatically be invited again to new events. In addition, the organizer should be able place someone on hold and flag them for follow-up on X date. In that case, they would not automatically be placed back on the invitation list unless the organizer decided to.

The address book should have a status field — Active, Pending, Hold, In the Future (that's being placed on hold), No Longer. Pending would mean information has been entered (at least to some extent) but you are waiting to decide whether to add them to the invitation list. No Longer would mean that the organizer can keep track of people who have asked to be taken off the invitation list, in case they ever pop up again.

The system would have additional numeric, string and date fields that were unassigned, and the organizer could use these fields to store additional information.

The data in the address book would be maintained in an industrial strength database, such as Microsoft SQL Server or MySQL. The organizer would be able to directly access the database using a query/reporting tool such as Microsoft Access or Crystal Reports, using an ODBC connection, and be able to slice and dice the data any way he wanted. Ideally the organizer would not only have read access to his database but also write access, but that may present security issues.

The organizer should be able to export all or a portion of the address book to a comma delimited (.csv) file.

Unsubscribing

• If the site permits users to unsubscribe (i.e., not receive any invitations from a particular organizer), the organizer should be able to download those who have unsubscribed, so that he can remove them from his database.
• Unsubscribing should not be a one-step process, because many people click on it by mistake. Instead, there should be a confirmation message that asks if they really want to unsubscribe.
• The organizer should also be able to initiate an unsubscribe, not just the user. That way, the organizer could say, “Do not ever send invitations to jsmith@gmail.com.”
• The user should be able to remove himself from a particular invitation.
• The user should be able to remove himself from all invitations without necessarily initiating an unsubscribe request. (An unsubscribe request initiates a permanent block.)

When You Invite People

• There are no limits on the number of guests an organizer can invite to an event — e.g., if I want to invite 15,000 people to an event, I can do so.
• If he wishes, the organizer can insert the full name and e-mail address of the guest.

The Invitation

• There is no limit to the number of characters in the invitation.
• The organizer can choose exactly what is displayed in the subject line of the invitation and follow-ups. (Many systems automatically add something like, "X has invited you to ..."
• The site has a wide choice of appealing templates from which an invitation can be greater. (The Evite system, for example, has really hokey templates.)
• The organizer can insert graphic images into the invitation — ideally as many as he wants.
• The organizer can insert HTML into the invitation. The only limits on what HTML is included are security-related (e.g., it would not make sense to permit an organizer to insert Javascript into an invitation).
• Inline and embedded styles would be allowed (although admittedly, this is more of an issue for the e-mail client than for the invitation system).
• The organizer can design his own invitation.
• The organizer can put a cap on the number of people who RSVP "Yes," and if that cap is reached, the event is closed and an e-mail is sent to the organizer letting him know that.
• Assuming that the sex of the guests is contained in the address book, the organizer should be able to set limits on the male/female ratio — e.g., if more than 60 percent of the people RSVPing are men, don't accept any more "Yeses" from men until the ration gets down below 55 percent men.
• The organizer can include data fields in the invitation, such as gender, year of birth, or other information. Ideally there would be If ... Then ... Else logic one could use in creating the invitation.
• The system should have an easy-to-use payment system so that users can purchase tickets for events that are not free. The payment system should be tied into the invitation system so that someone cannot RSVP "Yes" until they have purchased a ticket.
• The organizer can export names and responses to a .csv file.

Follow-ups

• There are no limits on how many follow-ups the organizer can send.
• The organizer can send follow-ups to any subset he wants — e.g., just to those who RSVPed Maybe, only to those who have not responded, only to those who have viewed the invitation but have not RSVPed.
• The organizer can design his own invitation.
• The organizer should be able to flag particular people so they will not receive follow-ups, even if they have not responded.

From the User’s Point of View

• It should be really easy for the user to respond. In particular, he does not have to log in.
• User has a choice of Yes, Maybe or No. (Believe it or not, there is some system out there that looks pretty good but does not offer a Maybe option.)
• Guests can see the full name of everyone who is attending and who has been invited.
• User can click on a button and add the event details to his calendar (Outlook or whatever he uses). The system would be smart enough to take the date and time information and automatically add it to the calendar.
• Many users have multiple e-mail addresses, which makes my life really fun. Ideally the user should be able to associate more than one e-mail address with his account so that.
• No need for the user to create an account or verify his e-mail address. Ideally there would be the option of creating an account or profile where one could post information and a picture of themselves if they wanted, but the user should be able to RSVP and use the system without having to create an account or profile.
• It would make sense for the system to keep track of every time a invitation is sent to a particular e-mail address, and if that address has received more than one invitation, an account would be created for them automatically and they could easily see all of their pending invitations.
• Assuming the organizer permits this when he sets up the invitation, the guest should be able to invite other people simply by entering their e-mail address. If that happens, the organizers should be able to easily see who has invited a particular person.
• Ideally there would be a master list of all the invitations the user has received, which he could see on one page, and then able to quickly RSVP Yes, No or Maybe, as well as quickly adding this to your calendar. This would be particularly helpful for my group, as most of my members are invited to a multitude of events, and they could look at all of their invitations on one Web page, rather than responding piecemeal.
• The user should be able to place himself on hold — e.g., from now until September 1, 2007, do not send me invitations. The organizer would continue to add them to various invitations but the user would not be receiving them. Then on September 1, 2007, the user would start receiving invitations, as well as those invitations he had been invited to before then for events that have not already taken place.

What's Wrong with Evite

Evite is the 800-pound gorilla of the Web-based invitation systems, and people often ask me why I no longer use them. Here are a few of the many reasons:

• Evite is not designed for large invitation lists. Their typical customer is someone who is inviting 100 friends to a party, rather than a promoter who is inviting thousands or tens of thousands of people to an event. Evite limits you to inviting 750 people to an event, unless you receive an exemption. It used to be fairly easy and routine to obtain an exemption but this has changed — I know several professional organizers who were turned down after waiting 10 days or so for Evite to make up their mind.
• If a guest unsubscribes (i.e., initiates a block so you are prevented from sending them future invitations), there is no way to download this information, so as far as you are concerned, they are continuing to receive invitations when in fact they no longer are.
• Evite limits the size of your invitation in terms of characters. They say it's 3000 but it actually closer to 2800 characters.
• Evite's address book limits you to 500 people and many essential fields are missing.
• Evite has a slow, bureaucratic software development process. I suspect this was not the case when they were a stand alone company, but they were acquired by a large company who has taken a Fortune 500 approach to software development. It can take them a year to implement a trivial new feature.
• Evite will sometimes delete responses and then have no way to recover the data. Apparently their system engineers were absent the day how to do backups was taught in school.

Read James' essay, The Mitchell Unconventionality Index.

May 6, 2007, version 1.0   |    List of other essays written by James Mitchell    |    Copyright notice

Cite as “The Ideal Invitation System” by James Mitchell. May 6, 2007, version 1.0.
www.BostonConvivium.com/jm_essays/ideal_invitation_system.