Start chat: 11 live chat limitations to test in 2026

What breaks when you add a Start chat button: widget blockers/CSP, 5‑minute reply expectations, JWT identity checks, plan limits, and Telegram routing.

Sev LeoLinkedInTwitter

Sev Leo is an SEO expert and IT graduate from Lapland University, specializing in technical SEO, search systems, and performance-driven web architecture.

Start chat, clarified

Android meaning

On Android, “start chat” usually has nothing to do with a website. It’s commonly a button or utility inside an app that lets you begin a WhatsApp/Telegram-style conversation quickly, sometimes without saving a contact first. That’s why a “start chat” search so often lands you in Google Play listings or mobile how-tos.

It also gets tangled with Google Chat: “start chat” can simply mean opening the Google Chat app and starting a direct message thread there. Useful, but it’s a consumer messaging workflow—not a decision about adding chat to your product site.

Website meaning

In this article, “Start chat” means the on-site call-to-action: the chat bubble or button on your website that opens a live chat widget so a visitor can message your team.

Search results are misleading because the same phrase is used for unrelated things like the Amazon Connect StartChatContact API (a developer endpoint for contact-center chat) and mobile chat starters. None of that answers the buyer’s real question: what breaks when you put a “Start chat” CTA into production.

So the evaluation here is narrow and practical: the on-site widget decision—whether it reliably shows up where you expect it, can be operated day-to-day by a small team, and fits your security and plan constraints. Even mainstream messengers can be configured to only appear on “trusted domains,” which is the kind of detail search results won’t surface when you’re just trying to choose a widget.

Invisible widget failures

A “Start chat” button only exists if the widget’s JavaScript actually loads and runs in the visitor’s browser. “Activating chat” is therefore two jobs: install the vendor’s script snippet on your site, then prove it still appears under real-world blocking and security rules.

1. Confirm the widget script is present and executing
   Put the snippet on the pages where you expect “Start chat” to appear, publish, and then check the page in a fresh browser session. If the bubble never renders, treat it like a production outage, not a design tweak.

2. Rule out script blocking (ad blockers / privacy extensions)
   Ad blockers and privacy extensions can block chat widgets entirely by blocking their JavaScript. Intercom’s own troubleshooting notes that some ad blocking extensions block JavaScript “such as the Messenger,” which is exactly how you end up with a site that “has chat” but visitors can’t see it.

3. Check your CSP first when the bubble is “invisible”
   CSP (Content Security Policy) is a browser-enforced allowlist delivered via HTTP headers; if you don’t explicitly allow a third-party script or connection, the browser will refuse it. Intercom documents that CSP misconfiguration can make the Messenger “fail to load or [be] invisible,” and their fix is concrete: allowlist the domains the widget needs (for example, widget.intercom.io, js.intercomcdn.com, .intercom-chat.com, and api-iam.).

4. Verify any “trusted domains” / domain allowlist settings
   Many chat tools let you restrict where the widget is allowed to appear. Intercom’s Messenger can be restricted to a list of “trusted domains,” and once set it “will only appear on these domains”—so a missing www, a new custom domain, or a staging-to-production move can silently turn “Start chat” off. Practically, teams disagree on how strict to be: leave the trusted-domain list empty during development/testing so the widget renders anywhere, then lock it down in production so it can’t be embedded on unintended domains.

5. Make visibility a release check, not a one-time setup task
   Test at least one “hardened” browser (extensions on + your real CSP headers) before you ship. If you can’t reliably make the bubble appear, you’re not choosing UX—you’re choosing whether support will exist for a slice of visitors.

Five-minute expectation

Adding a “start chat” button isn’t just adding a channel. You’re also publishing a response-time promise—whether you meant to or not.

• Limitation #4: live chat sets a minutes-level clock. HubSpot reports that 66% of consumers (surveyed in the U.S., n=100) expect a response within five minutes when they use live chat for customer service. If you can’t reliably answer inside that window, the chat bubble becomes a “we’re ignoring you” button.

• Limitation #5: small teams inherit interrupt-driven coverage. With one person (or a tiny team), “minutes-level” chat means you either (a) intentionally schedule coverage blocks where someone is watching and responding, or (b) accept constant context switching throughout the day. If you treat chat like email—“I’ll get to it later”—you’re breaking the expectation the UI created.

• Limitation #6: you must pick an offline strategy—and own the trade-off. Practitioners disagree on the right move:

• Hide chat when nobody’s online so visitors can’t start a conversation that won’t be answered.

• Leave it visible, but set expectations (your hours, typical reply time, and what to do for urgent issues).

If you can’t commit to minutes-level replies, design your “offline” path on purpose: clear availability, an away message that redirects, and a fallback channel that you actually check.

Identity can be faked

A lot of “start chat” setups treat identity as a couple of fields in the widget. That’s client-side identity: the browser tells you who the user “is,” and the browser is the attacker’s playground.

1. Decide whether this chat will ever touch account data
   If agents will look up an order, subscription, invoices, or reset access, you’re in “logged-in support” territory.

2. Assume name/email fields are cosmetic, not proof
   A visitor can type any email they want. If your workflow trusts that field, you’ve created an impersonation path.

3. Add signed identity verification, not more form fields
   Use a JSON Web Token (JWT)—a server-generated, signed token—to assert the user’s identity to the chat provider. Intercom explicitly warns that without Messenger identity verification, “a bad actor could gain unauthorised access to the data in your workspace through impersonation of your real users.”

4. Gate “account help” behind verification
   If the chat session isn’t verified, treat it as anonymous: general FAQs only, and route the user to sign in before you discuss anything specific.

If a lightweight widget can’t do signed verification, keep it for pre-sales and public questions—not support tied to an account.

Plans change the product

Your “start chat” button is a feature on day one. Six months later, it’s a policy: what you can store, integrate, and show to customers is decided by the plan you’re on.

Gloss: Retention = how long your chat history is kept. An API is a developer interface for syncing data. A rate limit is a hard cap on requests per minute.

If you’re budgeting chat, don’t price the widget—price the version of “start chat” you’ll still be allowed to run after history, integrations, and branding requirements show up.

Telegram routing trade-off

Routing your website “start chat” to Telegram is the no-dashboard move: messages land where you already are, and you can reply fast from your phone. The trade-off is that you inherit Telegram’s bot rules and limits.

Ship when the main problem is missed chats because nobody is watching an inbox, and you’re happy with a lightweight “message in, message back” loop.

Don’t ship when you need proactive outreach or controlled workflows: Telegram’s Bot API docs are blunt that bots can’t start conversations with users (the user has to message first).

If you land on “don’t ship,” you’re not failing at live chat—you’re picking the other category: a helpdesk-style tool with its own operator console (for example, Crisp).

Eloqra in practice

Eloqra is the concrete “live chat → Telegram” pattern: each visitor message is delivered to Telegram, and your replies from Telegram appear back inside the on-site chat. Setup is straightforward: connect Telegram via their bot, then drop a single script snippet on the site; configuration lives in a small web dashboard, but you don’t keep it open to reply. Eloqra also emphasizes a lightweight widget script (under ~5kb) that loads after your page.

The win is operational: you can cover chat without living in yet another support tab. The cost is that your day-to-day support inbox is now Telegram, with Telegram’s bot constraints along for the ride.

Prove chat works in production

A “Start chat” button isn’t real until the widget consistently loads for real visitors—so treat visibility like a release check, and debug blockers, CSP, and domain allowlists before you debate UX. Then be honest about the promise you’re publishing: either staff minutes-level replies, or deliberately design the offline path so people aren’t left hanging. If the conversation could touch account data, don’t trust whatever the browser types into name/email fields—gate “account help” behind signed identity verification and keep unverified chats generic. And choose the category that matches your operations: routing chat to Telegram is built for fast replies without living in a dashboard, while a helpdesk-style console is the better fit when you need controlled workflows beyond “message in, message back.”