Show which resolved cases could actually receive a satisfaction survey

The problem

A score based only on returned surveys can conceal cases that never received a survey because a template was unapproved, paused or outside an allowed messaging window. Comparing channels without those denominators can misrepresent survey coverage.

Agent job

Reconstruct case-level eligibility and survey transport stages from synthetic status exports and template history, keeping missing ratings missing.

Expected output

A draft coverage table of resolved, policy-eligible, sendable, attempted, explicitly delivered and responded cases by channel/time; reason-coded coverage gaps and cautious interpretation notes await the owner.

Why an agent / simpler alternative

An agent may explain how template-history transitions align with missing survey attempts and translate inconsistent status labels. Cohort membership, distinct-case counts and denominators should be deterministic. A native survey funnel or a short aggregate query is better when the platform exposes every stage consistently; no agent can infer the missing customers’ satisfaction.

Who this helps

1. Customer experience analyst

2. Support operations manager

Before a pilot — required, unexecuted

1. Name the intended send time, last-contact time, messaging-window rule and applicable template/version fields. Define the exact joins needed to determine eligibility for cases where no send was attempted.

2. Include a response with no delivery evidence in the expected results. Calculate response rate for delivered cases using only responders who belong to that delivered group; show unmatched responses and missing logs separately.

3. Label 12 October 2026 as the source guide's last update. Its original publication date is unknown.

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. Define one resolved-case cohort and a separate response-observation cut-off; avoid mixing surveys sent for older cases.

2. Distinguish policy eligibility from technical sendability and provider acceptance from explicit delivery.

3. Use synthetic case IDs and aggregate output only; prohibit recontact or template edits.

Inputs and access

1. Name

   resolved_case_metadata.csv

   Source or owner

   Synthetic CX owner

   Sensitivity

   Synthetic-only fixture. Synthetic case ID, channel, resolved time and policy attributes; no contacts or messages. 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

   Synthetic case ID, channel, resolved time and policy attributes; no contacts or messages

2. Name

   survey_events.csv

   Source or owner

   Synthetic channel owner

   Sensitivity

   Synthetic-only fixture. Attempt ID, case ID, sent/delivered/responded status and timestamps; synthetic ratings 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

   Attempt ID, case ID, sent/delivered/responded status and timestamps; synthetic ratings only

3. Name

   template_status_history.csv

   Source or owner

   Synthetic messaging administrator

   Sensitivity

   Synthetic-only fixture. Template ID/version, approval/paused states and effective intervals. 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

   Template ID/version, approval/paused states and effective intervals

4. Name

   survey_eligibility_policy.txt

   Source or owner

   Synthetic CX policy owner

   Sensitivity

   Synthetic-only fixture. Cohort window, survey exclusions, messaging-window rules and response cut-off. 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

   Cohort window, survey exclusions, messaging-window rules and response cut-off

Proposed steps

1. 1

   Build the cohort and assign explicit included/excluded reasons without using survey response as an inclusion condition.

   Input: Resolved metadata and eligibility policy

   Output: Resolved-to-policy-eligible cohort ledger.

   Expected output: Resolved-to-policy-eligible cohort ledger.

   Checkpoint: Every resolved case has one cohort disposition; missing attributes produce unknown eligibility.

   Approval gate: CX owner approves cohort and exclusion policy before interpretation.

2. 2

   Determine which supplied template/version and messaging-window rule applied at each intended send time; preserve status-transition uncertainty.

   Input: Eligible cases, resolution times and template history

   Output: Sendability timeline with template/window blocker reasons.

   Expected output: Sendability timeline with template/window blocker reasons.

   Checkpoint: Current approval status is not applied retroactively to older cases.

   Approval gate: Channel owner confirms effective times and rule meanings; no template submission or approval request is sent.

3. 3

   Join attempts to cases and retain retries; summarize unique-case attempted/sent states separately from event counts.

   Input: Survey attempts and cohort IDs

   Output: Case-level survey attempt ledger with retry multiplicity.

   Expected output: Case-level survey attempt ledger with retry multiplicity.

   Checkpoint: Multiple attempts cannot inflate the number of surveyed cases.

   Approval gate: Ambiguous case IDs remain unmatched; no recipient lookup or new access is included.

4. 4

   Derive explicitly delivered and responded stages; flag responded-without-delivery-evidence rather than inventing a missing event.

   Input: Attempt ledger and provider response/delivery events

   Output: Evidence-based delivery/response funnel with unknown states.

   Expected output: Evidence-based delivery/response funnel with unknown states.

   Checkpoint: Accepted does not become delivered; response evidence does not fabricate a receipt timestamp.

   Approval gate: Owner decides how unknown delivery evidence is represented in reporting.

5. 5

   Compute named ratios with visible numerators/denominators by channel and period; separate eligibility, sendability, delivery coverage and response rate.

   Input: Cohort, sendability and funnel stages

   Output: Coverage summary and template-change gap table.

   Expected output: Coverage summary and template-change gap table.

   Checkpoint: Each rate names its denominator and cut-off; zero denominators produce not applicable, not zero satisfaction.

   Approval gate: Do not rank teams or infer ratings for nonresponders from coverage differences.

6. 6

   Prepare an interpretation memo identifying where comparisons are not like-for-like and which missing records would resolve uncertainty.

   Input: Coverage summary and reason-coded gaps

   Output: Draft survey-coverage review packet awaiting CX owner approval.

   Expected output: Draft survey-coverage review packet awaiting CX owner approval.

   Checkpoint: No missing rating is imputed and no claim about the unobserved population’s sentiment is made.

   Approval gate: CX owner approves any use or sharing of the metrics; surveys, recontacts and template changes require separate authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Label

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

Placeholders

1. cohort_window

2. eligibility_policy

3. output_folder

4. resolved_cases

5. response_cut_off

6. survey_events

7. template_history

Text

From {resolved_cases}, {survey_events}, {template_history} and {eligibility_policy}, audit survey coverage for {cohort_window} through {response_cut_off}. Keep resolved, policy-eligible, technically sendable, attempted, explicitly delivered and responded counts distinct. Deduplicate retries by case for coverage but retain attempt counts. Apply template states at event time. Show each ratio’s numerator and denominator and mark unknown delivery or eligibility. Do not impute ratings, rank staff or infer sentiment from nonresponse. Write new draft coverage_tables.csv and an interpretation memo in {output_folder}; await CX-owner approval and send no surveys or messages.

Execution authorized

No

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. channel

2. cohort_window

3. resolved_cases

4. policy_eligible_cases

5. unknown_eligibility_cases

6. sendable_cases

7. attempted_cases

8. explicitly_delivered_cases

9. responded_cases

10. unknown_delivery_cases

11. template_blocked_cases

12. ratio_name

13. numerator

14. denominator

15. review_status

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

Resolved cases

10

Policy excluded

2

Policy eligible

8

Blocked by unapproved template

3

Sendable and attempted

5

Explicitly delivered

4

Delivery unknown

1

Responded with delivery evidence

2

Illustrative expected output

Eligible delivery coverage

4/8 = 50%

Response rate among explicitly delivered

2/4 = 50%

Response rate among policy eligible

2/8 = 25%

Interpretation

Three eligible cases were template-blocked and one attempted case lacks delivery evidence. Ratings for all nonresponders remain missing.

Review status

pending_CX_owner_review

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. CX owner approves cohort, exclusions and denominator labels; channel owner verifies template history and messaging-window meanings.

3. No survey send, recontact, template edit, staff ranking or external publication is included.

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. Latest template approval is applied to cases during an earlier pause.

2. Retried surveys inflate the sent denominator.

3. A response exists but the delivery log is absent.

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

   Latest template approval is applied to cases during an earlier pause.

   Recovery

   Rejoin by effective status interval and mark unresolved interval gaps rather than backfilling.

   Resume condition

   Channel owner supplies the relevant historical effective times.

2. Signal

   Retried surveys inflate the sent denominator.

   Recovery

   Maintain both attempt-level and distinct-case ledgers and rebuild the named ratios.

   Resume condition

   All aggregate counts reconcile to unique included case IDs.

3. Signal

   A response exists but the delivery log is absent.

   Recovery

   Keep the response as observed and delivery evidence unknown; disclose that funnel stages are not fully observed.

   Resume condition

   Owner approves an explicit missing-evidence convention; no receipt is invented.

Unexecuted validation plan

Sample setup

Unexecuted fixture blueprint: the ten-case illustrated cohort plus duplicate attempt events for one case, an approved-to-paused template transition, a zero-eligible subgroup and one response received after the response cut-off. No real survey or messaging account is used.

Acceptance checks

1. Primary cohort yields the stated counts and 4/8, 2/4 and 2/8 ratios with explicit denominator labels.

2. Duplicate attempts do not increase distinct attempted cases; post-cut-off response is excluded from that snapshot and separately noted.

3. Template state is evaluated at event time, and the zero-eligible subgroup reports not applicable.

4. No missing ratings, delivery receipts or satisfaction estimates are fabricated; every stage cites case/event evidence.

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. Historical template and delivery exports may be incomplete or costly to retrieve; administrator effort, platform usage and analyst review remain unknown.

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

Use organization-approved survey language and data-retention rules for any later local pilot. Preserve English/French template-version distinctions where supplied; no marketing-consent or Canadian privacy-compliance conclusion is made.

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.