- Working definition: Ramp Curve needs a published definition, population, evidence source, owner, operating consequence, effective date, and review condition.
- Business purpose: Ramp Curve makes one capacity-and-quota decision inspectable instead of allowing the current assignment or loudest stakeholder to become the rule.
- Mechanics: Define the trigger, required inputs, decision owner, ordered steps, output, effective date, and exception or restart path.
- Operating context: Use Ramp Curve during planning, scenario review, activation, and material in-year changes while keeping current and proposed states separate.
- Practical test: Walk one ordinary case and one edge case through Ramp Curve, naming every handoff, approval, output, and effective-date consequence.
- BoogieBoard doctrine: Publish the Ramp Curve standard before reviewing assignments so its tradeoffs remain visible and the approved sequence cannot be reverse-engineered from preferred outcomes.
What is Ramp Curve?
A Ramp Curve models how a seller's expected productivity changes from start date to full productivity across defined periods, with the definition, owner, evidence, and review timing published before assignments are approved. It becomes operational when the population, source evidence, owner, and consequence are explicit enough for another reviewer to reproduce.
Define Ramp Curve from the operating decision it is meant to support. In the capacity & quota context, that decision should connect available selling capacity and quota expectations to the number, timing, and viability of territories. Its definition should exclude adjacent decisions that use different evidence, owners, or consequences.
A complete Ramp Curve definition identifies its trigger, starting state, required inputs, decision owner, ordered steps, output, effective date, and restart or exception path. The workflow is incomplete if a handoff depends on private context.
Review Capacity Planning, Headcount Plan, Ramp Schedule, Productivity Baseline with Ramp Curve. Those concepts may supply inputs, constrain the decision, or consume its output, but none should silently inherit the same definition.
What Ramp Curve requires
Start with approved roles, hiring dates, ramp assumptions, productivity evidence, quota expectations, account potential, and go-live timing. Record the field or policy owner, source date, transformation, comparison population, and correction path. If any required input is unavailable, mark the limitation rather than filling it with an undocumented proxy. That preserves the difference between observed evidence and planning judgment.
For Ramp Curve, document the business reason, included population, source field or evidence, decision owner, operating consequence, and condition that causes a review. Test the definition against a normal record and an edge case before using it across the full population.
Run Ramp Curve against a preserved current state before changing live assignments. Record the starting condition, each decision and handoff, the proposed output, and the effective date. That creates a comparison point when timing, hiring, evidence, or policy changes later.
The operating record for Ramp Curve should show each case's trigger date, owner, current step, pending decision, due date, output, and final effective state. Aggregate reporting can reveal delays, but the case record must explain where and why a specific item stopped. That evidence supports both daily administration and later process redesign. Before approval, ask a reviewer outside the original design team to reproduce the Ramp Curve result or decision from that retained evidence.
How Ramp Curve works step by step
A team plans for 11 territories, including 5 roles that will be hired after the start of the period. It documents how Ramp Curve affects territory count, coverage timing, ramp, quota, and the accounts that cannot wait for a fully productive owner. The current roster remains the baseline, but it is not mistaken for the planned end state.
The team models at least two dated scenarios: one using the approved hiring and ramp assumptions and another showing a delay. For each scenario it identifies vacant or to-be-hired territories, temporary coverage, staged account transfers, manager capacity, and the date on which durable ownership should begin.
Leaders approve Ramp Curve only after reconciling the capacity plan with quota and territory viability. If hiring timing changes, the scenario is revised explicitly. Accounts do not drift between owners through informal coverage, and a later hire does not inherit unexplained commitments created before the role existed.
Ramp Curve variations and decision points
Ramp Curve may vary by segment, role, customer motion, geography, product, and planning stage when the business reason is published. Each population still needs an internally consistent standard and a clear explanation of why its treatment differs.
Test the rule against ordinary cases, edge cases, vacancies, and material in-year changes. Review both the summary outcome and underlying account roster. The standard should remain usable when the original planner is no longer present to explain it.
Review Quota Multiple, Territory Viability, To-be-hired Territory, Temporary Coverage alongside Ramp Curve. Preserve their distinct definitions and show the dependency between them so a correction to evidence does not quietly become a policy exception or assignment preference.
Ramp Curve failure modes and controls
The primary Ramp Curve failure is designing a full territory roster before the organization has reconciled hiring timing, ramp, and role-level productivity. Prevent it by publishing the definition and decision sequence before individual assignments are reviewed, then evaluate proposed changes across the full affected population.
Another failure is allowing Ramp Curve to end at a handoff with no accountable next owner or effective-state check. Define completion evidence, escalation timing, and the condition that restarts the workflow when an input changes.
Review Ramp Curve after each material cycle and when a trigger, role, handoff, approval, or system dependency changes. Track delayed cases, incomplete outputs, expired temporary states, and repeated escalations to find where the workflow is failing.
In practice with BoogieBoard
For Ramp Curve, the relevant BoogieBoard workflow is a proposed capacity or coverage change that remains reviewable before activation. BoogieBoard Codex lets an operator describe a coverage or capacity change in plain language and return a proposed update for review. The resulting territory and role assignments are still evaluated as a scenario rather than applied as an unexplained command. Teams can inspect the affected population, compare the proposal with the current state, and preserve the decision history before activation. This is useful when the concept changes hiring timing, temporary coverage, role capacity, or the number of territories that need to be supported.
