Automations

{{appointment.start_time}} needs time zone added
Expectation: when an appointment is booked, {{appointment.start_time}} (and other similar time-related fields) for use in workflows includes the time zone so it is clear to the client when their appointment is when they receive confirmation emails and reminder/emails and texts generated through workflows, regardless of where they happen to be physically (in the time zone where they booked the appointment, in a different time zone than where they booked the appointment (i.e., the time zone of the business), etc.). Problem: Because GHL autodetects time zone of the client when they are booking an appointment, it is causing confusion. This autodetection is using the assumption that the client will attend the appointment in the time zone in which they booked the appointment. It is not taking into account appointments that are for the physical location of the business that were booked in a different time zone. This issue has already caused problems/confusion with appointments several times. Example: Client booked an appointment with the business (which is on Central time) while they were in the Mountain time zone. They then returned to the Central time zone when the appointment was to occur, but all of the reminders that were being sent from the workflow were for Mountain time without specifying the time zone. The client appointment was supposed to be at 2:45 pm Central, but everything they were being sent said that it was 1:45 pm Central, which thus lead to confusion. If this is not fixed: this problem causes loss of revenue, confusion, and business reputation problems. This is unacceptable. Also, I realize that there are a couple of other tickets that touch on this, but the acceptance criteria is less direct.
1
Add a "Reply To" automation action that is able to reply to previously sent emails from the automation, keeping all correspondence in the same email thread.
Problem: People get dozens of emails every day. When engaging with customers, it is easy for them to lose track of what they have been sent, and what the previous contact with you was about. Especially when doing things such as cold outreach, if you send a customer 3 emails over 3 weeks, chances are they will have completely forgotten about the first email by the time the second email arrives. Solution: Email threading depends on how the email headers are set. Every email has a unique ID assigned to it. When a new email is sent, if the system includes a reference back to the ID of the earlier email, mail clients like Gmail and Outlook treat it as part of the same conversation thread. Right now, GoHighLevel sends every automation email as a brand-new message with no link back to the previous one. That means each follow-up starts a separate thread, which quickly clutters a prospect’s inbox and loses the context of earlier emails. Other outreach platforms, such as Lemlist, solve this by carrying the ID of the first email into all follow-ups. This makes the second and third emails appear as natural replies in the same conversation. When the recipient opens their inbox, they see one single thread with the entire conversation stacked together. The outcome: A single conversation thread that contains the first email and all follow-ups. Easy to scroll back and see what the first message said. The exchange feels like an ongoing conversation rather than multiple disconnected cold emails. Why this matters: Prospects are far less likely to lose track of the earlier context. It improves open rates and reply rates, because the email doesn’t feel like another fresh cold outreach. It matches how competing tools already operate, which prevents users from needing external platforms just for this one feature. Implementation idea: Provide an option in automation email steps to either: Send the follow-up as a new thread (current behaviour), or Send the follow-up as a reply to a previous step (by linking back to the earlier email ID). This would give agencies more control and help GoHighLevel deliver a better outreach experience.
0
Load More