Calendar

Problem: There is no way to filter contacts by which service they have booked in the Contacts view in Services V2. The only place you can filter by service is in the Calendar list view, but that view does not support bulk actions like adding tags, updating fields, or enrolling in workflows. This means if you want to take action on all contacts who booked a specific service (e.g., tag them, update a field, send a campaign), there is no native way to do it. Requested solution: Add "Booked Service" and "Service Category" as filter options in the Contacts view and in Smart Lists Allow bulk actions (add tag, update field, enroll in workflow) from the Calendar list view

Problem: The "In Service" filter is only available on the Service Booking trigger, not inside If/Else conditions. This means there is no way to branch workflow logic based on which service was booked. Without this, the only way to run different actions per service is to create a completely separate workflow for each service. For businesses with 10, 20, or 50+ services, this creates dozens of nearly identical workflows that are hard to maintain. Requested solution: Add "In Service" and "In Service Category" as available conditions inside the If/Else action when the workflow uses a Service Booking trigger. This would allow users to build one workflow with branching logic per service, instead of duplicating entire workflows. Example: Trigger: Service Booking (Confirmed) If Service = "Haircut" → send confirmation A Else if Service = "Massage" → send confirmation B Else if Service = "Facial" → send confirmation C Else → default confirmation All in one workflow instead of three separate ones. This would benefit any multi-service business using Services v2: salons, clinics, studios, spas, gyms, agencies, and more.

Problem: When using the Service Booking (Services v2) trigger, the only way to access the service name is through the {{#each serviceBooking.services }}{{ this.name }}{{/each}} Handlebars block. However, the Update Contact Field action does not process Handlebars blocks. This means it is impossible to dynamically save the booked service name or assigned staff name into a contact custom field. What I've tried (all return empty): {{#each serviceBooking.services }}{{ this.name }}{{/each}} {{ serviceBooking.services.0.name }} {{ serviceBooking.booking _id}} {{#each serviceBooking.services }}{{ this.user.name }}{{/each}} {{#each serviceBooking.services }}{{this.assignedUser}}{{/each}} The variable picker inside Update Contact Field shows "Service Booking > Services > Name" but inserts the #each Handlebars syntax, which this action cannot process. Requested solution: Add flat (non-Handlebars) merge fields for Service Booking data that work in all workflow actions, not just in message templates. For example: {{serviceBooking.serviceName}} for the first/primary service name {{serviceBooking.staffName}} for the assigned staff member {{serviceBooking.serviceCategory}} for the service category This would allow users to save service booking details into contact fields for segmentation, personalization, and automation without needing premium webhook workarounds. Use case: Any business using Services v2 with multiple services needs to store the last booked service on the contact record for segmentation, personalized follow-ups, or rebooking automation. Currently the only workaround is building a separate If/Else branch for every single service, which doesn't scale. This affects salons, clinics, studios, agencies, and any multi-service business using Services v2.

Cancellation screen of calendar at this moment cannot be changed, would like to request three enhancements: 1) Have a way to update all the content, seen that if its done in another language we would have to update it. 2) Give an option to toggle on/off the cancellation reason as required as we have it for T&Cs in forms 3) Option to also change it from reason to "radio" or "checkboxes" so we can have the client select the reason. Thanks

It would be very helpful for us if there will be an option to lock the time zone in the booking widget, its because the appointment time zone field does not really guarantee the right term for each time zone so we hard coded it to Philippine Time, because when leads booked an appointment using Ph time it shows in the email confirmation as PHT.

When I try to use the Custom CSS field on a rental calendar, instead of applying to the calendar, the CSS is printed below the iframe. I am embedding the calendar with an iframe into a WordPress (Divi) Code block, the same as I do with appointment calendars with no issue. My CSS is fine. I have tried much simpler CSS with no luck. I tried a couple of things the AI support widget suggested, like wrapping the CSS in an html <style> element, and applying the CSS to the code block in WordPress instead of the custom CSS field in GHL. Still no luck. I believe there is some kind of disconnect where the custom CSS field in GHL simply is not applying to the calendar at all. https://snipboard.io/EtDWgk.jpg

One feature that would greatly improve the Rental functionality is the ability to set different pricing rates based on specific times of the day. Currently, the advanced options allow users to customize pricing for different days of the week (such as weekends), which is very useful. However, there is no option to create different rates depending on the time schedule within a day. It would be extremely valuable if users could configure custom pricing for specific time ranges — for example, separate rates for daytime and nighttime rentals, peak hours, or evening schedules. This feature would be especially helpful for businesses such as coworking spaces, resorts, Airbnb properties, hotels, studios, event venues, and other rental-based businesses. Having flexible time-based pricing would be a major improvement and could make the rental system much more powerful and competitive.

When an appointment is marked as "showed", the time becomes available again in the calendar to book. IE currently the only status that stops a team member's time being booked, is "confirmed", all other statuses including "showed" open the slot again for booking. This is a problem in services bookings, for example health services (but also many others). A contact books an appointment, it is confirmed, then when they walk in the door the receptionist marks the appt as "showed" in order to notify the practitioner that the client is ready. It might be a 2 hours appointment BUT the calendar now shows the spot as available for booking and allows another appointment to be booked immediately, which creates a double-booking in reality. The solution is that "showed" status should also stop the team member from being available for booking, the same way "confirmed" does.

I am looking to customize the admin calendar UI/theme (background, grid, colors etc.). Is this on anyones radar?

There is currently no way to put a service "on sale" in Services V2 and have the original price and the sale price both visible to customers on the booking page. The only way to offer a discount is through coupon codes, which require the customer to know the code, type it in, and apply it at checkout. This means if a detailing shop, med spa, salon, cleaning company, or any service business wants to run a Black Friday sale, a slow- week flash promotion, or a seasonal discount on a specific service, they have two bad options: Change the actual service price to the sale price. The customer sees the lower number but has no idea it is a deal. There is no strikethrough, no "was $199, now $149," no urgency. The original price disappears entirely, and when the sale ends the business has to remember to manually change it back. If they forget, they are undercharging every customer who books after the promotion. Create a coupon code and tell customers to use it. This adds friction to the booking flow — the customer has to find the code, remember it, and type it into a separate field. Every extra step in a booking flow reduces conversion. And for a public sale where every customer gets the discount, requiring a code makes no sense. Nobody hands a coupon to every person who walks into the store and then makes them read it back at the register. What we need: Add a native Sale Price field to each service in Services V2. When the business enters a sale price, the booking page automatically displays both the original price and the sale price — with the original price shown as a strikethrough and the sale price highlighted as the current amount. The customer sees: ~~$199~~ $149 No code needed. No extra step. The discount is applied automatically to every booking made while the sale is active. How it should work: Each service gets an optional Sale Price field and an optional Sale Start Date and Sale End Date. If no dates are set, the sale runs indefinitely until the business manually removes it. If dates are set, the sale activates and deactivates automatically — no risk of forgetting to revert the price. When a sale is active, the booking page renders the original price with a strikethrough and the sale price as the current amount. This is standard e-commerce UX that every customer already understands. The original service price is never modified. It stays stored as-is. The sale price is a separate field layered on top. When the sale ends (either manually or by date), the service automatically reverts to the original price with zero action required from the business. Sale pricing should stack with coupon codes if the business wants both. If a service is on sale for $149 (down from $199) and the customer also applies a valid coupon code for 10% off, the coupon applies to the $149 sale price — resulting in $134.10. This lets businesses run public sales AND reward specific customers (referrals, VIPs, email subscribers) with an additional code-based discount on top. If the business does not want stacking, they can simply not issue coupon codes during the sale period. The sale price should be respected everywhere the service price appears: the public booking page, the New Booking screen when staff books internally, calendar confirmations, invoices, and any workflow merge fields that reference the service amount. Why this matters beyond just convenience: Strikethrough pricing is one of the most well-documented conversion drivers in retail and e-commerce. Showing what the price was next to what the price is now creates anchoring — the customer perceives the deal relative to the original value, not in isolation. A service at $149 feels different when it is sitting next to a crossed-out $199 than when it is just listed at $149 with no context. Right now, every e-commerce platform (Shopify, WooCommerce, Square, Stripe) supports native sale pricing with strikethrough display. Services V2 is GHL's commerce engine for service businesses, but it is missing this basic merchandising capability. Adding it would bring Services V2 to parity with what every product-based commerce platform already offers and unlock seasonal promotions, flash sales, and strategic discounting for the thousands of service businesses on GHL — without adding friction to the booking flow.