Session Re-engagement Prompt After Abandonment

This prompt is designed for a single, high-stakes moment in the session lifecycle: the instant a returning user sends their first message after a period of detected abandonment. Its job is to rebuild conversational continuity by acknowledging the time gap, accurately summarizing the prior context, and presenting a clear, low-friction next step. The ideal user is a platform team building persistent chat products—such as copilots, support assistants, or task-oriented agents—where users frequently leave mid-workflow and return hours or days later. The prompt takes a structured session summary, the abandonment duration, and any pending actions as input, and produces a user-facing re-engagement message that feels helpful rather than robotic.

You should wire this prompt into your session-resume pipeline only after your abandonment detection system has fired and before the user's new message is processed by the main assistant logic. It is not a real-time inactivity nudge (use a timeout prompt for that), a first-time user onboarding flow, or a marketing re-engagement email. Using it in the wrong context will produce messages that feel jarring and out of place—imagine a user pausing for 30 seconds to think and being greeted with 'Welcome back! It's been a while.' The prompt also assumes that a reliable session serialization and deserialization process has already captured the prior state; if your system cannot provide an accurate summary of where the user left off, this prompt will confidently fabricate a plausible but incorrect context, which is worse than saying nothing.

Before deploying this prompt, validate that your abandonment detection system has an appropriate minimum threshold—typically 30 minutes to several hours, depending on your product's usage patterns. Also ensure that your session summary includes the specific pending actions, unresolved questions, and the last user intent, not just a generic conversation digest. The prompt's effectiveness depends entirely on the quality of this structured input. If the summary is vague, the re-engagement message will be vague. If the summary hallucinates a task the user never started, the re-engagement will erode trust. Start by testing this prompt against a golden dataset of real abandoned-and-resumed sessions, and measure both context accuracy and tone appropriateness before routing live traffic through it.

The following template is designed to be wired directly into your session store and abandonment detection system. It accepts structured inputs about the prior conversation state, the abandonment signal, and the elapsed time, then produces a re-engagement message that acknowledges the gap, summarizes where things left off, and offers a clear path forward. Replace each square-bracket placeholder with live data from your application before sending the prompt to the model.

textCopy
You are a re-engagement assistant for a [PRODUCT_NAME] session. Your job is to generate a single, contextually appropriate message when a user returns after a detected abandonment.

## SESSION CONTEXT
- Last active timestamp: [LAST_ACTIVE_TIMESTAMP]
- Current timestamp: [CURRENT_TIMESTAMP]
- Elapsed time: [ELAPSED_DURATION]
- Abandonment confidence: [ABANDONMENT_CONFIDENCE] (0.0 to 1.0)
- Abandonment reason: [ABANDONMENT_REASON]

## PRIOR CONVERSATION STATE
- Session summary: [SESSION_SUMMARY]
- Last user message: [LAST_USER_MESSAGE]
- Last assistant message: [LAST_ASSISTANT_MESSAGE]
- Pending actions: [PENDING_ACTIONS]
- Unresolved questions: [UNRESOLVED_QUESTIONS]
- Active workflow step: [ACTIVE_WORKFLOW_STEP]

## CONSTRAINTS
- Acknowledge the gap naturally without over-apologizing.
- Summarize where things left off in 2-3 sentences maximum.
- Offer exactly one clear next action the user can take.
- Match the tone to [TONE_PROFILE]: professional, casual, or urgent.
- Do not fabricate details not present in the prior conversation state.
- If no meaningful prior context exists, offer a fresh start without referencing abandonment.
- If pending actions include time-sensitive items, flag them explicitly.

## OUTPUT FORMAT
Return a JSON object with this exact schema:
{
  "message": "The re-engagement message text.",
  "tone": "professional | casual | urgent",
  "references_prior_context": true | false,
  "next_action_type": "continue_workflow | answer_question | review_pending | fresh_start | acknowledge_only",
  "flags_time_sensitivity": true | false
}

Adaptation guidance: The [TONE_PROFILE] placeholder should map to your product's voice guidelines. For support products, prefer "professional"; for consumer apps, "casual" may be more appropriate. The [ABANDONMENT_CONFIDENCE] field should come from your detection system's scoring output. When confidence is below 0.5, consider suppressing the re-engagement message entirely or defaulting to a generic welcome-back message that does not reference prior context. The [PENDING_ACTIONS] and [UNRESOLVED_QUESTIONS] fields should be populated from your dialogue state tracker, not from raw conversation text. If your system does not track these explicitly, omit them rather than attempting to extract them at inference time, which introduces hallucination risk.

Validation and testing: Before deploying this prompt, validate the output JSON against the schema on every response. Reject any output where references_prior_context is true but the message field contains no specific reference to the prior conversation. Test with edge cases: sessions abandoned mid-purchase, sessions with zero prior turns, sessions where the last user message was a complaint, and sessions where the elapsed time exceeds your product's typical session boundary. For high-stakes workflows such as financial or healthcare sessions, route the generated message through a human review queue before sending it to the user.

The re-engagement prompt is not a standalone message generator; it is a state-aware component that must be wired into your session lifecycle manager. When a user returns after a detected abandonment window, your application should retrieve the serialized session state, populate the prompt's placeholders, and route the output through a validation layer before surfacing it to the user. The prompt expects three critical inputs: a structured session summary, a list of pending actions, and the elapsed time since last activity. If any of these inputs are missing or stale, the generated message will either hallucinate context or produce a generic greeting that fails to re-establish continuity.

Wire the prompt into a pipeline that executes in this order: (1) Abandonment detection triggers on user return, using a separate classifier or a simple time-threshold rule with a minimum idle period (e.g., 30 minutes for support chat, 24 hours for async workflows). (2) State deserialization loads the stored session snapshot, including the compressed summary, unresolved questions, and any tool outputs that were pending. (3) Input assembly maps the deserialized fields into the prompt's [SESSION_SUMMARY], [PENDING_ACTIONS], and [ELAPSED_TIME] placeholders. (4) Model invocation runs the prompt with a low-temperature setting (0.2–0.4) to keep the re-engagement message consistent and predictable. (5) Output validation checks the generated message against a schema that requires: a non-empty acknowledgment of the gap, a summary that references at least one specific prior turn, and a forward-looking action or question. Messages that fail validation should trigger a retry with the same inputs or fall back to a templated safe message.

For production resilience, implement a retry policy with a maximum of two attempts. If the first output fails validation, resubmit with an explicit [CONSTRAINT] appended: 'The previous output was rejected because it lacked specific context from the prior session. Reference at least one concrete detail from the session summary.' Log every re-engagement attempt with the session ID, elapsed time, generated message, validation result, and whether the user engaged with the message within the next two turns. This telemetry lets you tune the abandonment threshold and detect drift in message quality. Avoid surfacing raw model output directly; always run it through a content safety check for tone appropriateness—re-engagement messages that sound accusatory ('You disappeared for 3 days') or overly casual ('Hey stranger!') erode trust and should be rewritten before delivery.