Chat Widget

THE PROBLEM The Chat Widget's welcome message is a single static text field. Every visitor sees the same line no matter when they arrive — 6 AM or 11 PM. There is no merge tag, no conditional logic, and no way to pass a greeting value through the embed snippet at load time. Confirmed by GHL Support (ticket #6147878). THE REQUEST Allow the welcome message to change based on time of day, the way ChatGPT and Claude greet users: Morning → "Good morning! How can I help you today?" Afternoon → "Good afternoon! How can I help you today?" Evening → "Good evening! How can I help you today?" POSSIBLE IMPLEMENTATIONS — any one of these would solve it: A merge tag such as {{time_of_day_greeting}} usable in the welcome message field Multiple welcome messages with configurable time windows, so we define the ranges and copy ourselves A documented widget config option — passing a welcomeMessage value at initialization — so we can compute it client-side IMPORTANT: USE VISITOR LOCAL TIME The greeting must be calculated from the visitor's browser time, not the sub-account timezone. Most sites get traffic across multiple regions, so an account-level calculation would show the wrong greeting to a large share of visitors. "Good evening" at 9 AM is worse than no greeting at all. WHY IT MATTERS The chat widget is the first touchpoint for inbound leads on most sites. A time-aware greeting makes it read as live and human rather than canned, which affects whether visitors engage with the bot at all. The only workaround today is injecting custom JavaScript to rewrite the greeting in the DOM after the widget mounts. That is unsupported, breaks whenever the widget markup changes, and has to be maintained per site — not viable across multiple sub-accounts. If you run the chat widget for clients, please upvote.

It is great to allow a chatr widget in pcommunities and c;icnt portal, but being able to select an AI Agent should be allowed. Or AI Agent to be allowed for a widget, so we can add that to the community or website, whatever.

It would be a huge productivity improvement if HighLevel's emoji picker displayed recently used emojis at the top. Right now, every time we want to use the same emojis, we have to search for them again or copy and paste them from another app, which is time-consuming. A "Recently Used" section, similar to what most messaging apps have, would make conversations much faster and improve the overall user experience, especially for teams that communicate with leads all day. We hope this feature can be added soon. Thank you!

One of our clients requested the ability to make the chat bubble prompt disappear after a certain amount of time, such as 3 or 4 seconds. This would help prevent it from becoming distracting to website visitors. While they understand that users can manually close the prompt using the close (×) button, they believe that automatically hiding it would create a cleaner website experience and make the customer journey smoother. They also asked whether it would be possible to display the chat widget prompt only on desktop devices. On mobile devices, the prompt takes up a significant amount of screen space, which can negatively affect the user experience. Either of these options would be valuable on its own, but having both would provide the best experience.

SUMMARY (the short version) If you've custom-branded your Chat Widget, one setting — "System message text color" — controls several different pieces of text that sit on different colored backgrounds at the same time: the post-chat feedback prompt, the "start a new chat" button text, and the legal/consent disclaimer under the contact form. Because those backgrounds are different colors, there is no single color value that stays readable on all of them. Pick a color that reads on the dark area and the consent disclaimer on the accent-colored panel becomes hard to read. Pick one for the panel and the rest suffers. Requesting that these be split into separate color controls. WHO HITS THIS Any agency that (1) customized the widget colors beyond the default theme and (2) uses the legal/consent checkbox + disclaimer. If both are true, you likely already have a consent disclaimer that's lower-contrast than you'd want and no way to fix it without compromising the rest of the widget. WHY IT MATTERS (not just cosmetic) Of the texts tied to this one setting, the legal/consent disclaimer is the one that fails contrast on the accent panel, and it's also the one that carries the SMS/email consent language. So this isn't only a branding annoyance — it means agencies can't reliably guarantee the consent text is legible without degrading the rest of the widget. The other affected texts (feedback prompt, restart button) are cosmetic by comparison. THIS HAS ALREADY BEEN DONE ONCE — THIS IS THE NEXT STEP This is not new architecture. The August 8, 2024 "Chat Widget Upgrade" split header message and welcome message text colors out of previously shared tokens — the welcome message color was previously bound to "System message text color." That release already established the pattern and the mechanism for carving a surface out of this shared setting. This request applies the same approach to the surfaces that release didn't cover. THE ASK Split the texts currently bound to "System message text color" into independent color controls. Minimum viable version: a dedicated color for the legal/consent disclaimer, separated from the feedback prompt and restart button. That alone fixes the only readability-failing, compliance-relevant case. Full per-surface separation is the preferred end state. ALSO DESCRIBED AS (so others can find this) System message text color shared across multiple elements; consent text unreadable; disclaimer text color; legal disclosure low contrast; chat widget text not readable on colored background; separate / individual / granular text color settings; per-element color customization in Live Chat widget. REFERENCE Originated from premium support ticket 5476653. Reproducible from a standard Live Chat widget with custom colors and the consent disclaimer enabled.

Each Chat Widget customization can be select its own agent specifically. So, we can utilize different different chat widgets on different funnels by minimizing one step of transferring bot. Also if we have function specific page like technical support so the chat widget initiates with its own specific agent on that page.

Hello team, The new chat widget whit voice AI is great, however not being able to record and transcript the call we are missing what's happening during these call , we are not able to attack the pain point or understand customer experience which allows us to enhance AI behavior. Is there any plan regarding launching this feature soon?

Hi HighLevel team and community! Currently, Conversation Agent widgets can be 'steel' and embedded anywhere without restrictions, creating a major security gap. I suspect one of my client's chatbots was hijacked—conversations appearing have zero relation to their business, but I can't check which URL the widget was used on. Why this matters? Admins need to whitelist specific URLs (e.g., only client.com pages) to prevent unauthorized use and track abuse. This is a critical security flaw that could expose sensitive data. Has anyone experienced this? Vote if you agree—let's secure our widgets! #GHL #ConversationAI #Security #Widgets #FeatureRequest

The article "Conversation AI Bot – How to Automate Customer Chats" ( https://help.gohighlevel.com/support/solutions/articles/155000001335-conversation-ai-bot-explained ) states that supported channels can be configured by going to Settings > Conversation AI. However, there is no Conversation AI option under Settings in the sub-account UI. The correct navigation path is AI Agents > Conversation AI. The documentation needs to be updated to reflect the actual UI navigation.