Partner enablement package

Partner enablement package

Build a partner-safe package. If it is a copied direct-sales pack, rewrite it.

Partners get only what they may say and do under the agreement. Channel managers get the economics, conflict rules, and restricted proof in a separate internal pack.

Partner-safe. "You may position MosaicOps to mid-market ops buyers and register the lead. You may not quote discount, promise custom ERP, or share the four-customer pilot."

Copied pack. The AE battlecard, our win rate versus Competitor X, and the Q3 discount grid, with "partner" find-replaced in.

If a partner could quote an internal number after reading it, it is not done. The channel manager's file can hold that number; the partner's file cannot.

Confirm Inputs First

Ask only for the inputs that change the package:

1. Partner type and what they are actually allowed to do
2. The job after enablement: position, qualify, demo, sell, or hand off
3. Approved partner-facing claims, proof, and branding
4. What must stay internal: economics, discounts, account strategy, restricted proof

If a right, claim, or economic rule is missing, leave it unknown. Do not invent partner claims, discounts, territories, or readiness.

Read The Right Reference

Read references/partner-package-blueprint.md for the copy-paste tell, claim classification, and the partner-facing versus internal split. Skip it if they already handed you a classified source list and only want assembly.

Default Workflow

1. Define the permitted motion. Map what this partner may position, qualify, demonstrate, sell, deliver, and hand off. Partner type is context, not permission. Done when each activity has a scope, a prohibited commitment, and a handoff owner.
2. Classify every source. Mark partner_safe, internal_only, or unverified. Direct-seller approval does not approve partner use. Done when nothing unverified sits in a partner-facing artifact.
3. Build the partner-facing package from partner_safe only. Positioning, qualification, handoff, approved proof, and the learning they need for this motion. Cut anything a direct AE uses that this partner cannot defend.
4. Build the internal operator pack separately. Rights, lead registration, split rules, discount authority, conflict escalation, restricted content, exceptions, and support obligations. Never nest this inside a partner document.
5. Define observable readiness. Task, evidence, standard, assessor, remediation. Attendance is not ready. If the decision is a formal pass/fail, use certification-program-builder and consume that artifact; do not recreate it.
6. Review the boundary. Block unverified claims, expired assets, and content outside this partner's rights. Done when a channel manager can hand the external file to a partner without redacting.

For direct-hire ramp use onboarding-program-builder. For an internal-only launch kit use product-launch-enablement.

Output Contract

Return two artifacts, labeled as such:

• Partner-facing package: permitted motion, approved messaging, qualification, handoff, and readiness guidance
• Internal operator pack: rights, economics, claim ledger, restricted-content map, exceptions, and support ownership
• Approval status and blockers on each deliverable

Do not merge the two files. Do not publish, change portal access, or mark a partner ready without explicit approval.

Quality Bar

• A partner can execute the permitted motion without seeing internal economics.
• A channel manager can operate the motion from the internal pack.
• The package refused to be a find-replaced AE kit.
• Every external claim is approved for this partner audience, or is absent.
• Readiness is an observed task, not a completion checkbox.
• Qualification, escalation, and handoff owners are named.
• No invented claims, discounts, territories, or readiness states.