Implemented in project code
Google Sheets lead capture and recovery
Tailored Approach uses Google Sheets in the expanded Oren Fitness booking design as a modest, visible lead and recovery queue. The backend saves the request before it tries to create a Calendar event, then records whether scheduling succeeded or needs manual confirmation. That is a specific operational use, not a claim that Sheets should replace a CRM or database.
First-party implementation
Why Sheets exists in this booking workflow
The spreadsheet is used to preserve a customer request and expose an exception, not to imitate a full customer system.
Write the lead before creating the event
After the server validates the booking and rechecks the slot, it appends the visitor's name, phone, optional email, requested date and time, timezone, source, and a calendar_pending status to the Leads tab.
Only after that write succeeds does the backend attempt Calendar insertion. If Calendar fails, the business still has a row showing who asked, which time they requested, and that manual confirmation is required.
Keep an operational log separate
A DevLogs tab records lead capture, repeat-name-and-phone detection, Calendar creation, and Calendar failure with time, status, slot, event ID, and bounded error context.
Separating the customer-facing lead row from operational events can make investigation easier, but logs still need access, retention, safe error text, and an owner. A spreadsheet log is not automatically a secure audit system.
Use pending rows in availability
The availability endpoint reads lead rows and treats both calendar_pending and scheduled times as reserved. That keeps a saved request from returning to the public slot list while the Calendar event is absent or still being resolved.
The design therefore makes Sheet availability part of the booking decision. Manual edits, deleted rows, unexpected status text, or API failure can affect what customers see and must be monitored.
Data integrity
A simple sheet still needs durable identity
Human-readable rows are useful, but position and names are weak system identifiers.
Give every request its own stable key
The current implementation searches from the bottom for the newest row whose normalized name and phone match, then writes scheduled status and the Calendar event ID into that row.
That can be ambiguous when the same person submits more than one request or concurrent writes arrive. Before production, each accepted request should receive a stable identifier and the follow-up update should target that identifier rather than inferred row ownership.
Do not make row order a contract
People can sort, insert, delete, copy, or edit spreadsheet rows. Formulas and additional tables can also change how the append endpoint detects the next row.
Protect structural ranges, document which columns people may edit, validate status values, and reconcile requests by stable identity. If the workflow needs frequent concurrent updates or relational history, a database or CRM is likely a better system of record.
Spreadsheet security
Treat every written value as untrusted
A spreadsheet can interpret input rather than store it exactly as text.
Prevent formula interpretation
The current Oren append calls use USER_ENTERED, which lets Sheets parse values as a person typing into the cell would. User-controlled text that begins with formula syntax can therefore be interpreted instead of preserved as literal customer input.
Before deployment, external text must be neutralized safely or written with an input mode that preserves it as text while dates and statuses are handled deliberately. This applies to lead fields and any logged error string.
Keep credentials and scopes narrow
The backend uses OAuth refresh-token access to Calendar and Sheets. Secrets belong in the deployment secret store, not source files, browser code, logs, public callback pages, or shared spreadsheets.
Use the narrowest scopes that support the required spreadsheet and calendar operations. Restrict the spreadsheet to approved staff, review link sharing, remove stale access, and define who can revoke and renew the authorization.
Protect customer data throughout its life
The Leads tab contains names, phone numbers, email addresses, requested times, status, and event IDs. That requires a stated purpose, access rules, retention period, deletion process, backup decision, and a privacy notice that matches reality.
Do not add sensitive intake fields merely because Sheets makes it easy to add columns. The booking form should collect only what the consultation requires.
Reliability
Build a recovery path for Sheets itself
Lead-first recovery only works while the lead write is trustworthy.
Fail before Calendar when the lead cannot be preserved
The Oren backend currently stops the booking if the initial lead append fails, so it does not create an event with no operational lead row. That ordering is deliberate.
Production behavior still needs tested responses for expired credentials, missing tabs, changed headers, permissions, quotas, timeouts, file complexity, and service unavailability. Retries must not create duplicate rows or repeated Calendar effects.
Reconcile status changes
A Calendar event can succeed while the later Sheet status update or log append fails. The business needs a reconciliation view that finds pending rows with a real event, scheduled rows with a missing event, duplicate requests, and exceptions without a human decision.
Alerts should lead to a named person and a documented correction. A red cell nobody reviews is not failure handling.
Claim boundary
What this implementation proves and does not prove
The repository provides real evidence of design and code, while the production result remains gated.
Demonstrated capability
The repository code creates the Sheet layout, appends lead and log rows, reads reserved slots, and updates successful bookings. The public Oren case study documents the same lead-first order.
This is direct experience with one bounded Google Sheets workflow. It does not establish Google partnership, universal connector support, or that Sheets is the right database for every small business.
Production verification still required
The expanded Oren workflow is not currently claimed as available to customers and the case study remains noindex. Formula safety, stable request identity, OAuth handling, permissions, privacy, real API failure, reconciliation, and human recovery must be hardened and tested before that claim changes.
If volume, collaboration, reporting, relationships, or reliability outgrow the sheet, the correct next step is to move the system of record rather than add increasingly fragile spreadsheet conventions.
Common questions
What business owners usually want to know.
Why save the lead before creating the Calendar event?
It keeps the customer's request visible if Calendar creation fails. The business can contact the person and confirm or reschedule manually instead of losing the inquiry.
Can Google Sheets serve as a CRM?
It can support a small, controlled queue, but it lacks many identity, permission, relationship, workflow, audit, and concurrency features of a well-configured CRM or database. The fit depends on the operation and consequence.
Why is USER_ENTERED risky for public form data?
Sheets may parse user-controlled text as a formula or another typed value instead of storing the literal text. External values need a deliberate safe-write strategy before production.
Is the Oren Sheets workflow live and production-verified?
The expanded workflow is implemented in the repository. Customer availability follows the production release gate.
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.