A proactive message is one the customer did not ask for. Which signals are worth acting on, what a message has to contain to be support rather than noise, and how to measure win-back without fooling yourself.
Also available in Dutch: Proactieve klantenservice voor klanten die dreigen af te haken
Most support is reactive by design: someone has a problem, they write in, you answer. Proactive support inverts that — you send the message first, because something you can already see predicts a problem the customer has not reported. Done properly it removes tickets and keeps customers. Done badly it is marketing automation wearing a support costume, and customers tell the difference immediately.
The working definition is narrow on purpose: a message the customer did not ask for, sent because a signal predicts a problem, containing something they can act on. Three tests separate it from a newsletter with a support-coloured header. Is the trigger a specific event in this customer's own record, not a date on your calendar? Does it state a fact they do not have? And would an agent with the same information have sent it?
Fail any of the three and you are broadcasting. "How are you getting on?" fails all three. "Your parcel has been at the depot for two days — we have opened an investigation with the carrier and will update you Thursday" passes all three, and it is the most effective ticket-avoidance message in retail.
Rank candidate signals by how certain the underlying problem is. High-certainty signals justify an unsolicited message; low-certainty ones like "has not logged in for thirty days" justify making yourself easier to find, and nothing more.
| Signal | Certainty | The message that earns its place |
|---|---|---|
| Shipment past your promised delivery date | High — the fact is in your carrier data. | State the delay, what you have done, and when they hear from you next. Most tickets avoided per hour of work. |
| Failed or expiring payment on a subscription | High — the payment provider told you. | The fact, the consequence with a date on it, and a link that fixes it. Anything longer reads as a dunning letter. |
| A second contact about the same issue within days | High — it is in your own conversation history. | Not a message but a routing decision: a named person, with the earlier thread attached, before they ask a third time. |
| A negative rating on a conversation you closed | High — the customer told you directly. | A short follow-up from someone who can change the outcome. Low effort, high return, rarely done. |
| Repeated visits to your cancellation or returns page | Medium — intent is clear, the reason is not. | Offer to answer the question, do not pitch. An on-site nudge is the right weight; an email is not. |
A proactive message has a higher bar than a reply, because the customer did not invite it. Two elements are non-negotiable. The fact: what happened, with the identifier they recognise — the order number, not an internal reference. And the remedy: what you are doing, what they can do, or when they hear from you. A fact with no remedy is an alarm; a remedy with no fact is a coupon.
On-site nudges are the easy kind: the chat widget is already on the page, so it can open a small message based on what the visitor is doing right now. In CustomerEagle these are proactive rules, under Automations in the dashboard, part of the automations allowance that starts on the Standard plan. A rule is a message plus conditions the widget evaluates in the browser: a fragment the page URL must contain, where the visitor's traffic came from, desktop or mobile, a minimum number of visits or page views, and a cooldown in hours. On top of a plain delay, a rule can instead arm on a behavioural trigger — the pointer leaving through the top of the window (desktop only; there is no cursor to read on a phone), scrolling past a percentage of the page, or a stretch of idle time — and whichever of those happens first is what fires it. A schedule narrows any rule further, to a day-of-week list and a time-of-day window in a timezone you set or the visitor's own, including overnight spans. Rules run in priority order, at most one fires per page, and a visitor who already has a conversation open is skipped. Each rule counts impressions, clicks and conversations started — enough to tell a rule that works from one that annoys people, though those counters live on the rule, not on the conversation: nothing in the inbox marks a given conversation as having started from a nudge.
Two honest limits. The cooldown lives in local storage in the visitor's own browser, so a new device or a cleared cache resets it — treat it as politeness, not a hard cap. And the targeted variant, which attaches an audience segment to the same nudge, matches on attributes you pass in when you identify a signed-in customer: email, name, language and any metadata your site sends. An anonymous visitor matches no segment at all. Which plan carries which automation volume is on the pricing page.
The second kind is signal-driven outreach: something happens in another system — a parcel misses its date, a card is declined, an onboarding step stalls — and a message goes out without the customer being anywhere near your site. That is the kind that moves retention, and it is the hard one, because the trigger has to be computed where the fact lives. Today that is your own stack's job: your shop, your billing provider or a workflow tool watches the signal and sends the message. A support platform's contribution is downstream — the reply lands in the shared inbox with the customer's history attached. Be sceptical of a demo that blurs the two: a timed greeting on the pricing page is a reasonable feature, but it is not churn prevention.
Proactive messages spend a budget you cannot see. Each one reduces the odds the next gets read, and support channels start with far more credit than marketing ones — which is why borrowing them is tempting and expensive.
This is the part teams underestimate. A good proactive message provokes replies — that is the point of it. Tell ten thousand customers their parcel is late and a meaningful share write back, in a window you chose. So plan it like a campaign send: write the follow-up answers into the help centre first so the AI can answer from them, brief the team on the wording, and stagger a large send. This inbound is unusually automatable, because you know exactly what people will ask. But an unplanned send lands as an unplanned ticket spike and feels like the AI got worse, when the topic mix simply changed — a distinction that deflection rate and resolution rate pull apart in more detail.
A proactive message is a commitment made without a human in the loop, which makes this the strictest rule in the area: it must not promise an outcome that requires an action the automation is not allowed to take. "We have refunded your delivery charge" is only safe if the refund has already happened. If it has not, say what will happen and who will do it.
That is the same seam as maker-checker on the reactive side. In CustomerEagle the AI never executes a refund or an order edit on its own — it prepares the action with the conversation attached and a person approves it. A proactive message implying otherwise creates an obligation your process cannot meet. So state compensation as an offer to be confirmed unless it is already real, and never send off a signal you have not verified in production: a wrong delay notice reads as incompetence, a wrong account notice reads as surveillance.
Reply rate is the number every proactive tool reports and it is close to meaningless: an alarming message gets replies, and so does a confusing one. Measure what happens next instead.
One caution on in-product counters. Impressions, clicks and conversations started tell you whether a nudge is engaging; they cannot tell you a ticket was avoided, because the avoided ticket is the one that never arrived. Pair them with the cohort comparison above, and hold the rest of the reporting to the same standard as everything else you count — written out on how we measure AI resolutions.
Teams that treat proactive support as a retention channel end up with three or four messages that earn their place and a pile of ideas they dropped. That is the correct end state. The failure mode is a dozen rules nobody owns, firing on soft signals, quietly training customers that a message from you is not worth opening.
Proactive customer support means contacting a customer before they contact you, because a signal in their own record predicts a problem — a late shipment, a failed payment, a stalled setup step. It differs from marketing outreach in that the trigger is a specific event affecting that person, and the message contains a fact they do not have plus a remedy.
Prefer signals where the underlying problem is certain: a shipment past your promised delivery date, a declined or expiring payment, a second contact about the same issue within days, or a negative rating on a conversation you already closed. Softer signals such as inactivity predict very little on their own and belong to lifecycle marketing rather than support.
It can, but only for signals where the customer would otherwise have written in. A delay notice sent before the customer notices the delay removes the contact it pre-empts, while a generic check-in creates contacts instead. The only reliable way to know which one you built is to hold back a control group and compare contacts per affected order.
In-browser conditions: how long the visitor has been on the page or has been idle, whether they scroll past a set depth, the pointer leaving through the top of the window on desktop (there is no exit-intent equivalent on a phone), whether the page URL or the referring site matches a pattern, a day-of-week and time-of-day schedule, desktop versus mobile, how many visits or page views they have made, and a cooldown so the same person is not nudged repeatedly. Signals living in your order, billing or product systems still have to be evaluated there, because a widget cannot see them — that half of proactive support stays your own stack's job.
It can draft the message from the account state and answer the replies from your documented knowledge, which is the larger half of the work since proactive messages create inbound volume in a window you chose. What it should not do is promise an outcome requiring an action it is not permitted to execute — refunds and order changes should be prepared for a person to approve.
2026-08-09 · 10 min read
Tickets closed, handle time and raw CSAT survive in reports because they always look fine. Here is the replacement set, how each number is gamed, and the weekly page a support lead can defend.
2026-08-09 · 10 min read
Customers forgive a bot that does not know. They do not forgive one that will not let go. The triggers worth wiring, what has to travel with the conversation, and how to tell a good handoff from a bad one.
2026-08-09 · 9 min read
The biggest driver of your AI resolution rate is not the model — it is your content. A practical guide: one question per article, front-loaded answers, real values instead of screenshots, and how to test with your own tickets.
See how honestly-measured AI resolutions cut your support load — start on the Free plan, no credit card, no sales call to get started.