The default behavior of most chat widgets is to appear the moment a page finishes loading. We think that's the wrong default, and we built AIVA's widget to not do it. A visitor who's been on your site for half a second hasn't formed a question yet. Interrupting them before they have one doesn't feel helpful — it feels like being followed around a shop by someone asking if you need help before you've looked at anything.
Trigger design is really a question about timing and place: when has a visitor shown enough intent that an offer to help is welcome instead of intrusive, and which pages are the wrong place to ask at all.
The default we landed on
A visitor has to be on the page for 30 seconds before the widget offers itself. That's long enough to rule out the bounce — someone who clicked in from search, scanned the headline, and left — and short enough to still be there for the visitor who's actually reading, comparing, or hunting for a specific answer. Thirty seconds isn't a magic number so much as a reasonable proxy for "this person is still here on purpose."
Checkout pages get a different rule entirely: the widget can trigger immediately on /checkout, because that page is the opposite situation. Nobody arrives at checkout to browse — they arrived to finish something, and the questions that come up there (does this ship to my area, do you take this payment method, is this the final price) are the ones most likely to end in an abandoned cart if nobody answers them in the moment. Intent is already established before the page even renders. There's nothing to wait for.
Why time-on-page, and not something fancier
There are more precise signals we could trigger on — scroll depth, how far someone's moved through a pricing table, whether this is a first visit or a fifth. Each of those is a genuinely better proxy for intent than a flat timer in specific cases. The trade-off is that they're harder to explain and harder to configure. A business owner setting up trigger rules in a dashboard can reason about "30 seconds" immediately and correctly. "Trigger when scroll depth exceeds 60% and this is a returning visitor's second session" is a better rule in theory and a much harder one to set with confidence, or to debug when it doesn't behave the way you expected. We'd rather ship a default that's slightly less precise and completely legible than one that's marginally smarter and opaque to the person configuring it.
That's also why the checkout exception is page-pattern based rather than behavior-based — /checkout is unambiguous in a way that "seems like they're about to buy something" isn't. Simple signals are more predictable, and predictability matters more than marginal precision when the person tuning the rule isn't an engineer.
Knowing where not to show up
The other half of "smart" is staying out of the way. The widget stays hidden on blog pages by default — someone reading an article came to read, not to be sold to or supported, and a chat bubble competing for attention against the actual content they clicked in for is a worse experience, not a better one. It's also hidden for visitors who are logged in as the business's own admin — nobody wants to see their own customer-facing support widget nagging them while they're doing their own work on their own site.
The right question was never "how do we get more people to click the widget." It was "which pages does this visitor's intent actually match today."
The edge cases a fixed timer has to handle
A flat 30-second rule sounds simple until you consider how people actually browse. A visitor who opens your site in one tab, switches to check something else, and comes back four minutes later hasn't really spent four minutes reading — the timer tracks active time on the page, not wall-clock time since the tab opened, so a backgrounded tab doesn't quietly rack up engagement it never earned. A visitor on a slow connection is a subtler case: if a page takes eight seconds to finish loading images and fonts, the 30-second clock still needs to start from something reasonably close to when the page became usable, not from the first byte, or slow-connection visitors get interrupted before they've had a fair chance to actually read anything.
Multiple tabs raise a different question. A visitor who opens the same site in two tabs shouldn't see two independent widget instances quietly diverge — if a conversation starts in one tab, the other tab needs to reflect that state rather than offering a second, disconnected chat as if nothing happened. And a visitor who closes the widget without engaging shouldn't have it aggressively re-trigger on every subsequent page view in the same session; a widget that reappears immediately after being dismissed reads as pushy rather than helpful, which undermines the entire point of triggering thoughtfully in the first place.
Mobile visitors get their own consideration too. Someone scrolling a product page on a phone is interacting with the site differently than someone on a desktop with a mouse hovering near a corner — time-on-page still applies, but where and how the widget bubble presents itself has to account for a much smaller, more crowded screen, where a poorly placed trigger can sit on top of a call-to-action button instead of beside it, the same kind of overlapping-content problem accessibility guidelines warn against for any fixed-position element on a small viewport.
Measuring whether the rules are actually working
Trigger rules aren't something to set once and forget. A business can see, through AIVA's analytics dashboard, whether widget conversations are actually resolving or just opening and going nowhere — a strong signal that trigger timing, not the conversation quality itself, might be the thing worth adjusting. A widget that triggers too early on a considered-purchase page might collect a lot of conversations that never convert; one that triggers too late might miss visitors who needed help before deciding to leave. The dashboard is what turns "we picked 30 seconds" from a guess into something a business can actually verify against their own traffic.
None of this is fixed
These are defaults, not rules. A business selling a considered, expensive service might want a longer delay than 30 seconds — a visitor there needs more time to actually engage before an interruption is welcome. A business running a flash promotion might want the widget live everywhere, immediately, for a week. The trigger rules are configurable per page pattern, per timing, per visitor state, because "when should we interrupt someone" doesn't have one universal answer — it depends on what the business sells and what that specific page is for.
What doesn't change is the underlying principle: a chat widget earns the right to appear by matching the moment, not by showing up as early and as often as technically possible. Most widgets treat visibility as the goal. We treat relevance as the goal, and visibility as something that follows from getting relevance right. If you're setting this up for the first time, pasting the widget in takes minutes — the trigger rules and the branding are what's actually worth spending time on, and neither requires a developer to adjust. See the full widget on the platform page, or start free and test your own trigger timing against real visitors.