Most proactive chat trigger rules fire on dwell time alone, which is why visitors associate the little popup with spam. The fix isn't to turn proactive chat off — it's to combine page URL, dwell threshold, and identified-visitor traits (plan tier, MRR, account age) so the message lands when a real conversation is possible. Below are nine rules that hold up in 2026, with the targeting logic written out.

Key takeaways

• Proactive chat trigger rules built on dwell time alone fire on 80%+ of visitors who have no buying intent (estimate), which trains your team to ignore the channel.
• The strongest rules layer three signals: page URL, dwell threshold, and visitor traits passed via your identify call (plan, MRR, role).
• Different page types deserve different dwell thresholds — 25 seconds on pricing is hesitation, 25 seconds on a docs page is normal reading.
• Identified customers with paid plans should trigger faster and more often than anonymous visitors; the conversation has higher expected value.
• Cap firing to one message per visitor per session and exclude visitors who already messaged in the last 14 days.

Why dwell-time-only rules quietly fail

A dwell-only rule treats every visitor identically. Someone comparing five vendors on your pricing page gets the same nudge as a logged-in customer reading the same page to plan an upgrade. The first visitor is annoyed; the second is the conversation you actually wanted.

The pattern shows up in chat ticket logs everywhere: high firing rate, low reply rate, and the replies that do come are mostly "no thanks" or silence. Agents start muting the queue. Within a quarter, the team treats proactive chat as noise rather than a pipeline source.

The alternative isn't fewer triggers — it's tighter ones. Each rule below pairs a page URL pattern with a dwell threshold and, where possible, a visitor trait. The result is fewer fires, higher reply rate, and conversations your team takes seriously.

The targeting building blocks

Before the nine rules, three building blocks make all of them work.

Page URL targeting. Most platforms support a pageUrlContains match. Use specific paths (/pricing, /integrations/salesforce, /docs/api/webhooks), not domain-wide matches.

Dwell time threshold. Time on the current page in seconds. Anything below 15s is reflexive scrolling; anything above 90s on a marketing page is unusual and worth noticing.

Visitor traits. This is where most setups fall short. If your chat widget exposes an identify call, the host site can attach traits like plan, mrr, accountAgeDays, or role. Helptal's live chat widget accepts up to 30 keys per visitor via Helptal.identify({...}), and those traits surface on the live-visitor row before any message is sent.

With those three signals composable, you can write rules like "fire on /pricing after 30 seconds, but only for visitors where plan === 'free' and mrr > 0." That's the granularity that separates useful proactive chat from spam.

The 9 rules

1. Pricing page hesitation, anonymous visitor

Trigger: pageUrlContains: /pricing AND dwellSeconds >= 45 AND identified === false

Message: "Comparing plans? Happy to answer questions about which tier fits your team size."

45 seconds is the threshold where a visitor has read past the headline and is comparing tiers. Earlier than that and you're interrupting; later than 90s and they've probably bounced to a competitor tab.

2. Pricing page, identified free user

Trigger: pageUrlContains: /pricing AND dwellSeconds >= 20 AND plan === 'free'

Message: "Looking at upgrades? I can pull up your current usage and tell you which plan makes sense."

Identified users get a faster threshold and a more specific message. They've already chosen you; the question is which tier, not whether.

3. Enterprise plan page, any visitor

Trigger: pageUrlContains: /enterprise OR /contact-sales AND dwellSeconds >= 30

Message: "Want to skip the form? A quick chat can usually replace a discovery call."

Enterprise pages have a tiny audience and a huge per-visitor value. Lower threshold, no trait filter — every visitor on these pages is worth an attempt.

4. Integration page with matching trait

Trigger: pageUrlContains: /integrations/[name] AND dwellSeconds >= 25

Message: "Setting up the [Integration] connection? Happy to walk through the auth step if you get stuck."

Integration pages signal active implementation, not browsing. Even short dwell deserves a nudge because the visitor is mid-task.

5. Docs page, paying customer with active issue

Trigger: pageUrlContains: /docs/ AND dwellSeconds >= 120 AND mrr > 0

Message: "Stuck on something? I can pull up your account and look at the request logs with you."

A paying customer reading docs for two minutes is usually debugging. Anonymous visitors on docs are learning — leave them alone. The combination of long dwell + paid trait is the cleanest "this person needs help right now" signal you have.

6. Cart or checkout abandonment (B2B SaaS variant)

Trigger: pageUrlContains: /signup OR /checkout AND dwellSeconds >= 60

Message: "Quick question about the signup flow? I'm here."

Self-serve B2B SaaS has the equivalent of cart abandonment — visitors who get to the credit card form and stall. One minute on /checkout means they hit a real blocker.

7. Comparison or alternatives page

Trigger: pageUrlContains: /vs- OR /compare OR /alternatives AND dwellSeconds >= 40

Message: "Doing vendor research? I can tell you honestly where we fit and where we don't."

Visitors on comparison pages are in active evaluation. The message tone matters: don't pitch — offer perspective. Reply rates on this rule should run 2-3× the average proactive message (estimate based on intent density).

8. Returning visitor on any high-intent page

Trigger: visitCount >= 3 AND (pageUrlContains: /pricing OR /demo OR /contact) AND dwellSeconds >= 20

Message: "Welcome back. Anything I can help you decide?"

Third-time visitors on a conversion page are stuck on something specific. Lower the dwell threshold because their intent is already established by visit history.

9. Identified expansion candidate

Trigger: mrr > 0 AND accountAgeDays > 60 AND pageUrlContains: /pricing OR /add-ons

Message: "Looking at expanding? I can check your seat usage and see what makes sense."

This is a customer-success rule, not a sales rule, but it runs through the same proactive chat engine. Existing customers on pricing pages are evaluating expansion. Route these to a CSM, not a sales rep.

Rule firing matrix

Guardrails every setup needs

Three settings apply to every rule above:

1. One fire per visitor. Once a visitor sees a proactive message in a session, no other rule fires. Stacking is what makes chat feel spammy.
2. Suppress recent conversations. Don't fire if the visitor messaged you in the last 14 days. They already know you exist.
3. Respect Do Not Track. If navigator.doNotTrack is set, skip heartbeat and skip proactive rules entirely. It's the right thing to do and it removes a class of compliance risk.

How Helptal fits in

Helptal's live chat on the Growth plan and above includes live-visitor tracking and proactive chat automation rules built around the page URL + dwell + trait model described here. The Helptal.identify({...}) call attaches up to 30 traits per visitor (plan, MRR, role, account age) that surface on the live-visitor row and feed your rules at /settings/proactive-rules. Each rule fires once per visitor automatically, and you can also start chats manually from the live-visitor panel when a rule isn't the right fit.

Frequently asked questions

What is the right dwell time threshold for a proactive chat rule?

It depends on the page. Pricing and comparison pages reward 30-45 seconds — long enough that the visitor is comparing, short enough that they haven't moved on. Docs pages need 90-120 seconds because reading is normal. Enterprise and contact-sales pages can fire as early as 20-30 seconds since every visitor has unusual value.

Should proactive chat fire on anonymous visitors at all?

Yes, but only on high-intent pages with longer dwell thresholds. Anonymous visitors on pricing, enterprise, and comparison pages are worth a nudge after 40-45 seconds. Anonymous visitors on docs or blog pages are not — they're researching or reading, and proactive messages just create friction.

How many proactive chat rules should a B2B SaaS site run at once?

Six to ten well-targeted rules works for most teams. The constraint isn't the rule count, it's the firing budget per visitor. Cap firing at one message per visitor per session no matter how many rules they technically match, and you'll get most of the value without the spam reputation.

What visitor traits matter most for proactive chat targeting?

Plan tier (free vs paid), monthly recurring revenue, and account age cover most use cases. With those three, you can distinguish prospects from customers, free from paying, and new from established. Add role (admin vs end-user) if you sell to multiple personas inside the same account.

How do you measure whether proactive chat trigger rules are working?

Track reply rate, qualified conversation rate, and pipeline attribution per rule. A healthy proactive rule has a reply rate above 15% and a qualified conversation rate above 40% of replies (estimates from B2B SaaS norms). Rules below those thresholds should be retired or retargeted.

Pick two or three rules from the list and ship them this week — the pricing-anonymous rule, the docs-paying-customer rule, and the comparison-page rule are the highest-leverage starting points. Measure for two weeks before adding more. If you're evaluating tooling, Helptal's free plan includes chat and the broader feature set described in this article on paid tiers.