Calendars for people and meeting rooms
- Every Person has a calendar. Every meeting room has a calendar. Check Entities for the difference between Person and User.
- The appropriate user role can create new meeting rooms, delete existing, etc.
- Users can view their own calendar. Two way sync exists between this calendar and their Google calendar. If an event is created/deleted on one, that should be reflected in the other (Does this use API access or SMTP + iCal invitation)?
- Users can create events in their own calendar and add Persons to the event. Users can view the calendars of other Persons to find conflicts.
- Users can add a meeting as their meeting location. If the meeting room is already booked (an event exists on that meeting room’s calendar that intersects with the meeting time), do not allow the user to book the meeting room.
- Users can view a meeting room’s calendar alongside guest calendars when trying to book a time.
- Users assigned as a meeting room’s owner can delete or edit meeting room events owned by other users.
- Users with the appropriate role can assign a User to be a meeting owner
- Meeting rooms should have capacity. If a meeting’s total guests exceed the meeting rooms capacity, warn the user and require them to override.
Rippling Integration
- When a User requests time off in Rippling, block off their calendar.
- If a time off request is rejected, unblock that User’s calendar.
Notifications
Notify users when:
- An event has been added to their calendar.
- If a user has the appropriate org role, notify if someone requests time off and they have events on their calendar that day (if a tennis coach asks out and has a lesson booked, notify the head of tennis scheduling).
- If the above time off request is approved, and there are still events on the calendar, send another notification to the appropriate org role.
Event Types
- Singleton events occur once at a particular date/time range (Jessica has a lesson with Coach Jim at 7pm on April 7). They have a single “session.”
- Program events are recurring activities with a shared roster. For example: every Wednesday night at 7pm, the same 10 people receive a group lesson. These are recurring “sessions” within the same event.
- Multi- events occur over one or more date/times. Example: Participants can sign up for a tennis camp that runs 1pm to 3pm on weekdays, the week of June 15. This event has five sessions.
- Events and programs both take place on courts that may be in one of multiple locations (Indoor, Outdoor, Clay, Building B, etc.). Events or programs may have to use a variable number of courts (a camp might need 3 courts).
- When editing a program or multi-event, the user should have the option to apply the edits to: every session, the current session, the current session plus all future sessions.
- Program events and multi-events have a capacity of total possible guests. Once the capacity is reached, we don’t want people able to register. NOTE: this comes from the business, but what if we want open sign-ups to a singleton event, or otherwise have events with capacities that you can’t sign up for? Make a better way to flag if a user can sign up for the event, or if they event is generated by the user.
- On corporate holidays or other days when Farm and Forge is closed, by default, allow no external bookings, and warn internal users that F&F is closed. Make the internal user acknowledge and manually override.
Calendars for tennis courts
- A “building” (which might be outdoors) contains multiple tennis courts. Each court has its own calendar (similar to a meeting room).
- Using an internal dashboard, the admins of the tennis calendar can create, delete, and edit events.
- Court locations are very important internally, but should be hidden externally. Court booking logic: a customer wants to book a lesson with a coach. For a timeslot to be available, it should be open on the coach’s calendar, and there should be a court that is also open at that timeslot.
- Internally, tennis staff may move locations of the individual court back and forth, but that does not effect the customer. Their iCal event will have a location of “Building A” or “Building B” etc. A tennis coach may have a lesson moved from Building A Court 2 to Building A Court 7, and they will need to be notified and have their calendar event changed.
Calendars for Strength and Conditioning
- S&C is a separate org from Tennis. Some people will book lessons or classes with a personal trainer rather than a tennis coach. From a user perspective, S&C booking is a separate tab.
- Similar to tennis courts, a piece of workout machinery (weight bench, treadmill etc.) might be bookable. They belong inside of a “building” with similar logic.
- S&C needs a similar internal dashboard for scheduling events.
- Prioritize tennis calendars.
Public facing tool for lesson booking
- **New Customers**
1. A new customer goes online to book a lesson. They fill out a form with information about what kind of lessons they are looking for and their skill level.
2. Based on the information in the form, they are given a list of coaches from whom they may book lessons. They may view the coach's calendar and book a time directly.
3. If they do not yet have an account with a signed waiver and payment on file, they will be directed to create an account before the lesson booking can be finalized.
4. When the booking is made, the coach's calendar is automatically updated, and a court is automatically booked. The customer receives an automatic email with a calendar event.
5. When the lesson starts, the card on file is automatically charged. If an admin cancels a lesson beforehand, the times on the calendars are automatically released and the card on file is not charged.
- **Returning Customers**
1. A customer logins into the website and views the list of coaches with whom they may book a lesson. They can click on a coach to view their calendar and book a lesson directly.
2. When the booking is made, the coach's calendar is automatically updated, and a court is automatically booked. The customer receives an automatic email with a calendar event.
3. When the lesson starts, the card on file is automatically charged. If an admin cancels a lesson beforehand, the times on the calendars are automatically released and the card on file is not charged.
User Authorization
- When a new employee is hired by Farm and Forge, their Google credentials are automatically populated into the application.
- Employees can authenticate with Google credentials
- When a customer creates an account, they can use Google credentials or sign up using username/password. Use Google Cloud’s identity management.
- For external email-based authorization, include forgot/reset password links. Use MailKit for SMTP.
Payment Processing
- When a customer creates an account, they can add a card to keep on file. Store these credentials in Stripe using Stripe’s APIs.
- When a customer attempts to book a lesson, if they do not have a valid card on file, prompt them to store a payment method before booking the lesson.
- When a customer’s lesson begins, charge the card on file the appropriate amount. This is an automatic process: when the given date/time has passed, process the payment and mark the session has expired.
- Customers can cancel a lesson within the app and may be refunded if done far enough in advance. Appropriate F&F staff can also cancel a lesson for a customer.
- If a customer was charged mistakenly, appropriate F&F staff should be able to click a button and refund a lesson.
- Integrate Stripe’s coupon codes to allow staff to offer discounts.