Explain how reopened deals change sales-cycle metrics

Setup requirements

1. The owner chooses whether reopening starts a new episode; present alternative approved policies separately.

2. No individual employee ranking or commission decision; this is data-definition review.

3. Before any pilot, confirm an actual unresolved need and approve minimized inputs, processing environment, retention and recipients. This design does not authorize execution.

Inputs and access

1. Name

   stage_history.csv

   Source or owner

   CRM owner

   Scope

   Immutable deal IDs, ordered stage-entry events, lost/won/reopened states and timestamps.

   Sensitivity

   Synthetic fixture only; actual commercial, personal or location data requires minimized approved handling.

   Permission needed

   Specific owner approval before any real-data pilot. No live account access, credential handling or upload is authorized.

2. Name

   metric_policy.json

   Source or owner

   Revenue owner

   Scope

   Approved episode-boundary, elapsed-time and outcome-denominator rules.

   Sensitivity

   Synthetic fixture only; actual commercial, personal or location data requires minimized approved handling.

   Permission needed

   Specific owner approval before any real-data pilot. No live account access, credential handling or upload is authorized.

3. Name

   report_snapshot.json

   Source or owner

   Reporting owner

   Scope

   Dashboard totals, filters, date range and calculation definitions.

   Sensitivity

   Synthetic fixture only; actual commercial, personal or location data requires minimized approved handling.

   Permission needed

   Specific owner approval before any real-data pilot. No live account access, credential handling or upload is authorized.

Human approval boundaries

1. Before a pilot, the accountable owner approves exact synthetic/minimized copies, processing environment, retention and allowed recipients.

2. Owner validates identity mappings, authority, status definitions and all unresolved evidence.

3. Any source mutation, account access, upload, external communication, commercial commitment, payment or changed permission requires separate appropriate authorization.

The problem

Reopened opportunities can mix separate sales attempts into one apparent cycle and overwrite the meaning of historical losses.

Suggested task

Reconstruct owner-defined selling episodes from deal history and compare episode-based measures with record-level reports.

What you could produce

An episode ledger and denominator bridge showing how policy choices affect cycle and outcome totals.

Why an agent / simpler alternative

Mixed narrative and structured evidence can benefit from assisted extraction and explanation. Identity joins, interval calculations and totals require deterministic checks. A supported native report, query or spreadsheet is preferable when it answers the owner’s question reliably.

When this work comes up

Role

Revenue operations analyst

Trigger

Leadership disputes cycle length after lost deals are reopened.

Human approval

Owner approves scope, rules and evidence interpretation. Any operational action requires separate appropriate authorization.

Finished output

An episode ledger and denominator bridge showing how policy choices affect cycle and outcome totals.

Proposed evaluation scope — no pilot authorized

Scope

At most 40 synthetic deals and 250 complete stage-change events over one year.

Limit origin

Editorial evaluation bound, not a verified platform limit.

Overflow action

Stop and ask for approved partitioning; no silent truncation.

Pilot authorized

No

Evidence boundary

Firsthand reports establish stated friction or concerns only. O*NET provides duty context. Official documents establish limited native features or general primitives. This workflow, safeguards, fixtures and outputs are original proposals, not source-documented executions.

Proposed steps

1. 1

   Freeze event coverage, report filters and the exact policy alternatives authorized for comparison.

   Output: episode_scope.json

   Expected output: episode_scope.json

   Checkpoint: Do not invent a historical close date from the current record.

   Approval gate: Owner approves exact inputs and rule scope before any pilot.

2. 2

   Normalize stage events and distinguish duplicate delivery from a real repeated transition.

   Output: stage_event_ledger.csv

   Expected output: stage_event_ledger.csv

   Checkpoint: Original event IDs and timestamps remain unchanged.

   Approval gate: Owner resolves ambiguous identity, authority or language before affected rows advance.

3. 3

   Partition histories under each approved episode rule and retain links to the original deal.

   Output: episode_register.csv

   Expected output: episode_register.csv

   Checkpoint: A new episode never creates or merges a CRM deal.

   Approval gate: Owner resolves ambiguous identity, authority or language before affected rows advance.

4. 4

   Calculate elapsed durations and terminal outcomes using the supplied interval and denominator conventions.

   Output: episode_metrics.csv

   Expected output: episode_metrics.csv

   Checkpoint: Open episodes remain censored/unfinished rather than treated as losses.

   Approval gate: Owner validates the calculation or decision rule before relying on its result.

5. 5

   Bridge record-level report totals to episode-level measures and isolate missing history or conflicting definitions.

   Output: sales_cycle_bridge.csv

   Expected output: sales_cycle_bridge.csv

   Checkpoint: Metrics across different denominators are never directly combined.

   Approval gate: Owner reviews unresolved findings; no operational action is authorized.

6. 6

   Deliver the policy comparison with evidence gaps and an owner decision field.

   Output: episode_review.json

   Expected output: episode_review.json

   Checkpoint: No outreach, stage change or performance action is performed.

   Approval gate: Owner accepts the separate artifact; all live actions require separate authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Execution authorized

No

Text

Using only {approved_synthetic_inputs} and {owner_rules}, Reconstruct owner-defined selling episodes from deal history and compare episode-based measures with record-level reports. Follow the six-step design. Preserve exact identities, evidence spans and uncertainty. Use inspectable calculations. Write only separate review artifacts described by the output schema. Stop for missing authority, ambiguous evidence or out-of-scope data. Do not change source records, contact anyone, access live accounts, post transactions or execute recovery actions.

Expected output schema — proposed

Primary key

1. policy_id

2. deal_id

3. episode_id

Columns

1. start_event_id

2. end_event_id

3. start_time

4. end_time

5. outcome

6. elapsed_days

7. history_complete

8. report_cohort

9. metric_inclusion

10. source_spans

11. owner_decision

Record status

draft_review_only

Common provenance columns

1. input_snapshot_id

2. rule_version

3. source_document_id

4. source_row_or_span

5. reviewer_decision

Unknown value policy

Unknown values remain null, not zero. Keep raw identities and evidence. Unresolved rows do not silently enter approved totals.

Synthetic output illustration — not an executed result

Label

Synthetic authored example, not observed output

Synthetic

Yes

Executed

No

Input

Episodes

1. 1. 2027-01-01

   2. 2027-01-11

   3. lost

2. 1. 2027-02-01

   2. 2027-02-06

   3. won

Expected

Episode days

1. 10

2. 5

Active days

15

Record elapsed days

36

Terminal episode counts

Lost

1

Won

1

Limits

1. Original proposed and untested design; no source documents this complete agent workflow.

2. A reported problem is not proof of prevalence, willingness to pay, harm magnitude or current demand.

3. Historical product reports require current-installation checks; a current capability document only establishes general primitives.

4. Native reports or a deterministic script may be simpler. Exports, identity mappings, context size, privacy controls and actual tool compatibility remain untested.

5. Numerical fixtures are synthetic and have not been executed. Owner review is necessary; no time saving, cost saving or revenue outcome is asserted.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Assess this plan’s input, operation and output requirements before selecting an account.

   Capability source urls

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

   Selection basis

   Editorial candidate only. Shared source facts are general primitives; this plan remains unexecuted.

   Workflow compatibility

   BotCurrent has not tested this workflow.

Failure modes

1. The export contains only latest stage dates.

2. A lost-to-open correction is mistaken for a genuine new attempt.

3. A dashboard filters by final close date but the workpaper by episode start.

Recovery and troubleshooting

1. Signal

   The export contains only latest stage dates.

   Recovery

   Flag missing history and stop the affected episode calculation.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or explicit rule; otherwise retain the affected result as unresolved.

2. Signal

   A lost-to-open correction is mistaken for a genuine new attempt.

   Recovery

   Require an explicit owner rule or labelled correction event.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or explicit rule; otherwise retain the affected result as unresolved.

3. Signal

   A dashboard filters by final close date but the workpaper by episode start.

   Recovery

   Show the cohort mismatch before comparing any total.

   Resume condition

   The accountable owner supplies the missing authoritative evidence or explicit rule; otherwise retain the affected result as unresolved.

Unexecuted validation plan

Sample setup

Episodes

1. 1. 2027-01-01

   2. 2027-01-11

   3. lost

2. 1. 2027-02-01

   2. 2027-02-06

   3. won

Acceptance checks

1. With half-open elapsed-day intervals, Jan1-Jan11 lost episode is10days and Feb1-Feb6 won episode is5days.

2. Record-level Jan1-Feb6 elapsed is36days, while observed active episodes total15days under the supplied pause rule.

3. The two-episode outcome denominator has one loss and one win; the one-record denominator has one terminal win.

4. A still-open episode is neither won nor lost and must be shown separately.

5. Every conclusion traces to a source row or an explicitly labelled owner rule; repeated evaluation of identical frozen inputs must preserve identities and totals.

6. All original copies remain unchanged. Output is a draft review artifact, not an operational decision.

Stop conditions

1. Required identity, source coverage, calculation policy or owner authority is missing.

2. Unexpected real sensitive data is supplied without approved handling.

3. Requested work would require live access, upload, external communication, accounting posting, payment, permission change or irreversible action.

Executed

No

Fixture status

Designed specification only. No acceptance fixture or business workflow executed.

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan access, model usage, tool runtime and storage costs unknown.

2. Export preparation, evidence cleanup, review and correction effort unmeasured.

3. No native integration, paid service, new account or software installation assumed.

4. Case-specific effort is unknown: source extraction, identity repair, owner-rule preparation, fixture design and review may dominate model cost.

Caveat

No measured time saving, current demand, ROI or price claim. Compare the simpler remedy first.

Canadian adaptation — proposed

Verify local privacy and organizational record-handling requirements before any real-data pilot; preserve original currency, business calendars and time zones. No Canadian deployment or compliance claim.