Automations

User (Team Member) Replied Trigger Needed
Right now in GHL there is a trigger called "Customer Replied." It fires when a customer sends us a message. That part works great. But there is no trigger for when a user (a team member, a staff member, an agent) replies back to the customer. This is a huge problem. Here is the problem in simple words: A customer messages us. We are supposed to message them back. Sometimes our team does. Sometimes our AI does. Sometimes nobody does — and we don't find out until the customer gets angry and leaves. We have no way to know if a user replied or not. GHL does not tell us. What we want to build (but can't): Customer sends us a message Wait 5 minutes Check: did a user reply? If YES → great, do nothing If NO → send an alert to the owner: "Hey, nobody replied to this customer!" Step 3 is impossible right now. There is no "User Replied" trigger. What we need GHL to build: A simple new trigger called "User Replied" that fires when any team member sends a message to a contact. With filters for: Which user replied Which channel (SMS, email, WhatsApp, Instagram, Facebook, Live Chat) Which assigned user it was meant for Also please add "User Reply" as an option on the Wait action, the same way we already have "Contact Reply." Why this matters: AI agents are everywhere now. When the AI misses a message, we have no way to catch it. Sales teams need SLA tracking — "did my rep reply in 5 minutes?" is impossible to answer today. Drip sequences keep firing even after a human has already replied, which makes customers angry. Shared inboxes need this to know who is handling what. This idea has had hundreds of votes for two years. Please build it. It is the single biggest missing piece for anyone running AI or team-based customer conversations on HighLevel. Thank you.
8
·
New Feature
Add "Service Booking End Time" to the Wait Action — Event / Service Booking Time Only References Start Time
The Wait action's "Event / Service Booking time" type currently only references the service booking start time. There is no option to wait relative to the booking's end time. The only choices are After, Before, or Exact time — all measured from when the appointment starts. This is a real problem for any automation that needs to fire relative to when a job is expected to finish, not when it starts. Here's a concrete example. A mobile auto detailer runs three service types through Services V2: Interior Detail — 1.5 hours Full Detail — 3 hours Ceramic Coating — 7 hours After the job is done, the detailer needs an internal notification with a post-job survey link. Right now the only option is a fixed wait after the start time — say 30 minutes. That works for a 1.5-hour interior detail (the survey arrives while they're wrapping up), but for a 7-hour ceramic coating, the survey link lands 30 minutes into an all-day job. The detailer either ignores it or forgets about it entirely by the time the job is actually done. The workaround is to split the workflow into separate versions per service category — one with a short post-start wait for quick jobs, one with a long wait for full-day jobs. That means duplicating the entire workflow just to change one wait duration. And if the detailer adjusts a service duration in Services V2, the workflow wait doesn't update — it's hardcoded. What we need: Add an "End Time" reference option to the Event / Service Booking time wait type. The dropdown that currently only measures from the booking start time should also offer the booking end time as a reference point. This way you could configure: Before 30 minutes → Service Booking End Time = survey link arrives 30 min before the scheduled end (detailer gets it while still on the job, ready to fill out when they finish) After 15 minutes → Service Booking End Time = follow-up fires 15 min after the job was supposed to wrap The end time is already calculated by the system — Services V2 knows the service duration and the start time, so the end time exists. The Date/Time Formatter action already exposes "appointment start/end datetime" as source options, and the webhook payload includes end time. The Wait action is the one surface that doesn't let you reference it. This would make the Event / Service Booking time wait type consistent with how other actions in GHL already handle booking end times, and it would eliminate the need for duplicated workflows or hardcoded wait durations that break when service durations change. One small addition to the wait dropdown. Massive unlock for every service business running post-job automations.
0
·
Enhancement
Load More