Hi all,

I’ll preface by saying I’m not a developer by profession, so my code might not be up to industry standards.

I’ve created a tool for work called “multi_cal” that has a few utility features that Calendly does not offer (or only partially offers) on its own. Currently, it is based in Google Apps-Script and runs off a host email account that communicates with Calendly via workflows. I recognize that this is probably inefficient, but there are two reasons for this: the first is that, as stated, I am not a developer, and the second is that I wanted other people in my department to be able to set it up for themselves relatively easily and without requiring intervention on my part (that made fiddling with OAuth and other intricacies a little out of scope).

The Features

Shared Resource Keywords

Calendly is great for managing a single individual’s calendar, but it starts to struggle when different hosts are trying to schedule for the same resources (say a certain room or piece of equipment). To coordinate schedules, all users sharing a resource have a shared calendar in addition to their personal calendar. Their personal calendar is where Calendly schedules all its events, and the shared calendar is handled by multi_cal. Multi_cal essentially creates events on the shared calendar that include keywords for the resources being used. This way, if a specific resource is booked by a different host, you cannot book the same resource until it is available. By using the Free/Busy exception rules, however, you are freed up for booking any events that DO NOT use that resource.

Occupancy Notation

Some resources might have multiple slots inside of them (like a room which fits 20 people or a lab which has 5 of a certain machine). The Occupancy Notation essentially extends the functionality of the Shared Resource Keywords to allow an event to book only part of a resource. That way, if a teammate of yours books an event that takes up three of eight tables in a room, you can book an event that takes up to five (the remaining number) of tables in that same room. You can even enable yourself to host simultaneous events so long as they use the same resource and are thus able to be hosted/supervised at the same time.

Enrollment Handling and Public-Facing Calendar

Although the Group Event type is useful, it is lacking two functions that would make it practical where I work. The first and foremost is that we prefer to get multiple clients to book the same timeslot (it is a group event after all) but the booking page does not show or differentiate which timeslots have already been signed up for unless the client looks through every timeslot on the page.

The other function missing is a minimum enrollment. We not only prefer the clients to book the same timeslot, but in some cases we require it. There are certain events that are not worth hosting unless there will be a certain number of attendees.

To help with this, the script puts group events on a public calendar that shows the event name, its confirmation status, how many spots are left, and how many more people need to sign up for the event to be confirmed (you can set minimum enrollments in the script for each group event you host). The script handles changing the confirmation status in the title of the event from Tentative, Confirmed, Full, or Cancelled depending on signups and timing. It also adds a link to book that exact timeslot to the event’s description in the public calendar. This way, if a client sees an event that they are able to join, all they have to do is click on it.

The Repository:

You can find the repository for the script here: https://github.com/cfpbiggs/multi_cal

It is open source under Apache 2.0, so you are more than welcome to use it for whatever you like. If you have any suggestions, I’m all ears, and if Calendly ever wants to implement these features directly, I would be ecstatic.

Cheers,

cbiggs