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.