- Working definition: Ramp Schedule needs a published definition, population, evidence source, owner, operating consequence, effective date, and review condition.
- Business purpose: Ramp Schedule 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 Schedule 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 Schedule, naming every handoff, approval, output, and effective-date consequence.
- BoogieBoard doctrine: Publish the Ramp Schedule standard before reviewing assignments so its tradeoffs remain visible and the approved sequence cannot be reverse-engineered from preferred outcomes.
What is Ramp Schedule?
A Ramp Schedule assigns dated productivity expectations to new or transitioning sellers so coverage, quota, and account transfers reflect when capacity becomes available, 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.
Start Ramp Schedule with a precise statement of the decision it governs. 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 Schedule 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, Productivity Baseline, Quota Multiple with Ramp Schedule. Those concepts may supply inputs, constrain the decision, or consume its output, but none should silently inherit the same definition.
What Ramp Schedule 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.
how many roles and segments exist in your model - what one rep can realistically handle in each role - how your ramp schedule works - whether future Territories are built ahead of time or just in time - what metrics define a healthy Territory in each segment - how quota should align to ramp and Territory readiness
Run Ramp Schedule 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 Schedule 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 Schedule result or decision from that retained evidence.
How Ramp Schedule works step by step
A team plans for 14 territories, including 2 roles that will be hired after the start of the period. It documents how Ramp Schedule 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 Schedule 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 Schedule variations and decision points
Ramp Schedule 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 Territory Viability, To-be-hired Territory, Temporary Coverage, Ramp Curve alongside Ramp Schedule. 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 Schedule failure modes and controls
The primary Ramp Schedule 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 Schedule 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 Schedule 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 Schedule, 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.
