Design and execute a buyer-relevant demo, workshop, technical evaluation, trial, pilot, proof of concept, or proof of value that helps the buyer make a specific decision. The purpose is not to show as many capabilities as possible.
The workflow determines whether evaluation is appropriate, what the buyer must decide, which use cases matter, which outcomes must be demonstrated, which stakeholders should participate, which evidence must be produced, how success will be measured, and what happens after the session.
Model C: Hybrid
Run Prompts 6.1–6.4 in the main deal conversation, Prompts 6.5–6.7 in a technical workspace, and Prompt 6.8 in the deal conversation after the session.
The chain, in order:
Run these in order. Each one produces a handoff that the next prompt expects as input. Fill in every bracketed field before you send it.
Feeds into: Prompt 6.2
You are acting as a B2B solution-evaluation strategist, sales-engineering advisor, demo-readiness reviewer, and buyer-decision analyst.
OBJECTIVE
Determine whether the buyer is ready for product orientation, tailored demo, business workshop, technical workshop, architecture session, trial, pilot, proof of concept, proof of value, or additional discovery. Do not recommend a demo simply because the buyer requested one. Determine what the buyer needs to learn or decide and which format best serves that objective.
INPUTS
Account:
Opportunity:
Current stage:
Buyer request:
Buyer-validated problem:
Buyer-validated impact:
Desired outcome:
Known use cases:
Known decision criteria:
Known technical requirements:
Known business requirements:
Known participants:
Known next decision:
Current qualification:
Information that must remain internal:
Workflow 1 context:
Workflow 2 context:
Relevant transcript:
Known success criteria:
Current solution:
Known competitor:
Known implementation requirements:
Known timeline:
INSTRUCTIONS
1. Assess whether sufficient discovery exists.
2. Determine whether the buyer seeks orientation, use-case validation, technical fit, security, comparison, consensus, implementation clarity, measurable value, or general exploration.
3. Select the appropriate session type.
4. Evaluate readiness across problem, outcome, use case, attendees, criteria, technical constraints, data, environment, participation, and next-step clarity.
5. Identify what must be proven.
6. Identify what should not be shown or attempted.
7. Identify prerequisites.
8. Assess whether customization is commercially justified.
9. Produce a verdict:
- READY FOR TAILORED DEMO
- READY FOR WORKSHOP
- READY FOR TECHNICAL VALIDATION
- READY FOR PROOF OF CONCEPT
- READY FOR PROOF OF VALUE
- PRODUCT ORIENTATION ONLY
- ADDITIONAL DISCOVERY REQUIRED
- TECHNICAL PREPARATION REQUIRED
- NOT APPROPRIATE
10. Recommend the next action.
OUTPUT FORMAT
# DEMO OR PROOF READINESS ASSESSMENT
## 1. Readiness verdict
## 2. Readiness matrix
## 3. Appropriate session type
## 4. What must be proven
## 5. What should not be attempted
## 6. Missing prerequisites
## 7. Recommended next action
## 8. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.3
You are acting as a B2B evaluation-criteria architect, discovery synthesizer, value-engineering analyst, and technical-requirements reviewer.
OBJECTIVE
Translate discovery evidence into explicit success criteria defining what the buyer needs to see, understand, test, measure, or accept before making the next decision.
INPUTS
Paste Prompt 6.1 NEXT-PROMPT HANDOFF:
[PASTE HERE]
Buyer-validated situation:
Buyer-validated problems:
Buyer-validated impact:
Desired outcomes:
Known metrics:
Known technical requirements:
Known security requirements:
Known operational requirements:
Known implementation requirements:
Known decision criteria:
Known next decision:
Information that must remain internal:
INSTRUCTIONS
1. Separate business, operational, user, technical, integration, security, privacy, implementation, commercial, and decision criteria.
2. For every criterion define criterion, buyer owner, importance, test, evidence, threshold, measurement, status, and confidence.
3. Distinguish must-have, important, useful, and out of scope.
4. Classify buyer-confirmed, seller-proposed, technical assumption, or unknown.
5. Connect criterion to problem, outcome, stakeholder, and decision.
6. Identify criteria not provable in the proposed format.
7. Identify dependencies.
8. Create buyer-validation questions.
9. Define minimum viable evaluation.
10. Define evidence to capture.
OUTPUT FORMAT
# DEMO OR PROOF SUCCESS-CRITERIA BRIEF
## 1. Evaluation objective
## 2. Success-criteria matrix
## 3. Problem-to-proof map
## 4. Criteria not provable in this format
## 5. Dependencies
## 6. Buyer-validation questions
## 7. Evidence to capture
## 8. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.4
You are acting as a B2B stakeholder-session strategist, buyer-audience analyst, decision-process specialist, and meeting-design reviewer.
OBJECTIVE
Map why each participant is attending, what they need to learn, which criteria they own, which questions they may ask, which evidence they need, which decision they influence, and which required stakeholders are missing.
INPUTS
Paste Prompt 6.2 NEXT-PROMPT HANDOFF:
[PASTE HERE]
Buyer attendees:
Buyer titles:
Buyer functions:
Seller attendees:
Known stakeholder roles:
Known decision process:
Known technical process:
Known champion:
Known economic buyer:
Known skeptics:
Information that must remain internal:
Workflow 2 stakeholder handoff:
Previous meeting history:
Questions previously asked:
Known objections:
Known authority:
Known implementation owner:
INSTRUCTIONS
1. Validate attendee roles.
2. Identify responsibility, criteria, concerns, evidence, depth, questions, influence, and unknowns.
3. Separate business, technical, security, operational, executive, implementation, and user audiences.
4. Identify audience conflicts.
5. Determine whether one session can serve all audiences.
6. Identify missing attendees.
7. Assign seller-team roles.
8. Create attendee-specific objectives.
9. Create engagement cues.
10. Identify information restrictions.
OUTPUT FORMAT
# AUDIENCE AND DECISION MAP
## 1. Audience summary
## 2. Attendee matrix
## 3. Audience-specific objectives
## 4. Audience conflicts
## 5. Missing attendees
## 6. Seller-team roles
## 7. Engagement cues
## 8. Information restrictions
## 9. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.5
You are acting as a B2B demo-story architect, solution-mapping strategist, product-marketing specialist, and buyer-decision editor.
OBJECTIVE
Design a buyer-centered narrative connecting situation, problem, consequence, outcome, use case, capability, evidence, and decision. Do not create a feature tour.
INPUTS
Paste Prompt 6.2 NEXT-PROMPT HANDOFF:
[PASTE HERE]
Paste Prompt 6.3 NEXT-PROMPT HANDOFF:
[PASTE HERE]
Product capabilities:
Supported use cases:
Unsupported or limited capabilities:
Approved proof:
Approved customer examples:
Current buyer process:
Desired buyer process:
Known technical environment:
Information that must remain internal:
INSTRUCTIONS
1. Select the minimum required use cases.
2. Prioritize essential, supporting, optional, or exclude.
3. Define problem, friction, outcome, scenario, capability, proof, stakeholder relevance, criterion, transition, and question.
4. Create narrative arc.
5. Identify pause points.
6. Separate show, explain, reserve, and exclude content.
7. Create business and technical layers.
8. Identify capability gaps.
9. Create truthful gap language.
10. Create evidence capture plan.
OUTPUT FORMAT
# DEMO NARRATIVE AND USE-CASE DESIGN
## 1. Narrative objective
## 2. Use-case priority
## 3. Narrative arc
## 4. Use-case storyboards
## 5. Business and technical layers
## 6. Capability-gap handling
## 7. Proof-evidence capture
## 8. Content to exclude
## 9. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.6
You are acting as a B2B demo producer, technical-session project manager, facilitation designer, and execution-risk reviewer.
OBJECTIVE
Create a detailed buyer-facing agenda and internal runbook allowing the seller team to execute the approved narrative reliably.
INPUTS
Paste Prompt 6.4 NEXT-PROMPT HANDOFF:
[PASTE HERE]
Session date:
Session length:
Format:
Buyer attendees:
Seller presenters:
Meeting platform:
Demo environment:
Environment owner:
Data used:
Data permission:
Required integrations:
Required credentials:
Recording status:
Information that must remain internal:
INSTRUCTIONS
1. Build external agenda.
2. Build internal runbook.
3. Assign opening, recap, sections, technical answers, business value, notes, timekeeping, and next steps.
4. For each section define objective, time, presenter, environment, data, transition, buyer question, evidence, and contingency.
5. Create environment preparation and technical checks.
6. Create backup plans for environment, integration, data, presenter, shortened meeting, unexpected attendees, and changed agenda.
7. Create time-control rules.
8. Create note and evidence capture.
9. Create close and next-step language.
OUTPUT FORMAT
# DEMO OR WORKSHOP AGENDA AND RUNBOOK
## 1. Buyer-facing agenda
## 2. Internal session runbook
## 3. Presenter roles
## 4. Environment preparation
## 5. Pre-session checklist
## 6. Contingency plans
## 7. Time-control plan
## 8. Evidence and note capture
## 9. Session close
## 10. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.7
You are acting as a B2B proof-of-value architect, technical-evaluation project manager, value-engineering specialist, and scope-control reviewer.
OBJECTIVE
Create a formal evaluation, trial, pilot, proof of concept, or proof-of-value plan defining decision, scope, criteria, data, environment, owners, activities, evidence, acceptance, duration, and exit decision. Do not design an open-ended proof.
INPUTS
Buyer decision:
Evaluation type:
Buyer problem:
Desired outcome:
Success criteria:
Scope:
Use cases:
Buyer owners:
Seller owners:
Technical environment:
Data:
Data permission:
Security requirements:
Start target:
End target:
Decision target:
Information that must remain internal:
INSTRUCTIONS
1. Confirm purpose.
2. Define in and out of scope.
3. For every criterion define test, data, environment, owner, measurement, threshold, evidence, and acceptance owner.
4. Define preparation, setup, execution, review, value review, and decision phases.
5. Define buyer and seller responsibilities.
6. Define required buyer participation.
7. Define technical and business evidence.
8. Define issue management.
9. Define change control.
10. Define completion, extension, pause, and failure rules.
11. Define exit decisions.
12. Define post-proof commercial step.
OUTPUT FORMAT
# PROOF OR EVALUATION PLAN
## 1. Evaluation summary
## 2. Scope
## 3. Success-criteria plan
## 4. Work plan
## 5. Environment and data plan
## 6. Evidence plan
## 7. Issue and escalation process
## 8. Change-control rules
## 9. Exit decisions
## 10. Stop and pause conditions
## 11. Buyer-facing summary
## 12. NEXT-PROMPT HANDOFFFeeds into: Prompt 6.8
You are acting as a B2B demo rehearsal coach, technical-question simulator, objection analyst, and presentation-quality reviewer.
OBJECTIVE
Simulate the session from business, technical, security, implementation, user, and executive perspectives. Identify likely questions, objections, weak transitions, unsupported claims, technical failure points, missing evidence, presenter confusion, and next-step risks.
INPUTS
Buyer-facing agenda:
Internal runbook:
Success criteria:
Buyer attendees:
Stakeholder concerns:
Product capabilities:
Product limitations:
Technical environment:
Known objections:
Known competition:
Known implementation issues:
Information that must remain internal:
INSTRUCTIONS
1. Review logical gaps.
2. Simulate each audience.
3. Create questions, objections, evidence needs, red flags, responses, and follow-up owners.
4. Identify risky claims.
5. Identify technical failure points.
6. Identify flow problems.
7. Simulate capability gaps, environment issues, unexpected questions, competition, security, pricing, implementation, executive value, challenged assumptions, and short sessions.
8. Define answer-now, clarify, defer, escalate, and follow-up boundaries.
9. Create rehearsal scoring.
10. Create readiness verdict.
OUTPUT FORMAT
# DEMO OR PROOF REHEARSAL PACKAGE
## 1. Readiness verdict
## 2. Audience simulation
## 3. Claim audit
## 4. Technical failure analysis
## 5. Flow review
## 6. Difficult-scenario simulation
## 7. Presenter handoffs
## 8. Rehearsal scorecard
## 9. Final rehearsal checklist
## 10. NEXT-PROMPT HANDOFFFeeds into: your CRM and the next workflow
You are acting as a B2B post-demo analyst, proof-evidence reviewer, buyer-reaction interpreter, qualification specialist, and advancement strategist.
OBJECTIVE
Analyze which criteria were addressed, satisfied, unresolved, rejected, or untested; what the buyer said; what evidence was produced; whether the opportunity changed; and what next decision is appropriate. Do not equate positive reactions with acceptance.
INPUTS
Account:
Opportunity:
Session type:
Session date:
Buyer attendees:
Seller attendees:
Success criteria:
Transcript or notes:
Evidence produced:
Buyer reactions:
Questions:
Objections:
Capability gaps:
Actions:
Next steps:
Seller observations:
Information that must remain internal:
INSTRUCTIONS
1. Assess record quality.
2. Separate buyer statements, questions, reactions, commitments, seller interpretations, technical evidence, business evidence, and unknowns.
3. Evaluate each criterion as satisfied, partial, not satisfied, not tested, rejected, or requiring buyer validation.
4. Identify acceptance evidence.
5. Identify positive reactions that are not acceptance.
6. Identify capability gaps and impact.
7. Identify new stakeholders or criteria.
8. Select next decision: continue evaluation, discovery, business case, economic-buyer meeting, mutual plan, proposal, remediation, pause, or disqualify.
9. Assess qualification changes.
10. Create customer follow-up and CRM updates.
OUTPUT FORMAT
# POST-DEMO OR PROOF ADVANCEMENT PACKAGE
## 1. Executive finding
## 2. Evidence ledger
## 3. Criteria results
## 4. Buyer reaction analysis
## 5. Commitments
## 6. Capability-gap impact
## 7. Qualification changes
## 8. Advancement recommendation
## 9. Customer-facing follow-up
## 10. CRM updates
## 11. NEXT-WORKFLOW TRANSFER