FindFreeTime: Coordinating Meetings and Phone Calls

Matthew McNeely also demonstrated his service at the Web Innovator's Forum. Matt has built a service called Find Free Time. Find Free Time is very similar in purpose to Meet with Approval, which I wrote about previously during event week....

The Social Networking Weblog writes a review of FindFreeTime.

Read more

Web Innovators Group - May 8th

It was great to meet everyone at the Boston Web Innovators Group last night in Cambridge. Got some really great feedback. The two most important take-aways:

1) It must integrate with Outlook/Exchange
2) While many people expressed sincere interest in signing up and using it, the sense that I got is that most wouldn't sign up for a paid subscription.

Invaluable feedback. Thanks everyone who stopped by.

Demo video

I just finished a demo video for FindFreeTime. Find it here: http://beta.findfreetime.com:9090/video.jsp . This is the first video demo I've ever done. It was a lot harder than I imagined.

Instant API! Just add water.

A decade ago I was a software engineer at ON Technology in Cambridge--working on the Meeting Maker product line. One day the requirement came down that an API was to be built and offered to our customers as a product extension. The turmoil that resulted amongst the engineering ranks was astounding. Instantly, this seemingly minor task became the proverbial hot potato. Why? Because Meeting Maker was at the time a closed and extremely complex network-based system with an arcane custom database and very lightweight datagram transport protocol. The system was designed to be closed in order to be as efficient as possible—a very valid design given the fact that the target architecture was Apple Macs. That made the task of building a flexible and easy-to-use programming interface to this complex architecture a daunting task indeed.

Fast forward ten years. Web 2.0 user interfaces, whether they are AJAX or Flash, require HTTP-based access to the host systems that supply them with information. This design yields an ‘Instant API’ in the sense that other systems can integrate with the host systems using the same HTTP-based access points. Viola! an Instant API.

Choosing an open, well-documented protocol for your communications to and from the host systems is therefore an extremely important design decision. For FindFreeTime I chose to use XML-RPC, a simple XML-based communications protocol. Most of our ‘method calls’ to our API embed entities (people, proposals, etc) as escaped XML in struct members.

I suspect that the profusion of mashups and other “feats of interoperability” that Web 2.0 services now show off have AJAX and Flash user interface designs to thank for their success.

Pricing strategy

Development is moving along nicely. I've just completed the Java and Actionscript code to handle the XML-RPC communication between the Flash interface and the Java backend. Earlier in the week I completed the Flash User Interface library which contains AS class-wrapped windows, text widgets, comboboxes, etc. I even managed to create a dynamically resizing base window for the Flash interface that automatically expands to fill the browser window. It's working nicely in both IE and Firefox--finally! It was tempting to require Flash player 7 or better, but I've managed to keep the minimum version to the version 6 player.

Switching gears abit... I've been thinking about pricing lately. At some point following our beta, we'll have to think about making some money I suppose. FindFreeTime's value proposition is that it saves those who use it time. So I've been thinking about how much time a typical person might save:

Let's say Mary is a production manager at a busy web design firm. On average she coordinates two meetings a week with her firm's clients and on occassion independent consultants working for her firm. Since these people don't have access to her firm's Outlook server, FindFreeTime is an excellent way for her to book these meetings.

Without FindFreeTime, Mary must coordinate the meetings using email. She checks her own schedule and locates some free time for the meeting [task #1; 1 min]. She composes a proposal email. In it, she lists the times she has available [task #2; 2 min]. Once all the invitees have replied, Mary reviews all the emails and finds the first available common time [task #3, 2min]. Sometimes (let's say 30% of the time), there is no common available time. In this case, Mary must retransmit the request with additional free times, possibly incorporating feedback from the invitees [task #4*, 2 min]. If there is an available common time, Mary sends out a confirmation email, possibly adding call-in information or other meeting information [task #5.1, 1 min]. If there were no available common times, Mary sends out a cancellation email [task #5.2, 1 min].

Using these estimates, we can say that the average total time spent by the coordinator is 6.6 minutes when a meeting is scheduled using email. Can FindFreeTime do better?

Task #1: Although FindFreeTime will show committed meetings, there still may be commitments or meetings planned outside of FindFreeTime. So no savings there. But, because past proposals can be duplicated with just a click, this would save Mary some time. Estimate 0.5 minutes savings.

Task #2: There is no need to list free times because the interface handles this. 1 minutes savings.

Task #3: FindFreeTime automatically (and instantly, like watching TV!) shows the common times, no thinking required! 1.5 minutes savings.

Task #4: If no common times are automatically revealed, Mary can simply open up more time using the same screen. (1 minutes savings 30% of the time or 0.3 minutes savings).

Task #5.1 and 5.2: Mary simply has to press a button to confirm or cancel the the meeting --emails with VCAL attachments are automatically sent. 1 minute savings.

Other benefits aside, we can hypothesize that FindFreeTime can reduce the time required to coordinate a meeting from 6.6 minutes to 2.3 minutes. That's over 4 minutes per meeting.

If Mary books 2 meetings every week for 50 weeks, that's a time savings of 400 minutes or 6.6 hours per year.

So what's 6.6 hours a year worth to Mary or perhaps more to the point, her employer? If we use a $20/hr salary ($41,600/yr salary), then those 6.6 hours are worth $132.

I had been thinking all along that $40 per year seemed reasonable. And I'm feeling better about it now. So FindFreeTime could be had for about the cost of a latte (with maybe a few quarters dropped in) once a month. A company wishing to provide the service for their employees should be able to prebuy their domain (maybe in 50, 100, 500, & 1000 packs) with appropriate discounting.

I've also been thinking about giving the first 250 people to sign up and book a meeting a gratis one year membership--since they'll be acting as beta users, helping to find problems, etc.

Of course, we should also offer a trial. A 10-meeting trial seems adequate.

What's in a name

Kudos to my wife, Christine Traulich, hip wedding invitation designer and former marketing professional for our name: FindFreeTime.com. I love the double meaning: finding free times for a meeting and finding free time in your life by saving people time.

She's also helped me name previous software creations:

• onTap: an application for automatically extracting bits of information off internet sites, circa 1996
• eDict: an intranet-based corporate acronym/parts dictionary, 1997
• inList: an internet-based shared to-do list application, 1998
• flyingOX: a resource scheduling web service, 2003
  

Often overlooked details of booking a meeting

FindFreeTime will save people time by automating the "best time negotiation" task that now must be handled with email or phone calls. But for the automation to be effective, it must truly represent the nuances of booking a meeting.

The hard details of a meeting (guests, duration, location, etc) are obvious elements of meeting planning. Likewise are the yes and no responses to availability. But there are other classes of guests and subtle levels of availability that FindFreeTime supports that are also important. First, let's examine guests (or attendee in calendaring & scheduling parlance).

The vCalendar standard defines attendee types through the EXPECT attribute enumerations: REQUIRE, REQUEST, FYI, and IMMEDIATE. The REQUIRE value indicates that the person's presence is mandatory in order for the event to occur. The FYI value indicates that the invitation is informational only. Although it seems that the FYI'd person could accept the invitation and attend the meeting. In my opinion, the REQUEST value should be the default type (in the standard FYI is). The REQUEST type signifies that accept or not, the meeting will still go on without them. In my experience the REQUIRE and REQUEST/FYI types capture the two real world types of attendees: those who are required guests because they have some information or play some part in the event that is crucial. And those who it would be nice if they could attend, but the meeting will still go on without them. Our beta tests will include just these two classes.

If a group of people use a dedicated scheduling platform like Outlook or Meeting Maker, they can usually see at the time of meeting planning whether a potential guest has availability. It's likely that FindFreeTime will not be useful to them. But for most everyone else, knowing a guest's availability requires probing that person. And in my experience that's usually done with a barrage of emails to and from the meeting's organizer. This is the pain that FindFreeTime seeks to alleviate.

If one examines a couple of the "Are you free?" email threads in your Trash folder, it doesn't take long to discover that there are in fact four types of availability:

1. Yes, I can make that time.
2. No, there's no way at all that I can make that time.
3. Maybe, I'm not certain right now... but I should know conclusively at some future date whether that time works for me. In other words, I'll pencil it in.
   
4. Not ideal, but yes I can make that time if that's the only time available, but it causes some pain on my part. Hopefully one of the other times will work for everybody.
   

FindFreeTime's Interval Selection Interface (the ISI) allows an attendee (including hosts) to specify these subtle levels of availability. The host, or the automated meeting resolver, can then take these factors into account when finalizing the meeting.

In our XML Schema (Event.xsd), these types of availability are represented in the attendees element in the subelements confirmedAvailability, possibleAvailability and reluctantAvailablity.