Your support queue is a map of problems customers have already encountered. By the time a ticket appears, the customer has stopped the task, switched context, and spent effort explaining what your product could have observed directly.

If you are deciding where AI belongs in customer support, start there. The useful opportunity is not a more conversational ticket form. It is a system that recognizes a specific problem while it is happening, offers the smallest safe intervention, and verifies whether the customer recovered.

Start with a customer state, not a chatbot

Proactive support should not mean watching every click and asking an AI model to guess what the customer is thinking. That produces interruptions, not help. The better unit of design is a customer state: observable evidence of a problem, the context required to interpret it, an appropriate response, and a product event that confirms recovery.

Define each candidate intervention with the following fields before you discuss prompts, models, or vendors:

• Observable signal: What happened in the product? Prefer a failed operation, known error result, incomplete workflow, or account constraint over a vague behavioral pattern.
• Conservative diagnosis: What is the smallest claim the evidence supports? A failed import proves that the import failed. It does not prove that the customer is confused or likely to churn.
• Eligible audience: Which account, role, plan, workflow, and product state make the intervention relevant? Also define who must never see it.
• Intervention: What is the least intrusive action that could help? This might be an explanation, a deep link to the correct setting, a prepared change awaiting confirmation, or a human handoff.
• Verified recovery: Which system event proves that the customer completed the blocked task? A click on the message is not recovery.
• Failure and harm: What happens if the diagnosis is wrong, the message reaches the wrong role, or the proposed action fails?

Choose a narrow first use case

A strong first use case has an observable failure, a known remedy, a clearly authorized customer, and a reversible intervention. A weak first use case begins with inactivity, a broad prediction such as dissatisfaction, or an action that changes billing, permissions, or customer data.

Rank candidate moments by asking:

• Can the system distinguish the problem from normal customer behavior?
• Does the product already know the likely cause?
• Can the customer recover without a long diagnostic conversation?
• Can you identify the authorized recipient with confidence?
• Is the proposed action reversible, or can it be previewed before confirmation?
• Can you observe success inside the product?

Use high, medium, and low ratings if you need a scorecard. The point is not mathematical precision. It is to expose cases where a large ticket category has poor diagnostic evidence or a risky remedy. Ticket volume alone should not determine the starting point.

Consider a hypothetical collaboration product in which an invitation fails because the workspace has reached a seat limit. The backend result identifies the constraint, the account model identifies the workspace administrator, and a subsequent successful invitation can verify recovery. A useful intervention can explain the factual constraint and open the relevant workspace setting. It should not automatically purchase seats or change the subscription.

That example is narrow by design. Narrowness makes the diagnosis testable, the message relevant, and the downside of being wrong easier to control.

Build the system as signal, policy, answer, and action

The language model is only one component. A production system also needs product instrumentation, identity and entitlement data, decision rules, approved knowledge, authorization controls, delivery logic, and outcome measurement. Letting a model own all of those decisions inside one prompt makes failures difficult to detect and harder to contain.

1. Capture semantic signals. Record the attempted operation, result, error category, relevant object, customer role, entitlement state, and last successful step. Raw page views usually describe location, not the problem.
2. Assemble only the necessary context. Join the signal to the correct user and account while preserving role and tenant boundaries. The support agent should not receive unrelated account data merely because it is available.
3. Apply an eligibility policy. A deterministic policy should decide whether an intervention is allowed. It can enforce role requirements, suppress duplicate messages, respect dismissals, exclude cases already handled by a person, and block unsafe actions.
4. Ground the answer. Retrieve the approved explanation, current product instructions, and account-specific facts required for this problem. The model can adapt the wording and reason over the supplied context, but it should not invent product behavior or silently fill missing account data.
5. Constrain available actions. Give the agent a small set of typed tools rather than unrestricted access. Each tool should perform its own identity, permission, input, and state checks. Authorization belongs in the execution layer, not in a model instruction.
6. Deliver help in the right place. Use an in-product intervention when the customer is still in the affected workflow. Use an asynchronous channel only when the customer has left, the problem remains relevant, and the channel is appropriate for the account relationship.
7. Log the decision and outcome. Preserve the trigger, policy result, context fields used, content or prompt version, proposed action, confirmed execution result, recovery event, dismissal, and escalation. Without this record, you cannot separate a poor trigger from a poor answer or a failed tool call.

Write a trigger contract before writing the prompt

A trigger contract turns a promising idea into a testable product behavior. For the seat-limit example, it could contain:

• Problem: A workspace invitation returned the known seat-limit result.
• Trigger: The backend emitted that result for the current workspace and attempted invitation.
• Eligible recipient: An authenticated workspace administrator who can manage the relevant setting.
• Suppressions: The invitation has since succeeded, the customer dismissed this intervention, or a support agent is actively handling the same problem.
• Response: State the constraint, show the affected workspace, and link to the permitted management action.
• Action boundary: Do not modify the subscription, charge the account, or alter permissions without explicit confirmation through an authorized flow.
• Success event: A later invitation succeeds for the workspace.
• Failure route: Preserve the error context and offer a human support path.

This contract keeps the product team, support team, data team, and AI system aligned around the same event. It also makes the intervention portable: the wording or model can change without quietly changing who is eligible or what the agent is allowed to do.

Connecting behavioral product data to an AI support agent can materially expand what the agent can diagnose. In one vendor-documented implementation, Teachable connected Pendo product data to its AI agent and reported resolving 67% of customer issues. Treat that result as evidence that the pattern can work, not as a planning benchmark. Your issue mix, eligibility rules, denominator, and definition of resolution may be different.

Match AI autonomy to confidence and consequence

Detection confidence and action safety are separate questions. You can be confident about the problem while still requiring confirmation for the remedy. You can also have a harmless suggestion that is not worth showing because the trigger is weak.

Use an autonomy ladder that makes both dimensions visible:

Stage	AI behavior	Appropriate condition	Required control
Observe	Detect and log the state without contacting the customer	The trigger is still being validated	Human review of labeled cases and false positives
Explain	Describe the observed problem and offer a relevant next step	The diagnosis is reliable, but no product change is needed	Easy dismissal, support access, and message suppression after rejection
Prepare	Construct an action and preview its effect	The remedy is known, but the customer must review the consequence	Explicit confirmation through an authorized interface
Execute	Perform a low-risk, reversible action	Identity, permission, inputs, and expected outcome are verifiable	Execution checks, audit record, failure handling, and a reversal path

Move upward only when evidence supports both the trigger and the action. Better conversational quality does not justify more authority. An eloquent model can still act on the wrong account, expose restricted information, or confidently describe a change that never succeeded.

Design the intervention to preserve customer agency

A proactive message arrives without being requested, so it carries a higher burden of relevance. The customer should immediately understand what happened, why the message appeared, and what will happen if they accept the proposed action.

• State evidence, not psychology. Use language such as “The import stopped because the email column is not mapped,” rather than “You seem to be struggling with the import.” The first statement is testable. The second invents an internal state.
• Explain why the intervention appeared. Refer to the relevant failed task or account state. Do not create a sense that the product is monitoring unrelated behavior.
• Keep dismissal real. Closing the message should not cause it to reappear on every page. Record the dismissal and define what new evidence, if any, would make another intervention appropriate.
• Respect roles and account boundaries. A member should not see administrative settings, billing context, another user’s activity, or cross-tenant information merely because those details could help the model answer.
• Require confirmation for consequential changes. Billing changes, permission changes, deletion, exports, and communication to third parties should be previewed and confirmed through an authorized flow. A generated sentence asking “Are you sure?” is not an authorization control.
• Verify before claiming success. The agent should describe an action as complete only after the underlying system returns a successful result and the expected state is observable.
• Preserve access to a person. Escalation should carry the relevant trigger, diagnosis, attempted remedy, and execution result so the customer does not have to reconstruct the incident. Exclude unrelated sensitive data from that handoff.

Privacy, authorization, and suppression rules should be enforced outside the model as system policy. Prompts can shape behavior, but they are not a reliable boundary for data access or permissions.

Measure prevented pain, not message engagement

Clicks, opens, and chat replies tell you that the intervention attracted attention. They do not tell you whether the customer recovered. Even a lower ticket count is ambiguous: the customer may have solved the problem, abandoned the task, or decided that contacting support was not worth the effort.

Define an eligible episode as a distinct instance of the customer state covered by the trigger contract. Then use outcome and safety measures with explicit denominators:

Measure	Definition	Decision it supports
Trigger precision	Reviewed triggers in which the defined problem was actually present, divided by reviewed triggers	Whether the signal and eligibility policy are accurate enough to contact customers
Verified recovery rate	Intervened episodes followed by the predefined success event, divided by eligible intervened episodes	Whether customers complete the blocked task after receiving help
Incremental recovery	The difference in verified recovery between the intervention group and a comparable holdout	Whether the intervention caused improvement rather than receiving credit for self-resolution
Downstream contact rate	Eligible episodes followed by a related support request, divided by eligible episodes	How the intervention changes demand for human support
Repeat failure rate	Recovered episodes that encounter the same defined failure again within a predeclared window, divided by recovered episodes	Whether the intervention creates durable recovery or only a temporary escape
Harm rate	Delivered interventions involving a wrong recipient, wrong diagnosis, unauthorized action, data exposure, duplicate interruption, or complaint, divided by delivered interventions	Whether expansion is safe and whether the system should be paused

Choose the recovery event and measurement window before the test begins. If you change either after seeing the results, the system can appear successful simply because the definition moved. Segment the results by trigger type, account role, product surface, intervention version, and action stage; an overall average can hide a harmful experience for a smaller audience.

Resolution rate is meaningful only when the denominator is clear. “Resolved customer issues” could mean all eligible problem episodes, conversations accepted by the agent, or cases that reached a support workflow. Those are different measures and should not be compared as if they were interchangeable.

Roll out in stages that expose different failures

1. Run in observation mode. Log triggers without messaging customers. Review examples to find missing context, incorrect recipients, duplicate episodes, and cases in which the customer had already recovered.
2. Test the explanation separately. Use approved, constrained guidance for a limited use case and audience. Confirm that the message accurately describes the observed state before adding tool access.
3. Introduce a holdout. Where it is safe and appropriate, keep a comparable group without the proactive intervention. This separates genuine incremental recovery from outcomes that would have happened anyway.
4. Add actions gradually. Start with navigation or prepared changes. Require confirmation until the identity, authorization, execution result, and reversal path are dependable.
5. Review errors by type. Separate trigger errors, context errors, answer errors, permission failures, tool failures, and measurement failures. Each category has a different owner and remedy.
6. Expand by contract, not by generic prompt. Every new use case should define its own evidence, eligibility, suppressions, recovery event, action boundary, and stop conditions.

Set categorical stop conditions before launch. An unauthorized account change, cross-account data exposure, or repeated delivery to an ineligible role should pause the affected intervention immediately. Do not wait for an aggregate success metric to outweigh a boundary failure.

Key takeaways

• Begin with an observable customer problem and a verifiable recovery event, not a general ambition to make support proactive.
• Keep signal detection, eligibility policy, answer generation, authorization, execution, and measurement as distinct system responsibilities.
• Let the AI explain and adapt approved context, while deterministic controls enforce identity, permissions, suppressions, and action boundaries.
• Increase autonomy only when both diagnostic confidence and action safety justify it.
• Use verified recovery and a comparable holdout to measure incremental value; treat clicks and ticket reduction as supporting signals.
• Track wrong recipients, wrong diagnoses, unauthorized actions, data exposure, duplicate interruptions, dismissals, and complaints as product outcomes, not edge cases.

Pick one recurring failure state and write its trigger contract before selecting a model or redesigning the support experience. If you cannot name the exact evidence, authorized recipient, safe intervention, and system event that proves recovery, the use case is not ready for proactive automation.

References

• Pendo — Before the ticket: how Teachable gets to customers, before they ask for help

---