TLDR; We are updating Bilby’s booking statuses to reduce the current set from 7 to 4. The new statuses include; Interested, Pending, Valid and Void. Read on about why we are making the changes.
What are the new changes?
We are improving the system to allow bookings to be created in an easier way. Activity Owners should be able to add participants easily with an existing username and email. They should also be able to easily invite another User or friend simply by knowing their email or username.
We are also taking this opportunity to revise some inconsistencies in naming and improve clarity on processes that occur during the lifecycle of a Booking.
What do we have to consider?
- When creating a booking/attendance record for an anonymous user to an activity, we must be able to later identify that user
- We must protect the invited user from spam messaging
- We must accurately track and interpret status changes
- We also must ensure the invited user can accept or reject the invitation
What are some of the current issues?
Too Many Statuses
Bilby currently has 7 statuses associated with bookings. Pending, Declined, Wait List, Approved, No Show, Attended, Withdrawn. When implementing invitations to an Activity, if we are not careful, we could have several new statuses which will add to the complexity for Activity Owners and Users.
Pending vs Approved
The “Bookings Required” field on an activity is responsible for determining if a booking starts with one of the above statuses. We don’t think this is clear in the current system. If an Activity Owner would like to validate a booking before being accepted, then a booking should start its life as Pending. It’s logical to then assume every other booking is already valid.
This information should also be clear to a new Bilby user and should be explained during the booking process.
Withdrawn vs Declined
There have been issues of semantics on the labelling of a booking that has been marked as void. Bilby needs to track when a booking is no longer valid and has been finalised. Having multiple states that mean the same thing has caused confusion amongst Users and Activity Owners.
Wait List
A. This term has made it very challenging to re-use in Bilby processes. From a software perspective, it has become a default parking status that means the same thing as Pending but allows it to be ignored.
B. We feel like this status assumes further action from the Activity Owner. From a Users perspective, when they are on a Wait List, they should be informed if they are successful or not.
C. We allow bookings to be made while the activity is open, even when an activity has reached its maximum capacity. The Wait List had big dreams of becoming the next status once an activity had reached its capacity, but it did not feel right implementing a forced waiting list for the above reason.
D. It is very unclear to a User creating a booking what status they will end up in. This is true for brand new Users and even regular Members in the system. Bilby should really notify a User if there is some sort of approval process required to attend an activity.
No Show
This status offers little value for a user who made a booking and could not attend for personal reasons. It only serves to name and shame a user which goes against Bilby’s ethos of building a platform that promotes positive interactions. We would prefer this field to be interpolated by comparing valid bookings to actual attendance.
What are the 4 new statuses going to be?
We have done some magic and we decided we can boil down the current 7 statuses into a nice clean 4. These will encompass the above and provide us with flexible functionality for future development.
1. Interested
Users can express interest: This new status allows us to create a record for users who are interested in an activity. They may have a question or comment and this will give the Activity Owner an opportunity to engage with an interested user.
Guests who have reached the maximum bookings: We will also have a clear distinction on when a Guest has reached their maximum bookings in Bilby. The rule will be; they can only register interest, but at the end of the day, it will be up to the Activity Owner to process the booking if they wish.
Clarity on activities that have reached capacity: When an activity has reached its maximum capacity, Bilby will automatically register further bookings as interested. This will allow other users to express interest even when an activity is full (As long as the activity is open for bookings).
Easily create a Wait List: An Activity Owner can communicate with an interested User to let them know they are on some sort of waiting list. With the new Notes features, this will make it easy for an Activity Owner to know who is waiting at anytime.
Less work on moderation: There is no need to remove someone from the Interested state. It is now clear that no further action is required. When an Activity Owner responds to a User that has expressed interest, they will have an audit trail to see who might have missed out.
2. Pending
Activity Owner actionable: Bookings will start in a Pending state when an Activity Owner asks Bilby to set new bookings as Pending. This status is important to let Bilby know that the Activity Owner would like to manually administer and moderate their bookings.
3. Valid
Easier system tracking: Bilby can accurately articulate who should have access to features such as Message Board. This is because we consider a Valid booking to be its final state and Bilby will know who should always have access to these features.
Less work for Activity Owners: Because the Valid state is considered finalised in the system, it does not require further moderation. Marking attendance will happen outside of this process.
Support for future features: We would really love to implement ticket purchasing, so a valid ticket would be purchasable. This supports future development better than the old status which would be confusing. Another idea would be supporting QR code marking of attendance, which also makes sense in the context of a valid ticket.
4. Void
Less work for Activity Owners: When a booking is withdrawn or declined (as in the old system), or closed for any other reason, the booking will be voided. This is considered a final state with no further action. Bilby will record a note when an Activity Owner or User has voided their booking so the context is always available to Activity Owners and Users.
What else are we changing on bookings?
We are adding some new fields that will be internally managed by Bilby. They will be updated or changed depending on which User is performing an action.
A. Invited
Easily invite users to an activity: In the new feature, we can now safely allow Activity Owners and Users to invite a user simply with username or email. This will allow Activity Owners to track when someone was invited. We can also implement adding a note for who invited the user. Users must be logged in as a minimum to invite another user.
Accept or Reject an invitation: We will generate a notification to inform the user has been invited to an activity. This will include quick easy buttons to accept or reject the invitation. Rejection will not require authentication. When a booking is rejected, we will void and trash that booking. When a booking is accepted it will follow the Pending or Valid pipelines as per the Activity Owners configurations.
Activity Owners have full control: Bilby will wait for a User to action their invitation, but an Activity Owner can still moderate and perform updates to that booking, including removing it.
B. Attended
Quickly capture attendance: When finalising an activity, Bilby will present the Activity Owner with a list of the valid bookings. They will be automatically selected to mark attendance. An Activity Owner will be able to quickly deselect any participants that might not have been present reducing their workload.
Future support: We have a nice vision of implementing Ticket scanning through Bilby to show attendance. An Activity Owner would simply need to allow Bilby access to their camera and scan a QR code given to a User with a valid booking and this will mark attendance.
User friendly approach: Attendance may be exposed to a User, but would only be done in a friendly manner. We do not want to name and shame a user who could not attend for any reason. This information will be clear to an Activity Owner when seeing Attended vs Valid tickets.
How do the new statuses map to the old ones?
When we migrate to the new structure, use the following table to see how your data will map to the new structure.
| Old Status | New Status |
|---|---|
| Wait List | Interested |
| Pending | Pending |
| Approved | Valid |
| Declined \ Withdrawn | Void |
| Attended \ No-Show | (captured elsewhere) |
| Invited | (captured elsewhere) |
NOTE: The features described above are subject to change during development. This document outlines the overall strategy and updates for this feature. If development changes to something reasonably out of scope, the updates will be published at the base of this document.