Post-Sale Handoff

Bridge what was sold to what gets built. AI generates handoff documents covering technical requirements, integration dependencies, success criteria, and risk register for the delivery team.

Skill Details

Install this skill

Versionv1.0.0AuthorJorge ArteagaLicenseMITSections18

Works with

Claude CodeCursorWindsurf

When This Skill Owns the TaskWorkflow

Required Context to Gather FirstWorkflow

Before generating the handoff package, ask for or infer:

Won products and scope — Which Salesforce clouds and features were sold?

Contract and commercials — ARR, contract length, user count, add-ons?

Implementation timeline — When does the customer expect to go live?

Known technical requirements — From the sales cycle: integrations, SSO, data migration needs?

Customer contacts — Who is the project sponsor, IT lead, and business owner on their side?

Internal delivery team — Who is the implementation AE, CSM, and project manager (if assigned)?

Open items — What was left unresolved during the sales cycle that delivery needs to address?

Risks flagged — Any technical, organizational, or commercial risks from the sales process?

WorkflowWorkflow

Document the sold scope — Clear description of what was contracted, including exact products and SKUs.

Capture the business context — Why did they buy? What business outcomes are they expecting?

Detail technical requirements — Integration map, data migration needs, SSO, security, compliance.

Map the stakeholders — Who does the delivery team need to know and why?

Define success criteria — Quantified metrics that define what "success" means for this customer.

Build the risk register — Technical, organizational, and commercial risks with mitigations.

List open items — Anything unresolved from the sales cycle that delivery must close.

Schedule the handoff meeting — The document is a starting point; the handoff meeting is the transfer.

Core Frameworks

What Gets Lost Between Sales and Delivery

The most common handoff failures — and how to prevent them:

Success Criteria Framework

Success criteria must be:

Specific — "Sales team adoption of 90% within 60 days" not "good adoption"
Measurable — There must be a number
Time-bound — By when?
Agreed — The customer's economic buyer should have signed off on these

Output FormatTemplate

Handoff Package Template

MARKDOWN

# Sales-to-Delivery Handoff — [Company Name]
**Date:** [Date] | **SE:** [Name] | **AE:** [Name]
**Implementation Lead (if assigned):** [Name] | **CSM:** [Name]

---

## 1. The Opportunity Summary
- **Products sold:** [Cloud 1 (X users, $Y ARR), Cloud 2...]
- **Contract value:** $[ARR] / $[TCV]
- **Contract start:** [Date] | **Go-live target:** [Date]
- **Renewal date:** [Date]

---

## 2. Why They Bought (The Business Context)

**The business problem they were solving:**
[2-3 sentences: the specific pain that drove the purchase — in the customer's words if possible]

**The outcome they expect:**
[What success looks like to the economic buyer — be specific]

**The quote that captures it:**
*"[Verbatim quote from the economic buyer if you have one]"*

**The moment that closed the deal:**
[What ultimately tipped them from evaluating to buying?]

---

## 3. Sold Scope and Capabilities

| Product | Features Included | Users | Notes |
|---------|------------------|-------|-------|
| [Cloud] | [Feature list as sold] | [Count] | [Any commitments or caveats] |

**Capabilities promised in the sales cycle (delivery must honor these):**
- [Specific capability or configuration that was committed to]
- [Specific capability]

**Items explicitly out of scope:**
- [What was excluded — prevents scope creep]

---

## 4. Technical Requirements

### Integration Map

| System | Direction | Data | Pattern | Priority |
|--------|-----------|------|---------|---------|
| [ERP name] | Bidirectional | [Data being synced] | [REST / Bulk / MuleSoft] | [P1/P2/P3] |

### Data Migration
- **Migrating from:** [Source system]
- **Data types:** [Objects being migrated — Accounts, Contacts, Opportunities, etc.]
- **Volume:** [Approximate record counts]
- **Data quality notes:** [Any known data quality issues]

### Authentication / SSO
- **SSO required:** [Yes/No]
- **Identity provider:** [Okta / Azure AD / ADFS / Other]
- **MFA requirement:** [Yes/No]

### Security and Compliance
- **Compliance requirements:** [HIPAA / GDPR / SOC2 / FedRAMP / Other]
- **Data residency:** [EU / US / APAC / Hyperforce requirement]
- **Special access restrictions:** [Field-level security needs, profile restrictions]

---

## 5. Stakeholder Map

| Name | Title | Role | Relationship | Contact |
|------|-------|------|-------------|---------|
| [Name] | [Title] | Economic Buyer / Sponsor / Champion / IT Lead / User Lead | [Relationship quality: Strong/Neutral/Risk] | [Email/phone] |

**Who to call first if things go wrong:** [Name, why]
**Who to avoid escalating to without preparation:** [Name, why]

---

## 6. Success Criteria

| Metric | Baseline | Target | Measurement Date | Owner |
|--------|---------|--------|-----------------|-------|
| [Metric] | [Current] | [Goal] | [Date] | [Customer or Salesforce] |

**First QBR date:** [Date — should be 90 days post-go-live]

---

## 7. Risk Register

| Risk | Type | Severity | Likelihood | Mitigation |
|------|------|----------|-----------|-----------|
| [Risk description] | Technical / Organizational / Commercial | H/M/L | H/M/L | [How to mitigate] |

**The thing most likely to cause a difficult first 90 days:**
[Specific risk with context — the one the SE knows from the sales cycle]

---

## 8. Open Items (Sales Cycle Commitments Not Yet Resolved)

- [ ] [Item that delivery must close — owner, deadline]
- [ ] [Item]

---

## 9. Competitive Context
- **Competitors evaluated:** [Names]
- **Why we won:** [The 1-2 reasons the customer chose Salesforce]
- **What the runner-up is likely to do:** [Re-engage at renewal, etc.]
- **Bar that was set:** [What the customer benchmarked us against]

---

## 10. Notes for the CSM / AE on Renewal
[Anything the SE wants to flag for the renewal conversation in 12-24 months]

Anti-PatternsReference

Scoring Rubric (90 Points)Reference

Cross-Skill IntegrationReference

Task	This Skill	Defer To
Create a post-sale handoff package	Yes	—
Document technical requirements for the delivery team	Yes	—
Produce a risk register for the implementation	Yes	—
Set up success criteria for the engagement	Yes	—
Design the technical solution (pre-sale)	No	sf-se-whiteboard
Run the implementation itself	No	sf-deploy (or PS team)
Build the business case	No	sf-se-proof-of-value
What Was Lost	Why It Matters	How to Capture It
The emotional context ("Why they bought")	Delivery teams can technically succeed but miss the business outcome	Include "Why they bought" section with verbatim quotes from economic buyer
The champion's fear ("What they're worried about")	Delivery unintentionally triggers the champion's biggest concern	Document unstated concerns from the sales cycle
Technical promises ("We said we could do X")	Delivery discovers X requires a workaround and surprises the customer	Document every technical commitment made during the sales cycle
The competitive context ("Who else was in the deal")	Delivery doesn't know the customer was almost with a competitor	Include competitive context so delivery knows where the bar is set
The relationship map ("Who to call when things go sideways")	Delivery escalates to the wrong person	Hand off the stakeholder map with relationship context
Category	Example Success Criterion
Adoption	90% of licensed users logging in at least weekly within 90 days of go-live
Process efficiency	Opportunity update time reduced from 25 min to <5 min by end of Q1
Business outcome	Pipeline visibility report available to VP of Sales weekly within 60 days
Technical	All [X] integrations live and tested before go-live
User satisfaction	User satisfaction score >4.0/5.0 within 60 days of launch
Anti-Pattern	Why It Fails	Fix
Sending the contract as the handoff	The contract says what was sold; not why, or what the customer actually expects	Supplement the contract with the narrative context from the sales cycle
Handoff without a meeting	The document gets filed; delivery misses the nuance	Always run a handoff meeting where SE talks delivery through the context
No success criteria	Delivery doesn't know what "success" looks like; customer becomes dissatisfied even if the tech works	Define measurable success criteria before the handoff; get EB sign-off
Vague risk register ("communication might be hard")	Delivery can't act on vague risks	Name the specific person, system, or assumption that is the risk
Not documenting what's out of scope	Delivery says yes to customer requests that weren't sold; scope creep follows	Explicitly list what was excluded during the sales conversation
Omitting competitive context	Delivery doesn't know the customer was almost with a competitor; missteps erode the relationship	Always include who else was evaluated and why we won
Category	Points	Pass Criteria
Business Context	20	"Why they bought" is documented with verbatim language if possible
Technical Requirements	25	Integration map, data migration plan, SSO, and compliance documented
Success Criteria	20	At least 3 measurable success criteria with timelines
Risk Register	15	Top 3-5 risks with specific mitigation actions
Open Items	10	All unresolved commitments from the sales cycle listed with owners
Skill	When to Use It
sf-se-whiteboard	Attach the solution design from the sales cycle to the handoff
sf-se-architecture-review	Attach the architecture assessment if one was done
sf-se-proof-of-value	Include the success metrics from the PoV as the baseline for success criteria
sf-se-stakeholder-mapping	Attach the full stakeholder map to the handoff
sf-se-deal-strategy	Reference the win strategy for competitive context in the handoff