Privacy Policy

BetterBooking touches a few kinds of people, and the rules differ for each.

• Customers are the practices, brands, and agencies that sign in to the admin at https://app.betterbooking.co to set up a booking widget. For customers, Captive Demand is a service provider.
• Guests are the people who book an appointment, or chat with the treatment advisor, through a widget on a customer's website. The customer decides what the widget asks for and where the information goes. For guests, the customer is the party responsible for the data, and the customer's own privacy notice governs. We process guest data only on the customer's behalf and under their instructions.
• Clinicians and reviewers appear in content a customer adds, such as team profiles and imported reviews. The customer is responsible for that content.
• Website visitors are people who visit https://betterbooking.co or send us a request through a form there. For them, Captive Demand decides how the information is used.

If you are a guest with a question about a booking or a chat, contact the practice you booked with. They can see and manage your booking; we act on their instructions.

From customers

Account information. When a customer signs in with Google or an emailed link, we receive their name, email address, and profile picture from the sign-in provider. We keep a record of their organization, role, and activity in the admin, and of requests they make there, such as asking for custom analytics or an add-on.

Booking platform credentials. Customers connect their booking platform, Boulevard or Zenoti, by entering a business ID and API credentials. API keys and secrets are stored in an encrypted secrets vault and used only to perform the actions the customer sets up.

Clinic content. Customers add locations, services, copy, and team profiles. A team profile can hold a clinician's name, role, credentials, pronouns, locations, services, bio, and photo. Customers can also upload before-and-after photos. Uploaded images are stored where the widget can show them on the customer's website, so they are public. We remove embedded metadata, such as GPS location, from each image when it is uploaded.

Reviews. Customers can import reviews from a spreadsheet, one location at a time. Each review holds the reviewer's name as written in the file, a rating, a date, the text, and the services and clinicians it is tagged with. Reviews a customer chooses to feature appear in the widget with the reviewer's name.

Google Business Profile, when connected. A customer may connect a Google Business Profile account to bring in its reviews. When they do, Google gives us a token that lets us read the account, which we keep in the secrets vault. We read the account's business locations and the reviews for each location the customer matches, including reviewer names and profile photo links. This connection is optional and off unless a customer turns it on.

From guests, on the customer's behalf

Booking information. When a guest completes a booking, the widget sends us the guest's first and last name, email address, and phone number, the location, service, add-ons, and appointment time, and the page, button, and campaign tags (such as UTM tags) the booking started from. We add the price and status the booking platform confirms. Contact fields are encrypted at rest.

How a booking reaches the booking platform depends on the platform. With Boulevard, the guest's browser sends the booking to Boulevard directly, and our server then confirms it with Boulevard. With Zenoti, the booking passes through our servers, which find or create the guest's record in Zenoti and book the appointment. That booking session expires after 30 minutes without activity. Zenoti then tells us when a booking is created, cancelled, marked as a no-show, or paid. Those updates include guest details; we use them only to update the status of bookings we already hold.

New patient requests. Some widgets ask a new patient for their details before they book. When a guest finishes that step, we pass their name, email address, phone number, text-message opt-in choice, whether they chose to book now or asked for a call, the page and campaign tags, and the HubSpot and Google Analytics identifiers already set on the customer's site to the customer's HubSpot form. We do not keep a copy.

Sign-in codes. A guest can confirm their phone number or email address with a one-time code. Twilio sends and checks the code; we never store it. We keep the phone number or email address, encrypted, for the ten minutes the code is valid. Once a guest is confirmed, we keep their phone number, or a one-way hash of their email address, so the practice can recognize them next time. For a practice on Zenoti, we also keep a link to the guest's record there.

Treatment advisor. Some widgets include a chat that helps guests choose a treatment. It can ask about goals, skin tone, and how the guest's skin reacts to the sun, which we use to estimate a skin type. It keeps the guest's messages and what they have said they are looking for, such as a concern, an area, how much downtime suits them, a budget, or an event date. Answers and messages are encrypted at rest. A guest who has not signed in gets an anonymous session that expires after 30 days. For a signed-in guest at a practice on Zenoti, the advisor reads the guest's first name, active membership, and three most recent appointments from Zenoti. The practice can read advisor conversations in the admin.

Payment information. We never receive card numbers. When a booking requires a card, the guest's card details go directly from the guest's browser to the booking platform's payment vault. Our servers only learn whether the booking was completed. Bookings through Zenoti do not take a card in the widget.

Usage events. The widget records when it opens and closes, which step of the booking flow a guest reached, a random session identifier, the page URL, campaign tags in the URL, and the type of error if one occurred. These events power the reports the customer sees in the admin. They never contain the guest's contact details.

Analytics on the customer's site. The widget adds booking events to the page's data layer, for the customer's own tag manager. They carry the step, page, location, service name, whether the guest is new or returning, and the random session identifier, never contact details. What the customer's tags do with them is up to the customer.

Cookies and storage on the customer's site. The widget sets no cookies of its own and does no cross-site tracking. It reads the HubSpot and Google Analytics cookies the customer's site already set, so bookings and new patient requests can be attributed in the customer's HubSpot account. It keeps a guest's sign-in in the browser's session storage, which clears when the tab closes.

From website visitors

Requests you send us. When you ask for a free booking flow redesign on our website, we collect your name, work email, phone number if you give one, your clinic's website, your booking platform, what your website is built on, how many locations you have, and the campaign tags in the link you followed. We save it as a contact in our HubSpot account and post it to our team's Slack. If you email us, we keep the email.

Cookies. The admin sets cookies to keep a customer signed in and to remember which organization they are working in, and a short-lived one while a customer connects Google. Our website and the admin can load Google Tag Manager to measure visits, and the tags it loads may set their own cookies.

Technical information. We use IP addresses briefly to limit abuse, such as too many form submissions from one address. Our hosting provider keeps standard request logs.

• To operate the booking flow and confirm appointments with the booking platform.
• To keep a verified record of bookings that customers can review and export.
• To send booking and new patient details to the integrations a customer turns on, such as a HubSpot form or a webhook to the customer's own systems.
• To run the treatment advisor: to suggest treatments that fit what a guest asked for, and to confirm a guest's phone number or email address when they sign in.
• To write drafts with AI when a customer asks for one, as described below.
• To show customers how their widget performs, in aggregate and per booking.
• To secure the service, prevent abuse, and troubleshoot problems.
• To communicate with customers about their account and the service, and to reply to requests sent through our website.

We do not sell personal information, and we do not use guest data for advertising.

Some features use Claude, a model made by Anthropic, through Anthropic's API. Each feature sends Anthropic only what it needs to write a draft or a reply. A person at the practice reviews every draft and decides what to publish.

• Service copy. The clinic's name and a service's name, description, category, length, tags, device, and any voice notes the customer wrote. It returns a suggested name, description, and tags. No guest data is sent.
• Advisor details. A service's details and the clinic's list of guest goals. It returns suggested details for the treatment advisor, such as which goals a treatment suits.
• Clinician bios. The clinician's name, role, credentials, pronouns, locations, and services, the answers the customer types, and an existing bio if the customer pastes one. If the customer chooses, it also sends short excerpts of reviews tagged to that clinician. Excerpts never include reviewer names, and any review that contains a phone number, email address, or link is left out. It returns draft bios.
• Emails to a device maker. The clinic's name, the maker, the clinic's devices, how many locations it has, and the sender's name if given. It returns a draft email asking for before-and-after photos.
• The treatment advisor. The guest's messages, what they have said they are looking for, and the clinic's treatments. For a signed-in guest, it also sends their first name, whether they are a member, and the names and dates of their recent visits. Skin tone and sun answers stay on our servers; the model is told only whether a skin type is on file and which treatments do not suit it. It returns the advisor's reply.

We share information only with the providers that run the service and with the services a customer chooses to connect.

• Booking platforms, Boulevard and Zenoti, which hold the actual appointment and payment.
• Customer-chosen integrations, such as a HubSpot form for bookings or new patients, a webhook to the customer's own systems, or the customer's tag manager. The customer controls which of these are on and which fields are sent. Webhooks are signed so the customer can check they came from us.
• Infrastructure providers: Supabase (database, authentication, file storage, and secrets storage), Vercel (hosting for the admin, our website, and the widget's content delivery network), and Google (sign-in, Google Tag Manager, and Google Business Profile when a customer connects it). These are hosted in the United States.
• Other service providers: Anthropic (the AI features above), Twilio (sign-in codes by text message or email), and Resend (email the admin sends, such as a customer's request to our team).
• Our own tools for requests sent through our website: HubSpot, where we keep contacts, and Slack, where our team is told about each request.
• Legal reasons, when required by law or to protect the rights and safety of guests, customers, or Captive Demand.

BetterBooking schedules appointments and helps guests choose a treatment. The booking flow asks for contact details and the visit, not medical history, diagnoses, or treatment details, and customers agree not to set it up to collect them beyond what is needed to book a visit.

The treatment advisor asks about skin tone and how skin reacts to the sun, and guests may share health details in a chat. Those answers and messages are encrypted at rest and handled as this policy describes.

Captive Demand is not a HIPAA covered entity. Where a customer needs a business associate agreement, it must be signed separately before any protected health information is handled through the service.

Account information is kept while the customer's account is active. Booking records, usage events, advisor conversations, reviews, and clinic content are kept while the customer's account is active so the customer can review history and performance. When a customer closes their account, we delete their data within 30 days, except where we must keep it for legal or security reasons. Backups roll off on their own schedule after that.

Some information is kept for much less time:

• New patient requests are passed to the customer's HubSpot and not kept.
• A sign-in code is valid for ten minutes. Its record is deleted once the code is used, runs out of tries, or is found to have expired.
• A Zenoti booking session expires after 30 minutes without activity.
• An anonymous advisor session expires after 30 days.

Requests sent through our website are kept in HubSpot and Slack for as long as we need them to respond and follow up. We delete them when you ask.

• All traffic to and from the service uses TLS.
• Guest contact fields, advisor answers, and advisor messages are encrypted at rest with a key held in a secrets vault.
• Booking platform API keys and Google access tokens are stored in the same vault and never shown in full.
• Access to a customer's data is limited to members of that customer's organization, enforced by row-level permissions in the database. Guest sign-in and advisor records are readable only by our servers, which check the organization first.
• Card details never pass through our systems.
• Embedded metadata, such as GPS location, is removed from uploaded images.

No system is perfectly secure. If we learn of a breach affecting your data, we will notify affected customers without undue delay.

Customers can view, edit, export, and delete their data in the admin, or by writing to us. Guests should contact the practice they booked with; the practice can ask us to update or delete a booking record or an advisor conversation, and we will act on that instruction. Website visitors can write to us directly.

Depending on where you live, you may have rights to access, correct, delete, or restrict the use of your personal information, and to complain to a supervisory authority. We honor those rights and will not treat you differently for exercising them. To make a request, email hello@captivedemand.com.

The service is not directed to children under 13, and we do not knowingly collect information from them. Customers are responsible for any age requirements that apply to their own services.

We will post any changes here and update the effective date. If a change materially affects how we handle customer data, we will tell customers by email before it takes effect.

Captive Demand, maker of BetterBooking. Email hello@captivedemand.com, or write to us at 1015 W Kirkland Ave Ste 302, Nashville, TN 37216.