---

name: yepai-sales-engineer description: >- Pre-sales technical discovery, demo engineering, POC scoping, competitive technical positioning, and solution architecture. user-invocable: false disable-model-invocation: false metadata: {"openclaw":{"emoji":"🛠️"}} tags: [sales] license: MIT-0

Pre-Sales Engineering Criteria

When preparing demos, scoping POCs, handling technical evaluations, or positioning competitively, apply these frameworks.

Demo Craft

A demo is not a product tour — it's a narrative where the buyer sees their problem solved.

1. Quantify the problem first: Before touching the product, restate buyer pain with specifics. "Your team spends 6 hours/week manually reconciling — let me show you what automated looks like."
2. Show the outcome: Lead with end state (dashboard, report, workflow result) before explaining how.
3. Reverse into the how: Once they react ("that's what we need"), walk through config and architecture.
4. Close with proof: Customer reference mirroring their situation.

Non-negotiable: Tailored demos only. Review discovery notes, map top 3 pain points to capabilities, use buyer's terminology. Prepare a flexible deep-dive path for "show me under the hood" moments.

Aha Moment Test: Every demo must produce at least one "that's exactly what we need" moment. Plan for it.

POC Scoping

A POC is not a free trial — it's a structured evaluation with a binary pass/fail outcome.

• Problem statement: "This POC will prove that [product] can [capability] in [environment] within [timeframe], measured by [criteria]."
• Success criteria in writing before starting: Ambiguous criteria = ambiguous outcome = "need more time" = you lost.
• Scope aggressively: Focused POC proving one critical thing > sprawling POC proving nothing. "Absolutely — in phase two."
• Hard timeline: 2-3 weeks. Longer POCs produce evaluation fatigue, not better decisions.
• Midpoint checkpoint: Catch misalignment early.

FIA Competitive Framework

• Fact: Objectively true about competitor. No spin. Credibility is the SE's most valuable asset.
• Impact: Why this fact matters to the buyer. "Requires dedicated ETL" = fact. "Adds 2-3 weeks implementation + ongoing maintenance" = impact.
• Act: Specific talk track or demo moment to make the point land.

Never trash competitors. Acknowledge strengths, articulate differentiation: "They're great for X. Our customers typically need Y because [reason], which is where we differ."

Technical Objection Decoding

They Say	They Mean	Response Strategy
"Does it support SSO?"	"Will this pass security review?"	Walk full security architecture
"Can it handle our scale?"	"We've been burned before"	Benchmark data from equal/greater scale
"We need on-prem"	Security team or sunk cost?	Understand which — different conversations
"Competitor showed us X"	"Match or convince me"	Reground in their requirements first
"Build internally"	Vendor dependency fear	Quantify build cost vs. buy cost

Deliverable: POC Template

# POC: [Account Name]

## Problem Statement
[One sentence: what this POC will prove]

## Success Criteria (agreed before start)
| Criterion | Target | Measurement |
|-----------|--------|-------------|
| | | |

## Scope
- **In**: [Features, integrations, workflows]
- **Out**: [What we're NOT testing and why]

## Timeline
- Day 1-2: Setup | Day 3-7: Core implementation | Day 8: Midpoint review
- Day 9-12: Refinement | Day 13-14: Final readout + GO/NO-GO decision

Deliverable: Evaluation Notes

# Evaluation: [Account Name]

## Technical Environment
- Stack: [Languages, frameworks, infra] | Integration: [APIs, DBs, middleware]
- Security: [SSO, SOC 2, data residency] | Scale: [Users, data volume, throughput]

## Technical Decision Makers
| Name | Role | Priority | Disposition |
|------|------|----------|-------------|
| | | | Favorable / Neutral / Skeptical |

## Demo/POC Strategy
- Primary narrative: [Story arc] | Aha moment: [Target capability]
- Risk areas: [Where to prepare objection handling]