Implemented in project code
Google Calendar booking workflows
Tailored Approach has implemented a backend-owned Google Calendar booking workflow for the expanded Oren Fitness project. The server reads busy intervals, combines them with pending lead reservations, rechecks the chosen time immediately before creating an event, and preserves a manual-confirmation path when Calendar creation fails. The expanded workflow is implemented in repository code; customer availability follows the production release gate.
First-party implementation
The booking logic lives on the server
The browser shows choices, but it does not decide that a time is truly available or create the event directly.
Build availability from business rules and busy time
The Oren backend creates candidate time slots in the configured business timezone for the next booking window. It queries the Calendar free/busy endpoint and removes intervals that overlap existing busy periods.
It also removes times represented by pending or scheduled lead rows in Google Sheets. That second source prevents a saved request from disappearing back into public availability while Calendar creation is pending.
Recheck immediately before the write
A time can become unavailable after the page first loads. When a visitor submits a booking, the server validates the requested timestamp and checks the exact interval again against Calendar and reserved lead rows before attempting event creation.
If the slot is no longer available, the endpoint returns a conflict and asks the visitor to choose again. The first availability response is never treated as a reservation.
Use a stable event identity
The implementation derives a Calendar event ID from the approved booking time. A repeated attempt for the same slot therefore produces an identifier conflict instead of quietly creating a second event with a different identity.
The code handles that conflict as a taken time. This is one bounded duplicate control, not a universal guarantee against every race, manual edit, or integration retry.
Failure recovery
Preserve the request before Calendar mutation
A Calendar event is one outcome of the booking request, not the only record that the customer asked for help.
Capture the lead first
After the final availability check, the backend appends the request to a controlled Google Sheet with a calendar_pending status. Only then does it attempt to create the Calendar event.
If event creation succeeds, the newest matching lead row is updated to scheduled with the event ID. Operational log rows record lead capture, Calendar success, and Calendar failure.
Return an honest pending state
When Calendar insertion fails for a reason other than a known slot conflict, the endpoint still returns that the request was received and saved. It labels Calendar status as pending and tells the visitor that Oren must confirm the time manually.
That response avoids both bad extremes: losing the inquiry because a vendor call failed or claiming a confirmed appointment that does not exist.
Give pending requests a human owner
The design only works if someone reviews calendar_pending rows, contacts the customer, resolves or reschedules the request, and records the final outcome. Monitoring and ownership are part of the integration, not an optional support task.
Production verification must test what happens when Calendar is unavailable, credentials expire, quotas are reached, or the event write succeeds but the Sheet status update fails.
Authorization and privacy
Calendar access carries customer information
The API permission and the event contents should be no broader than the booking requires.
Choose the narrowest workable access
Google Workspace API access is granted through OAuth scopes. A booking service needs enough authority to read availability and create the intended events, but it should not inherit unrelated calendars or account-wide authority merely because a broad scope is easier.
Use a dedicated calendar where appropriate, protect client credentials and refresh tokens in the deployment secret store, restrict the OAuth callback, and define who can revoke and reauthorize access.
Minimize what enters the event
The current Oren code places the customer's name, phone, and email in the event description. That makes calendar sharing, notifications, exports, logs, staff access, and retention part of the privacy design.
Before production, confirm which fields Oren needs in Calendar rather than only in the lead record. Limit calendar sharing and prevent event details from becoming visible to people who only need free/busy information.
Release gate
What production verification still has to prove
Repository code proves the designed sequence. It does not prove the deployed accounts, credentials, data, and people operate it correctly.
Exercise the complete booking path
Test time zones, daylight-saving transitions, boundary hours, stale availability, simultaneous requests, duplicate attempts, malformed timestamps, existing busy events, pending Sheet reservations, expired credentials, API errors, quotas, and downstream status-update failures.
Confirm the event appears once on the intended calendar with the intended time, privacy, fields, and owner. Confirm every pending state is visible and recoverable.
Verify the public claim after deployment
The Tailored Approach Oren case study remains noindex while the expanded Calendar workflow completes its production release gate. Customer availability follows documented production verification.
This is independent Google Calendar implementation experience scoped to the verified booking architecture and account configuration.
Business decision
When this pattern fits
Calendar can be a useful scheduling boundary when the process is modest and its ownership is clear.
A reasonable fit
The pattern can fit a small service business that already operates one accountable calendar, offers a controlled set of appointment windows, and can manually recover exceptions.
It may be a poor fit when scheduling requires multiple resources, complex capacity, deposits, recurring appointments, regulatory controls, customer accounts, or workflow features better owned by a dedicated scheduling platform.
Common questions
What business owners usually want to know.
Does checking free/busy reserve a Google Calendar time?
No. It reports busy intervals for the queried window. The system must recheck the chosen time and create the event, while still handling another request or manual change that happens in between.
What happens if Calendar event creation fails?
In the Oren repository design, the lead is written to Sheets first. The visitor receives a pending manual-confirmation message and the business retains a recoverable request.
Is the Oren Calendar workflow live and production-verified?
The expanded workflow is implemented in the repository. Customer availability follows the production release gate.
Is Tailored Approach a Google Calendar partner?
No partnership or certification is claimed. This page documents a specific repository implementation.
Research
Sources and further reading
Reviewed 2026-08-15. Use these references to check the details and continue your own research.
Need help applying this to your business?
Tell us where the process breaks down today. We will ask the questions needed to find the cause and decide what is worth fixing first.