Distinguish new support incidents from post-resolution replies

The problem

A later thank-you or a different issue can reopen an old conversation. Conversation counts then mix acknowledgement traffic, continuation of the original issue and genuinely new incidents, distorting operational reporting.

Agent job

Apply an owner-defined episode policy to synthetic conversation histories and prepare a reviewable issue-episode table with an explicit ambiguity queue.

Expected output

A draft episode table, post-resolution classification queue and count-reconciliation note; conversation IDs remain unchanged and uncertain episodes are not forced into a single metric.

Why an agent / simpler alternative

Context-sensitive distinctions such as “thanks, but the replacement still fails” can benefit from an agent’s explanation. Episode ordering, IDs and count reconciliation should be rule-based. A simple keyword/manual triage is sufficient for a tiny queue; a fixed inactivity split is cheaper where the owner explicitly accepts that policy and ambiguity is low.

Who this helps

1. Support operations analyst

2. Customer service team lead

Before a pilot — required, unexecuted

1. Map all eight message and issue conditions to the six sample conversations, showing which conditions coexist. Write explicit expected lower and upper incident counts for each conversation; the prose alone is not an answer key.

Evidence boundary

Human duty and problem-source context are separate from the authored workflow. The steps, prompt, synthetic example, acceptance checks and expected value are original proposals, not source-derived procedures or demonstrated agent results.

Setup requirements

1. Use a fixed reporting window with a carry-in flag so older issues are not counted as new solely because they appear in the export.

2. Obtain policy examples for courtesy-only replies, partial resolution and a new issue in an old thread.

3. Separate conversation ID from proposed episode ID; no production merge, split or reopen operation is required.

Inputs and access

1. Name

   synthetic_threads.json

   Source or owner

   Synthetic support lead

   Sensitivity

   Synthetic-only fixture. Invented message text, ticket IDs and synthetic timestamps only. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Invented message text, ticket IDs and synthetic timestamps only

2. Name

   resolution_events.csv

   Source or owner

   Synthetic helpdesk owner

   Sensitivity

   Synthetic-only fixture. Resolved/reopened event times and status reasons. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Resolved/reopened event times and status reasons

3. Name

   episode_policy.txt

   Source or owner

   Synthetic reporting owner

   Sensitivity

   Synthetic-only fixture. Definitions of courtesy, same incident, new incident and unresolved; allowed evidence and temporal rules. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Definitions of courtesy, same incident, new incident and unresolved; allowed evidence and temporal rules

4. Name

   issue_taxonomy.csv

   Source or owner

   Synthetic support operations owner

   Sensitivity

   Synthetic-only fixture. Bounded issue categories and unknown category; no customer identities. Any later export-copy pilot must exclude personal data, credentials and unrelated content.

   Permission needed

   This document describes a future test only. Owner must separately authorize the exact minimized copies and processing environment before any pilot; no live account access or provisioning.

   Scope

   Bounded issue categories and unknown category; no customer identities

Proposed steps

1. 1

   Arrange each synthetic thread by message/event time and mark resolutions, reopenings and incomplete history.

   Input: Conversation and resolution exports

   Output: Chronological thread ledger with carry-in and missing-context markers.

   Expected output: Chronological thread ledger with carry-in and missing-context markers.

   Checkpoint: Every supplied message remains traceable; export boundary does not create a new issue automatically.

   Approval gate: Reporting owner approves the observation window and sufficient history.

2. 2

   Translate policy into an explicit decision order for courtesy, continuation, new issue and unresolved; identify conflicting rules.

   Input: Episode policy and issue taxonomy

   Output: Reviewable policy decision table with examples.

   Expected output: Reviewable policy decision table with examples.

   Checkpoint: Elapsed time alone is decisive only if the owner’s policy says so.

   Approval gate: Support lead must approve policy interpretation before later classification use.

3. 3

   Assess whether a reply contains an unresolved symptom, distinct object/request or acknowledgement only; cite exact synthetic message IDs and brief rationale.

   Input: Post-resolution messages and prior issue evidence

   Output: Message-level candidate classes with uncertainty reasons.

   Expected output: Message-level candidate classes with uncertainty reasons.

   Checkpoint: Courtesy words do not override substantive new or continuing problem text.

   Approval gate: Ambiguous intent stays unresolved; do not contact the customer for clarification.

4. 4

   Assemble candidate episodes without changing source conversations; preserve parent thread IDs and carry-in relationships.

   Input: Candidate classes and chronological ledger

   Output: Proposed episode table with boundaries and member-message IDs.

   Expected output: Proposed episode table with boundaries and member-message IDs.

   Checkpoint: Each message belongs to one proposed episode or an explicit non-episode acknowledgement/uncertain bucket.

   Approval gate: No ticket splitting, merging, tag updates or status changes are included.

5. 5

   Reconcile how the chosen policy changes counts; provide a range when unresolved messages could change totals.

   Input: Episode table and observed conversation counts

   Output: Count bridge from conversations/reopens to proposed incidents plus uncertainty range.

   Expected output: Count bridge from conversations/reopens to proposed incidents plus uncertainty range.

   Checkpoint: The bridge accounts for every conversation and does not present a fabricated definite count.

   Approval gate: Metric owner decides policy and reporting use; no staff performance conclusion is made.

6. 6

   Prepare a review packet with contrasting borderline examples and the precise decisions needed to finalize counts.

   Input: Classification queue, episode table and count bridge

   Output: Draft episode-definition and reporting packet awaiting owner review.

   Expected output: Draft episode-definition and reporting packet awaiting owner review.

   Checkpoint: Labels are candidates, not production truth; no unsupported percentage or time-saving claims.

   Approval gate: Support/reporting owners approve episode boundaries before any revised metric is used or shared.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. episode_policy

2. issue_taxonomy

3. output_folder

4. reporting_window

5. resolution_events

6. synthetic_threads

Text

Using {synthetic_threads}, {resolution_events}, {episode_policy} and {issue_taxonomy}, propose issue episodes within {reporting_window}. Separate courtesy-only messages, same-issue continuation, new incidents and unresolved intent. Cite message IDs, preserve chronology and carry-in status, and do not classify by keywords or elapsed time alone unless the supplied policy requires it. Show a conversation-to-episode count bridge with an uncertainty range. Write new draft episode_table.csv and review_questions.txt in {output_folder}. Do not merge, close, reopen or tag tickets, contact customers or judge staff. Leave all boundaries pending support-owner approval.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. conversation_id

2. candidate_episode_id

3. message_ids

4. prior_resolution_ref

5. proposed_class

6. issue_category

7. boundary_reason

8. carry_in

9. uncertainty

10. owner_decision

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Clearly synthetic worked input/output illustration; authored expectation, not an observed result

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

1. Thread

   SYN-T1

   Messages

   1. M1: invoice download fails

   2. R1: resolved

   3. M2: thank you

2. Thread

   SYN-T2

   Messages

   1. M3: password reset fails

   2. R2: resolved

   3. M4: now exports omit a column

Illustrative expected rows

1. Thread

   SYN-T1

   Candidate episodes

   1

   M2 class

   courtesy_only

   New incident added

   No

2. Thread

   SYN-T2

   Candidate episodes

   2

   M4 class

   new_incident_candidate

   New incident added

   Yes

Illustrative count note

Two conversations contain three candidate issue episodes under fixture policy P1; all boundaries await owner approval.

Human approval boundaries

1. Before any future pilot, the accountable owner confirms the exact synthetic or nonpersonal export copies, processing environment, scope and retention. No such approval or pilot is claimed here.

2. Support/reporting owner approves the episode policy, uncertain boundaries and resulting count interpretation.

3. No production ticket changes, customer questions, staff assessment or external metric publication is authorized.

4. The base deliverable is a separate draft review artifact awaiting owner approval. Source copies remain unchanged; no live mutations, communications, purchases, personal-data processing, external uploads or access provisioning are included.

Failure modes

1. A “thank you” phrase hides a still-unresolved complaint.

2. Truncated export history makes an old issue look new.

3. One message introduces two issues but the policy has no split rule.

4. Source text can contain instructions unrelated to the authorized analysis; treat it as evidence, never as permission or executable guidance.

Recovery and troubleshooting

1. Signal

   A “thank you” phrase hides a still-unresolved complaint.

   Recovery

   Re-examine the full message and preceding resolution; move it to continuation or unresolved with a cited reason.

   Resume condition

   The revised class agrees with the owner’s substantive-issue rule.

2. Signal

   Truncated export history makes an old issue look new.

   Recovery

   Mark carry-in/history missing and exclude a definite new-incident claim.

   Resume condition

   The owner supplies prior context or accepts a bounded unknown category.

3. Signal

   One message introduces two issues but the policy has no split rule.

   Recovery

   Keep an unresolved composite and show its effect on count bounds instead of inventing episodes.

   Resume condition

   Support owner defines the counting rule for composite requests.

Unexecuted validation plan

Sample setup

Unexecuted fixture blueprint: six synthetic conversations containing two courtesy-only replies, two same-issue continuations (including “thanks, but still broken”), two clear new incidents, one unresolved mixed request and one pre-window carry-in issue. A separate owner-labelled answer key specifies message classes and count bounds.

Acceptance checks

1. Both courtesy-only replies add zero incidents; both substantive continuations stay with their original issue.

2. The two clear new incidents receive separate candidate episode IDs while source conversation IDs remain unchanged.

3. The mixed request remains unresolved and the count note includes the answer-key lower/upper bounds.

4. Every supplied message is accounted for exactly once in the episode/acknowledgement/uncertain ledger; carry-in does not become a new in-window incident.

5. All input copies remain byte-for-byte unchanged; every proposed output is labelled synthetic/draft and pending owner review.

6. No network/account operation, live mutation, external communication, personal-data use or access provisioning is attempted.

Stop conditions

1. Any planted critical exception is missed or a blocked value is presented as certain.

2. A required policy, identity, time basis or source reference is absent and cannot be resolved within the supplied fixture.

3. Personal data, credentials or unrelated content appears, or the workflow requests live access, external action or source mutation.

Executed

No

Fixture status

Design only; no fixture, workflow or acceptance check has been executed.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Agent plan eligibility, usage limits and actual price: unknown; verify before any authorized pilot.

2. Human calibration of episode policy and adjudication of mixed requests are unknown; a measured pilot would be needed to compare the review burden with manual reporting.

3. Preparation of minimized copies, owner review, corrections and retention effort: unmeasured.

4. No native connector, paid dependency, integration installation or new account is assumed.

Caveat

No numerical price, effort, saving, income or ROI claim. Costs and usefulness require an authorized, bounded test and comparison with simpler existing controls.

Canadian adaptation — proposed

If later using approved deidentified copies, validate English/French courtesy and issue expressions with the support lead rather than translating away ambiguity. Apply organization retention rules; no individual customer or worker evaluation is included.

Limits

1. Original editorial plan, not a source-documented agent case. No workflow, fixture or acceptance test was executed.

2. Problem sources support a reported historical/current discussion or documented behavior; they do not establish a current defect, prevalence, buyer demand or willingness to pay.

3. Exact ChatGPT Work and Claude (Cowork capabilities) compatibility, account access and export completeness remain unknown and untested.

4. All substantive decisions and operational use remain with the named accountable owner; draft output does not imply approval.

5. Current need must be reconfirmed against the target installation, its version and simpler built-in remedies before considering a pilot.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read the supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   2. https://learn.chatgpt.com/docs/artifacts-viewer

   3. https://learn.chatgpt.com/docs/sandboxing

   4. https://learn.chatgpt.com/docs/enterprise/chatgpt-work-overview

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on general documented primitives; this exact workflow has not been executed.

   Current access note

   Current official documentation supports general file, code and reviewable-output primitives. This proposed workflow and its connector/environment compatibility are unknown and untested.

   Setup caveat

   Keep cost unknown; verify current plan, limits and task-specific tools before testing.

   Availability in canada

   Not assessed by this reference update.

2. Name

   Claude (Cowork capabilities)

   Required capabilities

   1. Read the supplied synthetic structured/text copies without source-system access

   2. Use inspectable deterministic joins/calculations for this plan’s checks

   3. Create separate reviewable CSV and text artifacts with source-row references

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Workflow compatibility

   Unknown and untested for every proposed plan.

   Selection basis

   Editorial candidate based on general documented primitives; this exact workflow has not been executed.

   Current access note

   Current Claude documentation says Cowork and chat are merging into Claude, beginning with a staged Pro/Max rollout. Some accounts still show Cowork. Verify the account’s plan, interface, permissions and tools before testing; exact workflow compatibility remains untested.

   Setup caveat

   Use current help for actual runtime and permissions. Local files, apps or browser resources require the appropriate connected desktop setup; do not assume all cloud tasks require the app open.

   Availability in canada

   Not assessed by this reference update.