BookingPorter combines AI conversations with deterministic booking controls. Here is what is implemented in the current example, and what we review for each business rollout.
AI has a defined role
The model can collect details and call narrowly defined tools for business information, quotes and availability. It cannot grant SMS consent, approve its own address verification, charge a card or access the owner dashboard. Customers submit through the application’s review and checkout controls.
Booking safeguards
The server validates inputs and checks pricing, quote validity, service addresses and team capacity. Address verification uses a signed, expiring proof tied to the address and ZIP code. Booking admission uses database transactions and locks to protect capacity.
Owner and customer access
The owner dashboard requires authentication. Owner sessions use an HTTP-only cookie; customers manage their own bookings through private tokens. Assessment photos are stored privately and served only through authorized owner routes. Treat a private booking link like a credential.
Provider credentials and infrastructure
API credentials stay on the server and are supplied through GCP Secret Manager in deployment. The runtime uses a restricted database role. The application uses TLS connections to the database and HTTPS for public access. Public request limits reduce automated abuse, but do not promise protection from every attack.
What we agree before your launch
Your business deployment requires a review of access roles, retention, backups, provider accounts, communication consent, payment and refund policies, operational monitoring and support responsibilities. We do not claim a compliance certification or suitability for regulated information. Tell us about your requirements during scoping.
Report a concern
Email hello@fourthrise.com with a description and reproduction steps. Please avoid sending credentials or other customers’ personal information.