Re: BookingBug Services

Hi Ed,

On 6 March 2017 at 13:44, Ed Clements <ed@bookingbug.com> wrote:

> Hi Everyone,
>
> I've been looking at the sport activities offered by some of our clients
> here at BookingBug. There are activities ranging from Coasteering to Aerial
> Yoga to Pole Dance Fitness. I'll work on collating a full list to share.
>


Great, thank you.


>
> With regards to modelling opportunity data I'd like to outline how we
> model bookable activities. At BookingBug we support two main types of
> bookings; events and services.
>
> Events occur at a set date & time with a specified duration. They can be
> configured as one-off or occurring regularly according to a repeat rule.
> They can also be set up as part of a course, where all the occurrences are
> booked and paid for collectively.
>
> It was interesting for me to see in 4.3.1 in 'Modelling Opportunity Data'
> that a recurrence rule is being seen as possibly required. While we use a
> recurrence rule for the creating of events we haven't generally needed to
> expose that in our APIs for booking events. We just return the available
> events between the requested dates along with the number of spaces
> remaining or spaces remaining on the wait list if configured.
>

OK. So the intention of allowing recurrence rules to be defined is to
ensure that there is a way for people to share that type of broader
schedule data, as well as individual events.

>From the perspective of offering a discovery API/service it makes sense to
allow a user or application to query for events between a time period and
then return the actual instances.

But I'm also keen to allow schedules to be exchanged to support aggregation
of opportunity data. In that scenario I think it's better to share an event
description with a recurrence rule (that can be reliably interpreted
anywhere) rather than a stream of events.

I can see there may be issues if individual events are cancelled, etc but
this can be supported by publishing an updated schedule with a specific
date(s) excluded. Or, as a final step, catching it at the stage of booking.

Does that seem OK to you? In short, its trying to ensure we have a common
way to exchange this data but over time we can work out what the most
useful patterns are from a publishing and API perspective.

As there's a good model for recurrence rules in icalendar its not a great
deal of work to include it in the specification.


>
> Services are continuously available and allow time slots (appointments) of
> variable duration to be booked for them. We allow configuration of the
> schedules of associated staff and resources.
>
> I'm concerned that our services aren't going to fit into the event
> definition. It could've been entirely possible that none of our sport
> activity clients had services configured but having had a look I can see
> that this isn't the case. In a small set of 10 clients I looked through
> there were a couple that have services configured. One was a volleyball
> court, the other a football pitch. These are both resource based
> organisations but I wouldn't be surprised if we also had staff based
> organisations such as a personal trainer.
>

> Here's an example of how we represent the bookable times of a service:
>
> [{
>  "start": "2017-03-06T09:00:00+00:00",
>  "durations": ["PT60M", "PT120M", "PT180M"],
>  "prices": [10, 20, 30]
> }, {
>  "start": "2017-03-06T10:00:00+00:00",
>  "durations": ["PT60M", "PT120M", "PT180M"],
>  "prices": [10, 20, 30]
> }, {
>  "start": "2017-03-06T11:00:00+00:00",
>  "durations": ["PT60M", "PT120M", "PT180M"],
>  "prices": [10, 20, 30]
> }, {
>  "start": "2017-03-06T12:00:00+00:00",
>  "durations": ["PT60M", "PT120M"],
>  "prices": [10, 20]
> }, {
>  "start": "2017-03-06T13:00:00+00:00",
>  "durations": ["PT60M"],
>  "prices": [10]
> }, {
>  "start": "2017-03-06T15:00:00+00:00",
>  "durations": ["PT60M"],
>  "prices": [10]
> }]
>
> Can the specification be expanded to support this kind of data? Or do we
> just indicate that the day is available and the consumer of the OpenActive
> data redirects the user to our booking journey for them to find out
> available times?
>

If I'm understanding correctly, then a service in your system is a facility
like a court, pitch, etc? If so then the specification currently allows for
facilities to have opening times when they're available. That feels close
to the model you're describing here. That would allow the broad
availability of a facility to be available, but would defer to the booking
flow to handle actual availability of a time slot.

I've not considered staff based organisations. There are some additional
issues there relating to personal data (e.g. describing availability of a
specific person at a time and place) which we'd need to be careful to avoid.

An approach for staff would be to share the availability as a recurring
event, e.g. "personal training with person a", which the trainer with be
attending as an organiser or contributor.

What do others think? Do we need to consider staff based opportunities or
is that better deferred to when we explore booking in more detail?

Cheers,

L.