Abstract
Currently Google Calendar gets very little maintenance, but is used by many people, so additional features / integrations are of great value. Applications on Google products can be built relatively quickly, because there are toolkits with features like pre-built OAuth1.
Currently one of the leading tools in this space seems to be Calendly2 which lets you set up a form for people to schedule emails with you (e.g. for sales or support calls). There is value in competition here, as this is a fairly simple problem (booking calendar times + timezone conversion). I think sales / onboarding people are most concerned about 100% booking their time with leads, whereas support people would prefer to minimize back-and-forth over scheduling. There is potential value in avoiding additional licensing costs to other products (sharing of meeting tools) and in more accurate time tracking.
Challenges / Opportunities
The challenges with this type of application are timezone conversion, syncing a database with a calendar, and getting some initial adoption (if a tool worked well, there is a natural referral process). Most products of this nature must offer integrations to grow – for instance Calendly offers Office 365, but one could imagine integration with meeting (GoToMeeting) or time tracking software to automate some irritating bookkeeping.
Calendly is priced at $8/mo. I don’t think anyone can compete on price directly (it would be hard to provide support for less). Based on my experience with hosting companies, around $10/mo seems to be the cutoff for being able to provide good support, which makes them effectively pricing themselves at the edge of being a commodity.
An individual or small team could easily build a similar product, but people will fear you disappearing. Thus, any competitor would benefit from being Open Source (paid hosting + free source, like WordPress). This counters the objection that you could disappear overnight, but still allows you access to valuable assets, like being the primary source of the application, having access to the user mailing list, etc.
From a marketing perspective, the Chrome App store provides ready access to people with Google accounts. Other integrations also have “app stores” (some private) so things like GoToMeeting could potentially slot in. Zapier is a popular integration target, as you can have “non-native” integrations with hundreds of other applications immediately, and advertise specific ones.
Design
I imagine that an application of this nature would be designed around events that occur in the process:
- Create an account – occurs when requesting the creation of a meeting. Happens when a support/sales person offers up their calendar. May occur when scheduling a meeting with them.
- Offer a meeting – This would be initiated by the sales/support person.
- Pick a meeting time – used by end user. This has constraints as a prerequisite, such as existing calendar events, a preset time window, and a preset meeting length (e.g. ½ hour, 1 hr, 2 hr), work hours, work days
- Reschedule a meeting – Same as above, but requires updating on the actual calendar. This implies that there is a natural synchronization method between Google Calendar and the client database (one could move a calendar entry on GCal, for instance).
- Cancel a meeting – may require notifications
- Completion of a meeting – While optional, there may be benefit to knowing that a meeting time has passed (any events for the end user should be gated by the sales/support personnel)
From an application perspective, each of these should have a UI link (e.g. that could be used in an email)
This requires the following API hooks in any external calendaring service:
- List times booked
- Delete meeting
- Move existing meeting
This requires the following screens:
- Screen to select a time for a meeting
- Account screen
- Close account
- Pick integrations
- Change email notifications
- Email hooks
Consequently any additional features can be implemented as hooks tied to the above event list. E.g. GoToMeeting or email notifications.
Additional features would need to be able to declare their own settings pages. I would think this should have an audit trail, so that anyone can figure out a chain of events that led to a particular result.
Currently it’s not clear that if someone registers for a meeting whether that implicitly should create an account for them, since it would have to email them later for some things.
Software Architecture:
Use React + Bootstrap + TypeScript + RethinkDB, or use the hackathon starter kit or Meteor. Hosting on Digital Ocean or the free AWS / Azure to start out. If one expanded out, Compose.io or RDS for database hosting. The Node ecosystem is a good place to start, because of libraries like Passport (tons of OAuth options for integrations). The downside is there are too many options to choose rom.
Marketing Design
- Calendar entry creation as a commodity
- Pay for “support” / hosting
- OSS so people can switch if they want (would want a heroku setup option – maybe even the real way the thing is hosted)
- GPLx possibly to restrict re-use
- Chrome App Store integration (may want to track who came from here to request reviews)
- Hacker news (probably better once theres a github + a marketing site)
- GoToMeeting or competitor store
- Zapier
- Blog posts listing options through Zapier, or Native options
- Github + Github issues list
- Mailchimp integration
- Blog posts about the buildout
- In-app notification
What might constitute an MVP
- Need ways for people to sign up for future notifications
- Need support channel(s) for inbound contacting me (could just be github issues or some simple ticket voting page)
- Need a simple payment mechanism (priority support)
- Chrome App Store to slowly collect leads
- Github page
- Marketing page describing what it does
- Ability to create / move / cancel calendar entry