partner-enablement-package

name

partner-enablement-package

description

Build partner-ready enablement packages that translate a direct sales motion into partner-safe messaging, onboarding, and field assets. Use when asked to create partner training, reseller onboarding, channel talk tracks, partner certification guidance, or partner launch support. Route direct-sales rep onboarding to onboarding-program-builder and internal-only launch enablement to product-launch-enablement.

Partner Enablement Package

Create a partner enablement package that helps external sellers represent the product accurately and consistently.

Confirm Inputs First

• Confirm whether a current revenue-enablement-context exists; if yes, use it as baseline assumptions, if no, capture only the highest-impact missing context.
• Confirm the partner type and motion: referral, reseller, services, marketplace, or channel.
• Confirm the product scope, target use cases, and target customer segment.
• Confirm what the partner must be able to do after enablement: position, qualify, demo, sell, or support handoff.
• Confirm the packaging needed: onboarding guide, talk track, deck outline, certification guidance, launch update, or all of the above.
• Confirm co-sell economics and governance constraints: lead registration, split rules, discount authority, and conflict escalation.
• Confirm known partner constraints, such as limited product access, services expectations, or compliance boundaries.
• Confirm approved source-of-truth assets partners are allowed to use.

If critical inputs are missing, ask for the smallest missing set. If the user prefers speed, proceed with labeled assumptions.

Read The Right Reference

• Read references/partner-package-blueprint.md before defining archetype variants and co-sell controls.

Default Workflow

1. Sort partner needs from internal needs. Keep only the material a partner can use safely and effectively.
2. Translate the message. Rewrite positioning, qualification, and proof in partner-safe language with no internal jargon.
3. Define the partner motion. Decide what the partner needs to say, ask, qualify, and hand off.
4. Build the core package. Include the onboarding guide, talk track, deck outline, certification guidance, and launch notes the partner actually needs.
5. Map approved content. List the source assets partners can use and the material they cannot see.
6. Add co-sell rules. Spell out lead registration, ownership, conflict handling, pricing authority, and escalation paths.
7. Set the support boundaries. Clarify services scope, handoff points, implementation expectations, and what not to promise.
8. Package for delivery. Return something partner managers and channel teams can use without extra rewriting.

Tool Notes

• Keep the default workflow tool-agnostic.
• If the user already works in PRM, LMS, Docs, or partner portals, use those systems as delivery channels rather than as workflow requirements.
• If direct partner data is limited, work from existing direct-sales materials and clearly label what still needs partner validation.

Output Contract

• Default to these deliverables unless the user asks for a narrower package:
• Partner positioning and talk track summary
• Qualification and handoff guidance
• Partner onboarding outline
• Core enablement asset list with purpose by asset
• Certification or readiness guidance
• Co-sell economics and governance summary
• Approved source-asset map with restricted-content notes
• Assumptions, gaps, and partner-specific risks

Quality Bar

• Package is usable by real partners, not copied directly from internal sales enablement.
• Messaging is accurate, bounded, and safe for external use.
• Qualification, escalation, and handoff logic are explicit.
• Assets match the partner motion and level of product access.
• Restricted internal-only information is clearly separated from partner-safe material.
• Output avoids channel theater and focuses on partner execution.