saas-sales-organization
Use when designing or scaling a SaaS sales organisation — sales motions, roles (SDR/BDR/AE/CSM/SE), pipeline stages, lead-to-cash, territory design, quota/commission, sales ops fundamentals, onboarding/ramp, and hiring rubrics. Sourced from "Blueprints for a SaaS Sales Organization" (van der Kooij, Pizarro).
Best use case
saas-sales-organization is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when designing or scaling a SaaS sales organisation — sales motions, roles (SDR/BDR/AE/CSM/SE), pipeline stages, lead-to-cash, territory design, quota/commission, sales ops fundamentals, onboarding/ramp, and hiring rubrics. Sourced from "Blueprints for a SaaS Sales Organization" (van der Kooij, Pizarro).
Teams using saas-sales-organization should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/saas-sales-organization/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How saas-sales-organization Compares
| Feature / Agent | saas-sales-organization | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when designing or scaling a SaaS sales organisation — sales motions, roles (SDR/BDR/AE/CSM/SE), pipeline stages, lead-to-cash, territory design, quota/commission, sales ops fundamentals, onboarding/ramp, and hiring rubrics. Sourced from "Blueprints for a SaaS Sales Organization" (van der Kooij, Pizarro).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# SaaS Sales Organization
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
<!-- dual-compat-start -->
## Use When
- Use when designing or scaling a SaaS sales organisation — sales motions, roles (SDR/BDR/AE/CSM/SE), pipeline stages, lead-to-cash, territory design, quota/commission, sales ops fundamentals, onboarding/ramp, and hiring rubrics. Sourced from "Blueprints for a SaaS Sales Organization" (van der Kooij, Pizarro).
- The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.
## Do Not Use When
- The task is unrelated to `saas-sales-organization` or would be better handled by a more specific companion skill.
- The request only needs a trivial answer and none of this skill's constraints or references materially help.
## Required Inputs
- Gather relevant project context, constraints, and the concrete problem to solve; load `references` only as needed.
- Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.
## Workflow
- Read this `SKILL.md` first, then load only the referenced deep-dive files that are necessary for the task.
- Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
- Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.
- For premium or enterprise offers, align the sales motion with account research, executive problem framing, proof assets, business case, stakeholder mapping, and concrete next-step commitments.
## Quality Standards
- Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
- Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
- Prefer deterministic, reviewable steps over vague advice or tool-specific magic.
## Anti-Patterns
- Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
- Loading every reference file by default instead of using progressive disclosure.
## Outputs
- A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
- Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
- References used, companion skills, or follow-up actions when they materially improve execution.
## Evidence Produced
| Category | Artifact | Format | Example |
|----------|----------|--------|---------|
| Release evidence | Sales organisation design document | Markdown doc covering motions, role mix (SDR/BDR/AE/CSM/SE), pipeline stages, and lead-source allocation | `docs/business/sales-org-design.md` |
## References
- Use the `references/` directory for deep detail after reading the core workflow below.
<!-- dual-compat-end -->
Design a sales organisation that matches your product motion, customer segment, and deal size. This skill is the "how we sell" counterpart to `saas-business-metrics`, `subscription-billing`, `software-pricing-strategy`.
## When this skill applies
- Founder-led sales has worked; it's time for the first hires.
- Scaling from $1M to $10M ARR and the sales team is breaking.
- Launching into a new segment (SMB → mid-market, or mid-market → enterprise).
- Designing sales ops foundations: CRM hygiene, forecasting, pipeline reviews, QBRs.
- Replacing a broken commission plan.
- Hiring SDRs, AEs, CSMs, or SEs and getting the roles right.
## Pick the sales motion before hiring anyone
```text
Deal size < $500 ARR, high volume, instant value -> Self-service (product-led growth)
Deal size $1k-$10k ARR, low touch -> SMB transactional (inside sales)
Deal size $10k-$100k ARR, medium touch, some evaluation -> Mid-market (inside + SE)
Deal size $100k+ ARR, complex evaluation, procurement -> Enterprise (field sales + SE + security review)
```
Rule: your motion is determined by the customer, not by preference. If buyers research and decide solo, self-service works. If buyers need help articulating value to a buying committee, enterprise is the only motion.
Premium sales rule: do not ask high-value buyers for time with generic outreach. Use trigger events, role-specific pains, relevant proof, a diagnostic point of view, and a clear reason the meeting is worth executive attention.
See `references/sales-motions-picker.md`.
## Roles and when to specialise
**SDR (Sales Development Representative)** — outbound prospecting; qualifies leads; hands off to AE.
**BDR (Business Development Representative)** — inbound-focused; qualifies marketing leads.
**AE (Account Executive)** — owns the deal from qualified opportunity to close.
**CSM (Customer Success Manager)** — post-sale adoption, renewal, expansion.
**SE (Solutions Engineer / Sales Engineer)** — technical discovery, demos, custom POCs.
**AM (Account Manager)** — named-account relationship, renewal, expansion.
**When to split AE into SDR + AE:**
- AEs spend >30% of time on prospecting.
- Deal cycle has distinct "qualify" and "close" phases.
- Team of 3+ AEs and growing.
**When to add SE:**
- Deals need custom demos or POCs.
- Win rate drops after technical stage.
- AEs cannot articulate the product deeply enough on technical probes.
**When to add CSM:**
- Net revenue retention is flat or declining.
- You have 50+ customers and adoption is inconsistent.
- Renewals are missed through neglect, not dissatisfaction.
See `references/roles-specialisation.md`.
## Pipeline stages that stand up to scrutiny
Every stage has an exit criterion. No exit criterion = not a stage.
```text
0. Lead — identified contact with fit signal
1. Qualified — BANT / MEDDIC / SPICED criteria met; discovery call scheduled
2. Discovery — pain identified, quantified impact, buying process mapped
3. Evaluation — demo / POC / trial in progress; champion identified
4. Proposal — pricing + terms delivered; procurement engaged
5. Negotiation — contract red-lines; legal review
6. Closed Won / Lost — booked
```
Discipline: a stage can only move forward when the exit criterion is provable (email, calendar invite, signed MSA). "I feel they're close" is not a criterion.
See `references/pipeline-stages.md`.
## Lead-to-cash
```text
Marketing / SDR produces lead
-> Qualified (MQL -> SQL) — agreed definition with sales
-> Opportunity (AE owns) — stages 2 to 6
-> Closed Won -> Order booked -> Onboarding starts
-> Customer Success adoption + expansion
-> Renewal + upsell
```
The handoffs are where deals die. Document exactly who owns what at each handoff and what fields in CRM must be populated.
See `references/lead-to-cash.md`.
## Territory design
Options:
- **Round-robin** — simplest; fair; no vertical expertise.
- **Geographic** — by country / region / time zone.
- **Vertical** — by industry (fintech, health, logistics).
- **Named-account** — each AE owns a list; best for enterprise.
- **Segment** — by employee count or ARR band.
Rule: design for fairness and motion. Don't split territories such that one person gets all the easy accounts. Rebalance yearly.
See `references/territory-design.md`.
## Quota + commission
Quota = annual sales target per AE. OTE = base + variable at 100% quota.
Typical structures:
- **Base : variable = 50:50** for AEs (SaaS norm).
- **Accelerators** — earn more above 100% attainment (e.g., 1.5x or 2x rate).
- **SPIFs** — short incentive pushes (new product, specific segment).
- **Clawbacks** — commission repaid if customer churns before N months.
- **Commission paid on cash collected** — not just bookings, to align with collections.
Rule of thumb: quota = 5× OTE for AEs in most SaaS categories. Less and you underperform; more and top performers leave.
See `references/quota-commission-design.md`.
## Sales ops fundamentals
CRM hygiene non-negotiables:
- Every opportunity has a close date that moves only with justification.
- Every stage has the required fields populated.
- Activity is logged in CRM, not in email or Slack.
- Weekly pipeline scrub — owners remove dead deals.
- Monthly forecast — bottom-up from AEs, reviewed by managers, committed to leadership.
Forecasting accuracy bands:
- Commit: >90% confidence, weighted average.
- Best case: >50% confidence.
- Pipeline: the rest.
If forecast is off by >15% two quarters in a row, there's a stage-definition problem, not a people problem.
See `references/sales-ops-fundamentals.md` and `references/forecasting-accuracy.md`.
## Onboarding + ramp
New AE ramp = time from start to quota-carrying. Typical 3–6 months.
Onboarding curriculum (weeks 1–4):
1. Product + value — pitch, demo script, objection handling.
2. Industry + personas — who buys, why, typical pain.
3. Proof assets — case studies, calculators, diagnostics, implementation roadmaps, objection handling, and premium positioning.
4. Process + tools — CRM, stage definitions, forecasting, cadence tools.
5. Shadow + role-play — with peers + manager.
6. First calls + first demos — supervised.
Rule: protect ramp. Don't throw accounts at an unfinished AE; outcomes hurt the AE, the customer, and the brand.
See `references/onboarding-ramp.md`.
## Hiring rubrics
Per role, define:
- **Success profile** — the 3–5 behaviours the top 25% demonstrate.
- **Disqualifiers** — signals that mean no, regardless of rapport.
- **Interview loop** — who evaluates what (recruiter screen, manager, peer, role-play, cross-functional).
- **Role-play** — always. Close one discovery call with the candidate as the AE.
- **Reference calls** — on-list + back-channel.
See `references/hiring-rubrics.md`.
## Anti-patterns
- Hiring AEs before product-market fit — they can't close what the market doesn't want.
- Hiring one AE and expecting them to figure it out alone. Hire two or wait.
- Splitting SDR from AE before you have 3+ AEs — too much overhead for a small team.
- Commission plans that reward non-retaining deals (no clawback on churn).
- Stage definitions that allow subjective advancement.
- Forecasting by gut instead of stage-weighted methodology.
- Quotas that no one hits (demotivating) or everyone hits (too low).
- Not firing reps clearly below quota after 2–3 quarters with coaching — unfair to team and customers.
## Read next
- `saas-business-metrics` — the metrics the sales org drives (MRR, CAC, payback, NRR).
- `subscription-billing` — the billing side of the quote-to-cash flow.
- `software-pricing-strategy` — what you sell at what price.
- `product-strategy-vision` — product direction that the sales org communicates.
- `competitive-analysis-pm` — win/loss analysis inputs.
## References
- `references/sales-motions-picker.md`
- `references/roles-specialisation.md`
- `references/pipeline-stages.md`
- `references/lead-to-cash.md`
- `references/territory-design.md`
- `references/quota-commission-design.md`
- `references/sales-ops-fundamentals.md`
- `references/forecasting-accuracy.md`
- `references/onboarding-ramp.md`
- `references/hiring-rubrics.md`Related Skills
saas-tenant-data-portability-and-erasure
Use when designing the GDPR/POPIA/CCPA-compliant data export (right to portability) and erasure (right to be forgotten) workflows for a multi-tenant SaaS — cascade through every data store including warehouse/backups, retention policy, requester verification, audit trail, multi-tenant nuances of erasing one tenant's data without affecting others, and the engineering for African market regulations (Uganda DPPA, Kenya DPA, POPIA).
saas-sso-scim-enterprise-auth
Use when implementing enterprise auth on a multi-tenant SaaS — SAML 2.0 and OIDC SSO with per-tenant IdP configuration, SCIM 2.0 user provisioning/deprovisioning, custom-domain support with automated TLS, IP allowlists per tenant, audit-log API, and the migration from email-password tenants to IdP-enforced tenants. The price of entry for enterprise SaaS.
saas-seeder
Bootstrap a new SaaS from the SaaS Seeder Template: setup database, configure environment, create super admin user, and verify three-tier panel structure. Use when initializing a new multi-tenant SaaS project from this template.
saas-rate-limiting-and-quotas
Use when designing per-tenant rate limits and quotas — algorithm choice (token bucket, sliding window, leaky bucket, fixed window), where to enforce (edge, gateway, service, DB connection pool, queue), per-plan / per-tier limits, soft vs hard caps, fair-queueing for noisy neighbors, headers and error responses, and how to expose quota usage to the tenant.
saas-lifecycle-email-orchestration
Use when designing the six core lifecycle email sequences (welcome/onboarding, behavioral/feature-discovery, upgrade/upsell, retention, reactivation, referral) — trigger contracts, branched automation, suppression rules, PQL/churn-risk triggers, and revenue attribution. Built on top of `saas-transactional-email-infrastructure`. Distinct from `tabler-email-templates` (HTML) and `subscription-billing` (raw billing events).
saas-erp-system-design
Use when designing configurable SaaS or ERP platforms with multi-step business workflows, domain modules, approvals, auditability, pricing and entitlements, operational reporting, and tenant-specific variation. Covers domain boundaries, workflow states, extension points, and control design.
saas-entitlements-and-plan-gating
Use when designing the entitlements engine that enforces what each plan/tier/tenant can do — feature flags vs entitlements distinction, limits enforcement (seats, API calls, storage, projects, AI tokens), gate placement (UI, API, worker), upgrade-discovery UX, override mechanisms for enterprise contracts, and the runtime that resolves "can this tenant do X right now?" in a few milliseconds.
saas-business-metrics
Complete SaaS metrics framework covering revenue (MRR/ARR/ARPU), growth (CAC/LTV/payback), retention (churn/NRR/GRR), engagement, customer satisfaction (NPS/CSAT/CES), unit economics, the Rule of 40, and SaaS finance basics. Use when measuring...
saas-architecture-strategy
Use when architecting or evaluating a cloud SaaS product — including choosing multi-tenant patterns, mapping deployment to IaaS, planning scaling and blast-radius isolation, aligning architecture to business capabilities, and reconciling multi-enterprise consumption requirements with operating-model constraints.
saas-admin-backoffice-tooling
Use when designing the internal admin / back-office console of a multi-tenant SaaS — tenant impersonation (audited, time-boxed), tenant lifecycle controls (suspend/restore/archive/hard-delete), billing operations (refunds, credits, plan overrides), feature-flag overrides per tenant, bulk actions (mass invite, plan migration, region migration), and the audit-log spine that backs all of it. Distinct from the customer-facing super-admin panel in `multi-tenant-saas-architecture`.
saas-accounting-system
Implement a complete double-entry accounting system inside any SaaS app. Users enter transactions naturally (sales, expenses, inventory) while the system auto-posts journal entries under the hood. Produces both user-friendly reports and technical...
multi-tenant-saas-architecture
Use when designing or reviewing a multi-tenant SaaS platform — tenant isolation model, three-panel separation (super admin, franchise admin, end user), zero-trust enforcement, audit trails, and per-tenant permission overrides. Unlike `modular-saas-architecture` which focuses on pluggable business modules, this skill defines the tenancy and auth boundaries that every module inherits.