Evidence-Grounded Sales-to-Customer-Success Handoff System

Create a deal-specific sales-to-customer-success handoff system from the supplied records. The result must preserve customer intent and commercial context without turning informal sales notes into approved commitments.

## ChatGPT operating boundary
ChatGPT may analyze only the material supplied in this conversation, organize evidence, identify conflicts and gaps, calculate metrics from supplied data, and draft templates, decision gates, agendas, and communications for human review. It cannot inspect a CRM, contract repository, email, call recording, product roadmap, ticketing system, or customer account unless the relevant content is pasted or otherwise made available in the active ChatGPT session. It cannot confirm product capability, interpret a contract authoritatively, approve scope, update systems, assign employees, contact the customer, accept the handoff, or execute onboarding.

Describe all outputs as proposed, draft, blocked, or unverified unless the supplied evidence demonstrates a completed action. Never claim that a record was updated, a stakeholder approved an item, a promise was validated, or CS accepted ownership without dated evidence of that event.

## Supplied deal material
- Deal summary: [Deal summary]
- Customer goals: [Customer goals]
- Stakeholders: [Stakeholders]
- Sales promises: [Sales promises]
- Use cases: [Use cases]
- Purchased products: [Purchased products]
- Implementation risks: [Implementation risks]
- Commercial terms: [Commercial terms]
- Timeline: [Timeline]
- Handoff tools: [Handoff tools]

Treat each entry as an input, not automatically as fact. Preserve source labels such as signed order form, statement of work, master agreement, approved email, CRM field, call note, implementation assessment, security review, or unattributed recollection. When practical, retain dates, record owners, document versions, and short supporting excerpts.

## Input gate
The minimum reliable inputs are:
1. A deal or account summary identifying what was sold.
2. Purchased products or services and the governing scope evidence.
3. Customer goals and intended use cases, with their sources.
4. Every known sales promise, or an explicit statement that none were found after human review.
5. Commercial and timing terms relevant to onboarding, preferably as excerpts from governing documents rather than paraphrases alone.
6. Known customer and internal stakeholders, even if some roles remain vacant.
7. Known implementation dependencies, constraints, and risks.

Useful but non-blocking context includes historical objections, support expectations, adoption data, integration details, security reviews, procurement history, renewal context, prior kickoff material, and the fields or workflow available in the named handoff tools.

If purchased scope, governing commercial evidence, or known promises are absent or internally contradictory, ask concise clarification questions before issuing an acceptance recommendation or drafting customer-facing language. If answers are unavailable, continue only with a clearly marked partial package, preserve each unknown, and set the handoff state to Blocked or Conditional. For other missing inputs, use Unknown rather than inventing content. Do not resolve a conflict by selecting the most convenient source.

## Evidence and decision rules
Classify every material statement as one of:
- Documented fact: directly supported by identified supplied evidence.
- Reported expectation: attributed to a person or note but not established as an approved commitment.
- Interpretation: a reasoned reading that requires owner confirmation.
- Assumption: a bounded working premise used only to make provisional progress.
- Unknown: required information not supplied.
- Conflict: two or more supplied sources disagree.

Apply this evidence precedence only as a review aid, not as legal interpretation: executed agreement or order form; executed statement of work; formally approved amendment; dated approved customer communication; approved internal product or implementation record; CRM field; meeting or call note; recollection. Flag conflicts between sources regardless of precedence.

Do not infer that a product can support an integration, migration, data volume, security requirement, customization, service level, deadline, outcome, or roadmap feature. A sales statement is not a confirmed commitment unless supported by governing or explicitly approved evidence. Do not provide legal, financial, security, privacy, or regulatory advice.

## Workflow
1. Normalize the supplied deal material without silently changing its meaning. Link each material claim to a source, source date, owner, and excerpt when available.
2. Reconcile products, scope, goals, use cases, promises, commercial terms, dates, and stakeholder roles. Record omissions and conflicts instead of smoothing them over.
3. Test onboarding readiness across scope clarity, outcome definition, stakeholder coverage, technical feasibility, data and integration dependencies, security or procurement dependencies, resource availability, timeline realism, communication expectations, and measurable first value.
4. Evaluate each promise by evidence strength, customer impact, delivery feasibility, contractual ambiguity, owner, required reviewer, and decision deadline. Route relevant items to sales leadership, CS, implementation, product, support, finance, legal, security, privacy, or executive leadership.
5. Build the handoff packet and field-level completion rubric. Distinguish complete, incomplete, risky, and blocked fields.
6. Define the internal handoff meeting, decision rights, system-of-record updates, customer communication controls, and first 30-60-90-day follow-up cadence.
7. Apply the CS acceptance gate. Report the expected condition, supplied evidence, actual observed state from that evidence, variance, owner, and disposition for every gate. Do not treat a proposed criterion as evidence that it has been met.
8. Verify internal consistency across the scope, promise register, risk register, timeline, ownership, acceptance decision, and communication draft.

## Authority, privacy, and stop conditions
- Redact credentials, payment data, government identifiers, health data, and unnecessary personal information before analysis. Minimize customer contact details and confidential contract content to what the handoff requires.
- Draft customer-facing language only when requested by the supplied context, label it Draft — Human Approval Required, and include only supported commitments.
- Require authorized human approval before changing CRM or project records, committing resources, accepting exceptions, changing scope or dates, waiving requirements, interpreting contractual language, or communicating externally.
- Stop and mark the handoff Blocked when a material promise lacks an accountable reviewer, governing documents conflict on scope or timing, a required security or legal review is unresolved, feasibility is unknown for a critical use case, no customer decision-maker or operational owner is identifiable, or the proposed kickoff would communicate an unapproved commitment.
- Preserve the prior record and document the reason, owner, and required resolution for any proposed correction. Do not overwrite conflicting evidence.

## Required deliverable
Produce the following in markdown.

### 1. Readiness snapshot
State the proposed handoff status as Ready, Conditional, or Blocked. Summarize the sold scope, customer outcomes, target kickoff, evidence coverage, highest risks, decisions required before transfer, and the limits of ChatGPT's review.

### 2. Evidence and discrepancy ledger
Create a table with: ID; claim or field; classification; supplied source; source date or version; supporting excerpt or observation; confidence; conflicting evidence; missing evidence; required human check.

Include products, contracted scope, exclusions, goals, use cases, success measures, promises, commercial terms, dates, stakeholder roles, dependencies, and implementation constraints.

### 3. Promise and expectation register
Create a table with: ID; promise or expectation; customer interpretation risk; supporting evidence; governing-document status; feasibility status; delivery owner; required reviewers; decision deadline; permitted customer wording; disposition.

Use dispositions Confirmed, Rejected, Revised, Pending Review, or Unsupported. Only use Confirmed when supplied approval evidence supports it.

### 4. Risk, dependency, and gap register
Create a table with: ID; risk, dependency, or gap; evidence; trigger; likelihood; impact; severity; affected milestone or outcome; accountable owner; mitigation; escalation path; due date; residual risk; status.

Assess at least scope ambiguity, unsupported use cases, missing stakeholders, timeline compression, technical or data blockers, security or procurement dependencies, unusual commercial terms, undefined success criteria, resource constraints, expectation mismatch, and early renewal or retention exposure. Mark an area Not Evidenced rather than manufacturing a risk.

### 5. Copy-ready internal handoff packet
Provide fields for account and opportunity identifiers; sales, CS, implementation, and executive owners; customer stakeholder map; business goals; measurable success criteria; use cases; purchased products; contracted scope; exclusions; approved commitments; unconfirmed expectations; known objections; integrations and data needs; security or procurement dependencies; commercial milestones; onboarding timeline; risks and blockers; first-value definition; kickoff objectives; internal follow-ups; and approved customer communication notes.

For each field, include value, source, record owner, freshness date, completion state, and next action. Use Unknown where evidence is absent.

### 6. Field quality rubric
Define deal-specific standards for Complete, Incomplete, Risky, and Blocked. Include examples for goals, success criteria, scope, promises, stakeholders, timeline, dependencies, and ownership. A field is not Complete merely because text exists; it must be specific, attributable, current, and sufficient for the receiving team to act.

### 7. Internal handoff meeting and decision record
Provide a timed agenda covering deal context, outcomes, stakeholder map, scope and exclusions, promise review, feasibility and dependencies, commercial or timing constraints, risk treatment, kickoff plan, owner assignment, customer messaging, and the acceptance vote.

Add a decision log with: decision; options considered; evidence; decision owner; approvers; decision; rationale; conditions; due date; and proof of approval. Leave unmade decisions Pending.

### 8. CS acceptance gate
Create a table with: gate; expected condition; supplied evidence; actual observed state; variance; accountable owner; disposition; blocking reason; required evidence to close.

Include gates for minimum account context, customer goals, measurable first value, purchased and excluded scope, promise disposition, customer and internal ownership, implementation feasibility, required specialist reviews, timeline realism, risk ownership, kickoff messaging, and system-of-record readiness.

Conclude with one proposed decision:
- Ready: all mandatory gates have supporting evidence and no unresolved blocker remains.
- Conditional: ownership may transfer only with explicit conditions, owners, deadlines, and authorized acceptance of residual risk.
- Blocked: one or more stop conditions remain.

Name who has authority to make the actual acceptance decision. Do not present ChatGPT's recommendation as acceptance.

### 9. Operating process and controls
Define the trigger for handoff, stage owners, reviewer responsibilities, approval points, system of record for each artifact, version and change control, meeting timing, escalation service levels, customer communication approval, rejected-handoff recovery path, and 30-60-90-day review cadence. Map recommendations to capabilities actually described in the supplied handoff tools; otherwise label the configuration Proposed and Tool Capability Unverified.

### 10. Measurement specification
For handoff completeness, missing-information rate, unsupported-promise rate, escalation resolution time, close-to-kickoff time, kickoff delay rate, time to first value, expectation mismatch rate, CS rejection rate, and early churn or downgrade risk, provide: operational definition; numerator and denominator where applicable; source record; owner; reporting cadence; segmentation; target-setting approach; and data limitation. Do not invent baselines, targets, or measured results.

### 11. Controlled communication draft
If evidence permits, draft an internal summary and a separate customer kickoff-confirmation note. Label both as drafts. The customer note must distinguish agreed scope, proposed onboarding actions, open questions, and items awaiting approval. Omit the customer note if material scope or promise conflicts make safe drafting impossible, and explain the blocker.

### 12. Verification report
Report each check as Pass, Fail, or Not Verifiable, with expected condition, actual observation from supplied material, evidence reference, and remediation:
- Every material commitment traces to supplied approval evidence or remains unconfirmed.
- Products, scope, exclusions, goals, and use cases reconcile across the package.
- Dates and commercial milestones do not conflict without a recorded resolution.
- Every critical risk, dependency, and open decision has an accountable owner and deadline.
- Acceptance status matches the gate results and stop conditions.
- Customer-facing wording contains no unsupported capability, date, outcome, price, or obligation.
- Proposed tool fields and workflow do not assume unverified system capabilities.
- Missing inputs, conflicts, assumptions, pending reviews, and privacy redactions remain visible.

Finish with the three highest-priority human decisions, their authorized owners, required evidence, and the next three controlled actions. Clearly separate actions merely proposed from actions evidenced as completed.