Session Abandonment Detection Prompt

This playbook is for platform engineers and chat product teams who need to reclaim resources, trigger re-engagement flows, or close tickets without prematurely terminating active conversations. The core job is to analyze a conversation's last-turn signals, pending work, and elapsed time to produce an abandonment likelihood score with a recommended action. The ideal user is an engineering lead or backend developer integrating this prompt into a session lifecycle manager, a timeout handler, or a CRM ticket-closure pipeline. Required context includes the full conversation history (or a structured summary), the timestamp of the last user message, the current elapsed silence duration, and any known pending actions or unresolved questions extracted from prior turns.

Use this prompt when the cost of a false positive—closing a session a user intends to resume—is lower than the cost of holding resources indefinitely, or when you need a structured signal to trigger a re-engagement message before taking destructive action. It is appropriate for asynchronous support tickets, long-running copilot sessions, and multi-turn workflows where users may step away for hours or days. Do not use this prompt for real-time synchronous chat where sub-second pauses are normal turn-taking behavior, for voice assistants where silence detection is handled at the audio pipeline level, or for sessions where a user has explicitly set an expectation of a long wait (e.g., 'I'll check back next week'). In those cases, a simple fixed timeout or an explicit user-set reminder is more reliable and less prone to misclassification.

The prompt is designed to be wired into a state machine that transitions sessions from ACTIVE to IDLE, ABANDONED, or CLOSED. Before deploying, you must calibrate the elapsed-time thresholds against your product's actual usage patterns. A 30-minute silence in a customer support chat is a strong abandonment signal; the same duration in an async code review thread is noise. Pair this prompt with a Session Re-engagement Prompt After Abandonment to handle the user-return path, and always log the abandonment score and recommended action alongside the session state transition for auditability. The next section provides the copy-ready prompt template you can adapt and test against your own session data.

This prompt template analyzes the final turns of a conversation to determine whether a user has likely abandoned the session or is simply in a natural long pause. It evaluates last-turn signals, pending work, elapsed time, and conversation closure cues to produce a structured abandonment likelihood score with a recommended action. Wire the placeholders from your session store, conversation history buffer, and system clock before sending this to the model.

textCopy
You are a session state classifier for a production chat system. Your task is to analyze the final turns of a conversation and determine whether the user has likely abandoned the session or is in a natural pause.

## INPUT

[CONVERSATION_HISTORY]

## CONTEXT

- Current time: [CURRENT_TIMESTAMP]
- Time since last user message: [ELAPSED_SECONDS] seconds
- Session duration: [SESSION_DURATION_SECONDS] seconds
- Pending actions requiring user input: [PENDING_ACTIONS]
- Unresolved questions awaiting user response: [UNRESOLVED_QUESTIONS]
- User's last explicit intent: [LAST_INTENT]
- Conversation phase at last turn: [CONVERSATION_PHASE]
- System timeout threshold: [TIMEOUT_THRESHOLD_SECONDS] seconds

## OUTPUT_SCHEMA

Return a JSON object with exactly these fields:

{
  "abandonment_likelihood": "high" | "medium" | "low",
  "confidence": 0.0-1.0,
  "signals": [
    {
      "signal": "string describing the signal detected",
      "weight": "strong_abandonment" | "weak_abandonment" | "neutral" | "weak_engagement" | "strong_engagement",
      "evidence": "specific quote or observation from the conversation"
    }
  ],
  "recommended_action": "terminate_and_archive" | "send_reengagement_prompt" | "extend_timeout" | "no_action",
  "reengagement_message": "string or null if no reengagement is recommended",
  "rationale": "brief explanation of the decision"
}

## CONSTRAINTS

- Do not classify as abandoned if the user explicitly stated they will return or need time.
- A simple 'thanks' or 'ok' at the end of a completed task is a strong closure signal, not abandonment.
- If [ELAPSED_SECONDS] is less than 30% of [TIMEOUT_THRESHOLD_SECONDS], bias toward low likelihood unless there are strong closure signals.
- Pending actions that require user input increase abandonment likelihood if the user has been silent beyond the typical response window.
- Multi-step workflows with incomplete steps are not abandonment if the user is between steps within a reasonable time.
- If confidence is below 0.7, prefer the less disruptive action.
- Never fabricate evidence. If a signal has no direct evidence, omit it.

## EXAMPLES

[FEW_SHOT_EXAMPLES]

## RISK_LEVEL

[RISK_LEVEL]

Adaptation notes: Replace [CONVERSATION_HISTORY] with the last N turns formatted as speaker-labeled messages. [PENDING_ACTIONS] and [UNRESOLVED_QUESTIONS] should come from your dialogue state tracker, not raw message text. [FEW_SHOT_EXAMPLES] should include at least one example each of true abandonment, natural pause, and explicit closure. Set [RISK_LEVEL] to "high" if this prompt controls session termination in a regulated or revenue-critical workflow—this should trigger additional human review gates before destructive actions execute.

What to avoid: Do not inject the full conversation history if it exceeds your context budget. Prune to the last 5-10 turns plus any turns containing pending actions or unresolved questions. Do not use this prompt for real-time interruption detection—it is designed for post-silence analysis, not mid-utterance classification. If your system uses streaming input, buffer the silence period before invoking this classifier.

The Session Abandonment Detection Prompt is not a standalone classifier; it is a decision component inside a session lifecycle controller. Your application owns the timer, the session state machine, and the final action (warn, pause, terminate, or escalate). The prompt's job is to analyze the last-turn signals, pending work, and elapsed time you provide, then return a structured abandonment likelihood score with a recommended action. The controller reads that output, validates it against the actual session state, and decides whether to act. This separation prevents the model from unilaterally terminating sessions and keeps your product logic in control of user-facing consequences.

Wiring the prompt into a controller: The controller should trigger the prompt only when a configurable inactivity threshold is crossed (e.g., 5 minutes of silence for a support chat, 30 minutes for an async research assistant). Before calling the model, assemble the input payload: the last N user and assistant turns (typically 3-5 turns), a list of unresolved questions or pending actions from your dialogue state tracker, the elapsed seconds since the last user message, and any session metadata such as channel type or user segment. Pass these into the prompt's [CONVERSATION_HISTORY], [PENDING_ITEMS], [ELAPSED_SECONDS], and [SESSION_METADATA] placeholders. After receiving the model output, validate the JSON schema: confirm the abandonment_score is a float between 0.0 and 1.0, the confidence field is present, and the recommended_action matches your allowed enum (warn, pause, terminate, continue_waiting, escalate). Reject and retry any response that fails schema validation.

Retry logic and failure modes: If the model returns malformed JSON, a score outside bounds, or a hallucinated action not in your enum, retry once with the same payload and a stronger format constraint appended to the prompt. If the second attempt also fails, fall back to a conservative default: continue_waiting with a logged warning. Do not retry more than twice on a single abandonment check; the cost of repeated model calls on an idle session outweighs the benefit. Log every abandonment check result—score, action, confidence, and whether the controller followed or overrode the recommendation—so you can measure false-positive and false-negative rates against ground truth (e.g., did the user actually return within 24 hours?). This log becomes your eval dataset for tuning thresholds and prompt versions.

Decision boundary between model and controller: The model recommends; the controller decides. For example, if the prompt returns terminate with a 0.92 score but your session state tracker shows an active multi-step workflow with a tool call in flight, the controller should override to pause and notify an on-call channel. Similarly, if the score is below your production threshold (start with 0.7 and calibrate from eval data), the controller should take no action and reset the inactivity timer. Never expose the raw abandonment score to users; the controller translates the decision into an appropriate user-facing message or silent state transition. For high-stakes sessions—financial transactions, healthcare handoffs, legal intake—require human review before any termination action, regardless of the model's confidence.

Model choice and latency budget: This prompt works well with fast, cost-effective models (e.g., GPT-4o-mini, Claude Haiku, or equivalent) because the task is classification with structured output, not deep reasoning. Latency should stay under 1-2 seconds; if your model provider exceeds this, consider a local classifier or heuristic fallback for the timeout path. Cache the system prompt prefix if your provider supports it, since the instructions are static across all abandonment checks. For air-gapped or local deployments, a fine-tuned small model on your abandonment eval dataset will outperform a general-purpose model on this narrow task.

Next steps after implementation: Once the harness is live, monitor the abandonment score distribution, controller override rate, and user re-engagement rate after each action type. Use these metrics to tune your inactivity threshold, score cutoff, and retry policy. If the controller overrides the model recommendation more than 20% of the time, your prompt or threshold likely needs adjustment. If users consistently re-engage within minutes of a warn action, your inactivity threshold is too aggressive. Treat the prompt and the controller as a single tuned system, not two independent components.