Booking Component

A number of people have expressed interest in a CiviCRM booking component. Let's try to get our needs/desires for such a project outlined here:

In a Nutshell

We want a system where configurable "resources" can be reserved, paid for, and then used, by CiviCRM contacts.

We want these bookings to be recorded in CiviCRM and accessible via search, report, contact tab, etc.

Proposed Schema

The "Resource" entity

Sort of a cross between a few other entity types (think "contact" meets "event" meets "activity type") this entity would have the following properties:

• Name
• Description
• Type (preconfigured? configurable? unnecessary?)
• Price(s)
• Capacity/units of some sort
• Limit - how many of these are available at a time?
• Parent/child relationship to other resources
• Custom data?  - For example room layout (this may effect capacity)

MM: I was thinking that we could model this as an activity type, e.g. Create a new activity type, call it a Video Camera, and the way of creating a booking is recording an activity of this type.

I was also thinking that we should use Price sets here on the activity/event.  We'd nee to make some price sets time dependent and others one off.

Sgladstone:  I was thinking it may be useful to generalize the "subcontact" type features in CiviCRM. What I had in mind: When a new subcontact type is defined, the parent could be a generic object called "Entity".  Entity's only fields would be name, description, and external id.  Everything else would be custom fields for that particiular contact type.    Also, the current built-in contact types "household", "organization", and "individual" would be decendants of the new "entity" contact type. 

EM To what extent can we re-use event functionality? Conceptually it is much like an event except there is a range of times & an activity is recorded - (based on MM's suggestion which I like). But other things, like payment, pricesets, Capacity are somewhat in common with events.

Coleman: I don't think a resource as we're talking about it is an activity or a contact, and we'll be better served by having it stand on its own rather than trying to make it fit into a mold not made for it.

Oliver: Added some basic custom data examples

Phil B: We offer a discount to groups depending on their status. Public Sector, For-Profit etc pay 100%, 30% discount for charities, 60% for community groups (3 or less staff). If we could associate a discount with an organisation, that would be great. The status of the organisation would have to be verified to stop misuse.

The "Booking" entity

Kind of like "participant" or "activity," this entity records that contact(s) has booked one or more resources

• Creator CID
• Target CIDs (the people this booking is for)
• Creation date
• Total Price
• Amount Paid (this maybe shouldn't be a DB column, but can be calculated based on contributions attributed to this entity)
• Status
• Notes
• Custom data

The "Booked Resource" entity

A child of the booking entity, we create one of these for each resource booked, so that more than one resource can be booked (or the same one more than once, like a room from 2-3pm and 7-8pm) in a single booking.

• Booking ID
• Start datetime
• End datetime
• Resource ID
• Price
• setup timetrame
• teardown timeframe

Sgladstone:  I added the field "permanent/owned" to cover situations where the resource was essentially purchased outright, or is a very long-term arrangement.   This could apply to several situations: The organization has sub-leased a space to a tenant on a long term basis. For example, some organizations rent a section of their building to another organization, where the "tenant" has use of the space for 15 years and may have helped to pay for remodeling the space. 

Coleman: I removed Sgladstone's permanant/owned field, because I think the same thing can be achieved by just leaving end date blank. Correct me if I'm wrong. 

sgladstone: Leaving end date blank in the db is fine, we just need to make sure the user interface makes this fool-proof in that someone should not be able to easily forget to put in an end-date by mistake.  Also there will need to be filters in the search/reporting areas to hide any permanent/owned resources from the calendar, to avoid cluttering up the calendar.

EM I was thinking the booked resource would be a contact. Since in many instances the resources might be people in the DB. People could make specific contact types bookable (now that we will have the ability for people to have multiple types)

sgladstone: I added "setup timeframe" and "teardown timeframe". These would be filled in by the facility admin staff in the following situations: Someone has booked a large room for a complex event, where the organization's  staff needs 25 minutes to setup the tables/chairs/food/etc for the event. The staff also needs 30 minutes after the event to clean up the room.   The person who is making the room reservation would make the booking from 5pm - 7pm, then the staff would fill in the setup and tear down times later based on the complexity of the event details.   So the room would not be available for a different booking until 7:30pm. 

Integration with CiviContribute

I (Coleman) think we need to avoid falling into the trap that the rest of CiviCRM is still struggling out of, where there is a 1-1 relationship between obligations and payments. If we can abstract the payment system so that any number of payments (from any number of contacts) can be attributed to the same booking, then that allows people to pay deposits, pay in installments, get a partial refund, crowdsource, etc.

• The ability to generate an invoice linked to a contribution page would be wonderful
• Contributions can be FKed to a booking. This component can ship with a reserved contribution type "Booking Payment"

EM - I would like to look at extending the concept developed for CiviMember whereby an item in a price set can be associated with a membership type. In general I would like to see price sets become the underlying structure for all contributions as maintaing two structures is an over-head. But also, I think pricesets offer much more flexibility - the Room with tea & coffee facilities being a good example.

The U.I.

EM - so 3 parts to the UI, booking form, administration & viewing. Viewing seems to be already discussed as being a tab - with obviously reports as well. Presumably on that tab we'd want to flick between calendar & records view.

Availablity calendar

This shows the availability of each resource. Might be nice to be able to view mutiple resources on one calendar, so you can do things like find out when the two rooms you want to book and the projector are available.

Booking form

Not sure if this is seperate from the calendar at the moment, perhaps it is linked from it.

Use Case Scenarios

Lots of people have different uses in mind for this. Let's briefly outline each one here so we make sure the above is flexible enough to accommodate them all.

Guest Accommodations

Woolman has a few guest houses and cabins. Rooms in a house can be rented separately, or the entire house can be rented as one. So we need a parent=>child relationship between these resources so that if someone books the whole house, each of the rooms inherits the status "reserved" during that time period. We charge individuals per person, per night, and we charge groups per building used. Other amenities can be added, like meals and linen service. We generate an invoice for each group, they pay a security deposit, cleaning fee, etc. These technically aren't resources, but they need to somehow be included in the price.

Meeting room / space booking

Organization has a meeting room that they want to rent out.  They want members of their organization to be able to view availability for the room and to be able to book the room.  There is a price associated with the room, which is an hourly rate.  They might also want to book extras like Tea and Coffee.
Oliver: An added complexity is that room booking hourly rates are often different based upon weekday / evening / weekend rates etc.

Booking a time with a person

The organization has a number of teachers who parents need to schedule meetings with. For example during the week of parent/teacher conferences, there may be 20 teachers and 400 parents. Each parent can book an appointment time with a teacher lasting 15 minutes. The choices would be at 3pm, 3:15pm, 3:30... until the last choice at 7:45pm.

The organization may offer paid tutoring with a set of 5 tutors. The tutors each have a set schedule where the person can sign up for a tutoring session. ( Tutoring sessions may be paid, free or only free for members of the organization) 

In many situations the person booking the tutor is NOT the person being tutored. For example: George Jetson will book and pay for a tutoring appointment on behalf on his son Elroy.  The tutor would need to know that the appointment is with Elroy Jetson. The tutor may not need to know or even care that George booked the appointment. 

Coleman: I don't think this will be a problem. Just book the tutoring for Elroy, and George can pay.

Reserving seats

The organization has a large auditorium with numbered seats. For certain special events, people can purchase a seat for that event.   In some cases, a large donor may own a permanent seat that they sit in every year. Other seats are in flux and can be purchased by different people each year. 

The administrator of the organization would need to quickly identify which seats are available/open for a certain event, or available for an outright permanent purchase. 

In some cases the person who purchased the seats will also be the person occupying/sitting in the seat. However, there will also be many situations where the purchaser is buying a block of 5 seats, where 4 of the 5 seats are occupied by a guest.   

Coleman: I think there's a line somewhere between CiviBooking and CiviEvent. This sounds way over the line to me. But we need to get more clear about these specs and the difference between the two, and possible points of intersection. 

sgladstone: Perhaps a solution would be to create the possibility of an event registration process with a link to a CiviBooking process  For example: A parent registering their child for a school program could also schedule a tutor at the same time.   Or someone sets up a CiviEvent for a large meeting/conference, where they also need to allow self-service registration for the attendees. In this case there is a need to link the CiviEvent to the room that is booked for the event.( There is already a spot on the event config to specify location. This could be enhanced to include room booked for that event.) That way the person setting up the room knows how many chairs to set up, how much food/coffee to set out, etc.      Or if staff reassigns the event to a different room, that would be reflected on the event details.

Another thought I had where there is already overlap is in priceset fields that include a participant limit.  In a sense, those types of priceset fields represent a "resource" that can be consumed. 

Notes/Misc:

Some other projects/products that might give ideas on how bookings are handled:

http://mrbs.sourceforge.net/ (Open Source, PHP)

http://sourceforge.net/projects/phpscheduleit/ (Open Source, PHP)

http://drupal.org/project/merci (Drupal module , MERCi)

http://www.dea.com/Industries/nonprofit/default.aspx  (Commercial product)

Making It Happen

At some point (when these specs seem solid enough to implement) let's consider starting a MIH to fund some paid developer time in addition to all the volunteer work we're committing to. Speaking of which... who's up for putting some time into this?

Oliver: We have some money which we can contribute towards a MIH for this.