Privacy policy for OnsitePilot.

This policy covers the OnsitePilot public website, private beta application flow, provider workspace, customer booking pages, and related API workflows operated under the onsitepilot.gigassbox.com domain.

OnsitePilot is built for solo service businesses that need booking, route-aware scheduling, deposits, reschedules, cancellations, calendar sync, and repeat customer question handling. The data practices below are written for that actual product scope, not a generic placeholder site.

When you reserve private beta access, OnsitePilot collects the information submitted in the beta form and basic request metadata needed to operate the queue and reduce abuse.

• Name, email, profession, business category, current booking method, social booking interest, social channels, monthly booking volume, launch timeline, discovery source, pain points, and optional notes.
• Source path, browser or user-agent details, timestamps, confirmation email status, and a hashed form of request IP where used for administration or abuse prevention.
• This information is used to review fit, prioritize beta access, send confirmation or access emails, understand booking workflows, and improve the product roadmap.

Providers who use the workspace may provide account, business, service, booking-rule, location, calendar, and payment-connection information.

• Provider email, password hash, display name, timezone, session identifiers, device or browser metadata, and account status.
• Business configuration such as service names, durations, prices, deposits, currency, refund rules, cancellation and reschedule windows, no-show settings, operating hours, buffers, travel mode, service area, store or departure address, and published configuration history.
• Storefront or public booking details when configured, including store name, description, phone, cover image, icon, and related asset metadata.
• Audit events for important account, configuration, booking, payment, calendar, and administrative actions.

When a customer uses a provider booking page, OnsitePilot collects the information needed to verify access, recommend valid booking options, hold or confirm a slot, send booking notifications, and keep the provider schedule consistent.

• Customer email, verification-code challenge state, session or resume tokens, timestamps, and order-access state.
• Booking details such as selected service, service date, slot start and end time, address text, address coordinates where route checks are used, travel estimate, service duration, buffer time, payment status, booking status, cancellation state, reschedule state, refund state, and no-show state.
• Customer contact details or booking notes only when the booking flow asks for them or the customer submits them for the provider to complete the service.

OnsitePilot uses Square for provider-connected payment workflows. Providers connect their own Square account, and customers are sent to Square-hosted checkout or payment links when a deposit or payment is required.

OnsitePilot does not collect or store full payment card numbers. Square handles card entry and payment processing. OnsitePilot stores payment workflow data needed to connect the payment result back to the booking.

• Provider Square merchant ID, location ID, connection status, OAuth token material, scopes, verification status, and connection timestamps.
• Payment link ID, Square order ID, checkout URL, amount, currency, local transaction status, Square payment ID, Square payment status, refund state, webhook event ID, and webhook processing metadata.
• Payment data is used to create payment links, confirm or expire deposit flows, process webhook updates, support refunds where implemented, prevent duplicate handling, and keep booking state aligned with Square payment state.

Providers may connect Google Calendar so OnsitePilot can write confirmed booking events to a provider-selected calendar, update those events after reschedules, and delete them after cancellations. Google Calendar is not used as the booking source of truth.

OnsitePilot does not invite customers as Google Calendar attendees in the current workflow. Customer notifications are handled by OnsitePilot email and ICS files.

• Google user ID, Google email, selected calendar ID, selected calendar summary, connection status, OAuth token material, scopes, sync status, external calendar event IDs, sync errors, and connection timestamps.
• Google Calendar data is used only to provide and maintain the provider-facing calendar sync feature, including connection status, calendar selection, event creation, event update, event deletion, troubleshooting, security, and legal compliance.
• OnsitePilot does not sell Google Calendar data, use it for advertising, or use it for unrelated profiling. OnsitePilot use and transfer of information received from Google APIs is intended to follow the Google API Services User Data Policy, including Limited Use requirements.

OnsitePilot uses TomTom for address search, route-aware scheduling, service-area checks, and travel-time estimates where route logic is part of a booking workflow.

• Provider store or departure addresses, customer service addresses, address search results, latitude and longitude, selected travel mode, estimated outbound travel minutes, and cached route calculation inputs or outputs where used.
• Route data is used to decide whether a slot is operationally reachable, protect buffer time, and avoid booking windows that look open but do not work once travel is included.

OnsitePilot uses email for beta confirmations, provider verification, customer booking access, booking confirmation, reschedule, cancellation, refund, and related operational notifications.

• Email address, delivery status, message context, booking links, provider display name, customer booking details, and ICS attachments where needed for booking notifications.
• Support, contact, or beta notes are used to answer the request, understand product fit, diagnose product issues, and improve the workflow.

The site and application use technical data to run sessions, protect private workflows, debug failures, and maintain service security.

• Session cookies or tokens for provider, customer, and admin workflows; anonymous booking session identifiers; CSRF or OAuth state values; timestamps; request headers; IP or hashed IP data; browser metadata; logs; errors; and audit events.
• These records are used for authentication, fraud prevention, abuse prevention, debugging, rate control, incident investigation, and service reliability.

OnsitePilot uses collected data to operate the product and the beta program. The main purposes are account access, beta administration, provider setup, customer booking, email verification, route-aware slot logic, deposit workflows, calendar sync, notifications, support, security, debugging, analytics about product usage, and product improvement.

Provider-supplied service rules, policy text, prep instructions, and booking context may be used by OnsitePilot automation to answer customer booking questions and move the booking workflow forward. Providers are responsible for the accuracy of the service, price, policy, and availability information they configure.

OnsitePilot does not sell personal information as part of the current beta product. Data is shared only where needed to operate the product, support the workflow, comply with law, or protect the service.

• Providers can see customer booking information for bookings made with their business. Customers can see the provider, service, booking, payment, policy, and order-access information relevant to their booking.
• Service providers may process data for hosting, database, email delivery, logging, security, routing, calendar sync, payment processing, and operational tooling. Current product integrations include Cloudflare-hosted infrastructure, Resend email, TomTom, Google Calendar, and Square.
• Information may also be disclosed if required by law, legal process, fraud investigation, security response, dispute handling, corporate transaction, or to enforce applicable terms.

OnsitePilot keeps data for as long as needed to operate the beta, maintain accounts and bookings, support providers and customers, preserve audit trails, process payment and refund workflows, investigate abuse, comply with legal obligations, and improve the product.

Some records, such as booking, payment, webhook, audit, security, and dispute-related records, may be retained longer than account profile data because they are needed for operational integrity, accounting, fraud prevention, or legal defense.

Depending on where you live, you may have rights to request access, correction, deletion, portability, or restriction of certain personal information. OnsitePilot will evaluate requests based on the requester, the workflow involved, applicable law, and the need to retain records for security, payment, booking integrity, or legal reasons.

To make a request during private beta, use the contact page at /contact/ and include the email address, provider workspace, booking link, or beta application context needed to identify the record. Do not send payment card numbers or unnecessary sensitive information in a request.

OnsitePilot uses administrative, technical, and operational safeguards appropriate for the current beta product, including server-side secrets, token handling, session controls, audit records, and integration-token encryption where configured for Google Calendar and Square connections.

No internet service can guarantee absolute security. If you believe OnsitePilot has a security issue, use the contact page and include enough technical detail to reproduce or investigate the issue.

OnsitePilot is intended for service businesses, providers, and customers arranging services. It is not directed to children under 13, and OnsitePilot does not knowingly collect personal information from children under 13.

This policy may change as the beta product changes. Material changes should be reflected by updating this page and the last-updated date. If an integration requires additional in-product disclosure or consent, that disclosure should be shown where the integration is connected or used.