A wellness practice needed online booking with deposits, service areas that follow where each independent nurse lives, and a way to work out contractor pay. We built it inside GoHighLevel with ZIP checks, a payment-gated booking page and pay rules recorded per sale.
Prefer to watch? The one-minute version
A GoHighLevel build that gates the booking calendar behind a deposit, checks ZIP coverage per nurse, and records contractor pay on every completed sale.
Watch it on its own page, with the transcript.
The practice sells IV therapy delivered to the client's home, vitamin injections and health coaching. The owner is building a team of independent nurses who work as contractors, each in a different part of the region. As the owner put it, "all of my nurses are going to be in different areas so they'll be able to service people that I'm not."
Three things had to work before the first contractor started taking visits. Clients needed to book online and pay a deposit that covers the card processing fee. Each client needed to see only nurses who can realistically reach them. And the practice needed a dependable way to work out and record what each nurse is owed, so that any problem with payment shows up early rather than after real money has moved.
Nothing here is exotic on its own. The difficulty is that the rules stack on top of each other.
A visitor starts on a booking link from the website. The first step is a ZIP code check. If the code is covered, a form collects the service, the deposit and the processing fee, and charges the card through GoHighLevel Payments on Stripe. Only after payment succeeds does the visitor reach a second page, which holds the calendar and books the appointment. That page is not reachable by skipping the form, so an appointment never exists without its deposit.
Health coaching takes a different path. It carries no deposit, so its link goes directly to the booking page. This is the same kind of Stripe-backed billing logic we build for other practices, applied to a booking funnel instead of a subscription.
Each nurse is a user inside the practice's sub-account, not an agency-level user, with their own calendar. For in-home visits the staff and location fields are set to "Ask the booker," so the client supplies the address where the nurse should go and nothing about the nurse's own home is exposed. When more than one nurse covers the same area, the client picks one, and only open slots appear.
Adding a nurse is a short, repeatable routine, written into a PDF walkthrough:
The documentation is revised whenever the configuration changes, so the walkthrough always matches what is live.
The pay rules are encoded so each completed in-home IV visit produces a pay record. For these visits the nurse's share is a set percentage of the full sale total, with no separate in-home fee calculation, and the IV minimum still applies. IV discounts reduce the base before the share is taken. Injection packages pay a flat share with no minimum. Because pay testing needs real nurse data in the system, a test nurse was created so the numbers can be checked end to end before any real contractor is added.
ZIP coverage currently sits in one shared list. The next change moves it to a setting managed per nurse, so adding or moving a nurse means editing that nurse's coverage and nothing else. The business phone number becomes a custom value, so one edit updates every page, form and message that shows it. A navigation label on the website is also corrected so it reads "Services."
The workflows that confirm and follow up on bookings are built and testable. The text steps hold until carrier approval, and the project is not treated as finished until they send. If you are heading into the same wait, our website and A2P 10DLC launch exists to get registration right the first time.
Any practice that sends independent providers out to customers faces the same shape of problem: the service area belongs to the person, the money is split after the sale, and the customer must not see anything they should not. Keeping the deposit, the booking and the pay record inside one GoHighLevel account means a single source of truth. There is no spreadsheet to reconcile and no separate scheduling tool to keep in step.
Gating the calendar behind payment is a small structural choice with a large effect. It removes the manual job of chasing unpaid holds. Building the pay logic before the first contractor is hired also means mistakes are found with test data instead of real paychecks. For more on this kind of setup, see our work for clinics and care practices and our broader GoHighLevel automation service.
Next come per-nurse coverage management, text confirmations and review requests once carrier approval lands, and a payout summary per nurse built from the pay records. If you run a team of independent providers, book a call and we will map this pattern to your services.
Yaakov (Koby) Oranski, Founder and CEO of Yotomations
Certified GoHighLevel Admin and Partner. Koby designs CRM migrations, two-way integrations, billing systems and AI agents for service businesses, and writes from the engagements described on this site.
Yes. The booking page can sit on a separate step that is only reached after the payment form succeeds, so no appointment is created without its deposit. Services that need no deposit can link straight to the calendar instead.
The calendar's staff and location fields are set to ask the booker, so the client enters the address where the visit should happen. Coverage is judged by ZIP code, and the nurse's own address is never shown on the site.
It can be modeled with custom fields and workflows, so each completed sale produces a pay record using your rules, such as discounts reducing the base and a minimum per sale. Testing with a test nurse first catches rule mistakes before real payouts.
The booking, payment and calendar flow works without it. The text steps are built and held until the carrier approves the campaign registration, and then they begin sending without rebuilding anything.
A mobile and in-office IV therapy business needed bookings routed by service type, provider and service area, with a record of who sold and performed each service for contractor pay. The solution is a GoHighLevel build where each system has one job: GoHighLevel records, Stripe collects, QuickBooks calculates.
Trade show visitors meet spa businesses on the floor, exchange nothing durable, and the connection ends when the show does. The pilot puts a QR code between them: the visitor registers once, and the introduction continues in GoHighLevel after everyone has gone home.
A local moving company was paying for Yelp ads, but the leads never reached GoHighLevel, so no one could reply fast or track what the ads cost. We onboard the Yelp business under our agency key so every lead becomes a GoHighLevel contact, answered by an AI agent that books on the calendar.
Book a 30-minute call. We will tell you what we would do first and what it would cost.
No pitch deck. We look at your current setup and tell you what we would do and what it would cost.Need more than GoHighLevel? Yotomations, our parent company, also builds AI agents, custom software and websites.
