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.
How a mobile IV therapy startup used GoHighLevel, Stripe, and QuickBooks to route bookings and calculate contractor pay, without any system doing two jobs.
Watch it on its own page, with the transcript.
The owner of a mobile and in-office IV therapy and wellness business had done most of the hard front-end work. In their words, "I have the majority of the website built." The pieces that make a website earn money were the ones missing. The booking and purchase buttons did not do anything yet, and the messaging compliance setup was unfinished, which keeps the business phone number from going live for texting.
The business sells in three modes: mobile visits to a client's location, appointments at a physical in-office site, and virtual sessions. Treatments are delivered by nurses who work as independent contractors, and the owner personally delivers health coaching. Consent forms, good-faith exams, medical directors and pharmacies sit in a separate telehealth and EMR platform, so the question for the marketing and booking system was narrower than it first looks: who is booked, where, with whom, for what, and who gets credit.
None of the individual requirements is unusual. Together they pull against each other, and the owner had been going back and forth over which system should own which job.
The build is a single GoHighLevel sub-account with a clear division of roles, then the booking and attribution mechanics on top. It is a good example of GoHighLevel setup and automation where the design work matters more than the number of workflows.
The rule that organizes everything is the owner's own summary: "the guiding role of this is High Level records who sold what and where." Stripe documents how the customer paid, and QuickBooks records the accounting results.
The product list the owner drafted is imported into GoHighLevel as products, with the mobile and in-office variants kept as distinct items. A set of custom fields carries the attribution: service type, provider type, provider location, seller, performer and the calendar used. Because products do not depend on which nurse performs them, with health coaching as the one exception that only the owner delivers, the product list does not need per-nurse versions.
The website's booking and purchase buttons open GoHighLevel calendars and checkout. A workflow reads the service type first. In-office services go to the in-office calendars, virtual sessions go to virtual calendars, and health coaching goes to the owner's calendar with no deposit step.
Mobile visits add an address check. The client's address is compared against each nurse's coverage area through a small custom integration, typically a webhook to an n8n step, and only providers who cover that address are offered. GoHighLevel has no native radius logic, so this is the one piece of code in an otherwise configuration-driven build. A multi-service cart books each service in a single transaction and reserves the right provider time for each.
Checkout runs through Stripe. Most appointments collect a deposit at booking, and the balance is collected after the visit. Refunds and disputes stay in Stripe, where the payment record already lives.
When an order completes, a workflow stamps the seller, performer, provider type and location onto the record and passes a compact attribution entry to QuickBooks. Stripe and the bank feed remain the only sources for money in QuickBooks, so nothing is imported twice. QuickBooks then applies each contractor's rules to the attribution entries when it is time to pay. Custom reports inside GoHighLevel are not part of the first phase, since QuickBooks does the calculating.
The website pop-up collects email and text opt-in with consent wording that matches what is registered. The privacy policy and terms carry the matching opt-out language, and the A2P registration is completed so the phone number can go live. This is the same work we package as a Website and A2P 10DLC Launch. Consent forms and exams stay in the telehealth platform, and the owner's position is that no HIPAA-regulated data is stored in GoHighLevel. The system is built so that only scheduling, sales and consent-to-contact data live there.
Any business that pays contractors by what they sold or delivered runs into the same trap: one tool gets asked to be the calendar, the cash register and the accountant. Splitting the record of a sale from the payment and from the accounting keeps each system doing what it is built for. It also means the pay rules can change without rebuilding the booking flow, because the rules live in QuickBooks and the facts live in GoHighLevel.
Clinical and wellness businesses add a second reason. Keeping charts, consent forms and exams in a purpose-built EMR and sending only what marketing and operations need is the approach behind our webhook bridge for a specialty clinic, and it is the posture we take across GoHighLevel work for clinics.
Once bookings, attribution and compliance are in place, the next layers build on the same fields: memberships, email and text campaigns, and a conversational AI for phone calls and Facebook and Instagram messages trained on the business's own documents, as covered under AI voice and chat agents. If you run a service business with contractors and a booking flow that has to know who did what, book a 30-minute call.
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.
Not as an accounting function. GoHighLevel records who sold and performed each service, Stripe handles the payments and payouts, and QuickBooks applies each contractor's percentage. Keeping the calculation in accounting means pay rules can change without touching the booking system.
Each provider carries a coverage area, and the booking workflow checks the client's address against it through a small webhook step. Only providers who cover that address are offered on the calendar. GoHighLevel has no native radius matching, so this check is the custom part of the build.
In this design it does not. Consent forms, good-faith exams and medical director workflows stay in the telehealth and EMR platform. GoHighLevel holds scheduling, sales and contact consent data only.
Not here. A single sub-account with service type and provider fields, plus separate calendars, handles all three modes. Separate sub-accounts add overhead without solving the routing problem.
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 solo real estate agent had built most of her GoHighLevel account with AI help and needed it checked, cleaned up and finished. The solution is an audit-first pass that makes the existing build work as intended, followed by a second phase that completes the missing pieces.
A life insurance telesales agency inherited a GoHighLevel sub-account with broken Meta connections and no access to its old website, while its agents still dial every call by hand. The fix is a rebuilt account with one sub-account per licensed state, Voice AI, compliant texting and a path for selling leads to a downline.
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.
