Resource Allocation and Capacity Planning Questions

Requirements clarification: automate safe, efficient matching of incoming opportunity to SA based on ARR, technical-complexity, strategic-fit, product-fit, geography, current-load, and skill-tags while preserving fairness and human control.

Scoring function (weighted linear score):
Score = w1norm(ARR) + w2norm(TechComplexity) + w3norm(StrategicFit) + w4norm(ProductFit) + w5GeoAffinity + w6(1 - norm(CurrentLoad)) + w7*SkillMatch

• SkillMatch = sum(tag_weight_i * match_i) where match_i ∈ {0,1} or graded by proficiency.

Normalization:

• Use min-max per feature across rolling 90-day window, clipped at [0,1]. ARR and load log-transform before min-max to reduce skew. GeoAffinity binary or distance-based decay normalized to [0,1].

Threshold bands for auto-assignment:

• Auto-assign if Score ≥ 0.85 and SkillMatch ≥ 0.7 and CurrentLoad ≤ 0.8.
• Auto-suggest (queue to manager) if 0.65 ≤ Score < 0.85 or SkillMatch 0.5–0.7.
• Manual only if Score < 0.65, TechComplexity high (>0.8) but SkillMatch <0.5, or strategic flag set.

Manual override rules:

• Sales or SA can override with mandatory reason code; overrides feed audit log.
• If SA declines two auto-assigns in 30 days, suspend auto-assignment for them until review.
• Escalation: high-ARR (>top 5%) always notifies ARCH lead for confirmation.

Feedback loop & weight updates:

• Capture signals: accept/decline, success (opportunity progressed to next stage), win rate, time-to-engage, customer satisfaction.
• Online learning: daily aggregate; retrain weights monthly using constrained logistic regression / gradient boosting optimizing success probability with L2 regularization and fairness constraints.
• A/B test weight changes before global rollout; allow manual weight adjustments by ops.

Fairness & constraints:

• Capacity caps: ensure no SA receives >X% of opportunities for given week; enforce per-region and per-role quotas.
• Rotation: small-proportion randomized assignments to maintain exposure for development.
• Protected attributes: do not use demographics; monitor metrics (assignment rates, outcomes) across cohorts and apply regularization to reduce disparate impact.
• Transparency: provide SA dashboard with score breakdown, reasons for assignment, and appeal path.

Operational notes:

• Implement as microservice with retrainable model, explainable scoring API, human-in-the-loop UI, audit logs, and metrics (time-to-first-touch, conversion lift).

Approach:

1. Gather historical data (last 4–6 quarters) on hours spent by SAs on: pre-sales proposals (discovery, architecture, docs, demos), post-sale onboarding, and reactive support tickets. Break down by opportunity size/type (SMB, mid-market, enterprise) and by phase of deal cycle.
2. Normalize data to effective FTE-hours (e.g., convert partial-day tasks to hours). Calculate average hours per opportunity type and average tickets per customer with mean time to resolution (MTTR).
3. Make clear assumptions: expected deal mix (number of SMB/mid/enterprise deals), average deal size, anticipated ramp-up time for new customers, and any planned hires or vacations. Document these explicitly.
4. Compute expected workload = Σ(expected #deals_of_type × avg_hours_per_deal) + projected support-hours. Apply a safety margin (buffer) — typically 15–30% depending on uncertainty — to cover spikes, onboarding overruns, and knowledge gaps.
5. Convert total hours to capacity in FTEs (total available working hours per SA per quarter) to show headcount gap or surplus. Present scenarios (best/likely/worst) using conservative and optimistic assumptions.

Three metrics to collect going forward:

• Average SA hours per opportunity by deal type (refines proposal effort estimates).
• Tickets per customer per quarter and MTTR (improves support workload forecasting).
• Win-rate and lead-to-opportunity conversion time (helps predict number of proposals needed and timing).

This method provides traceable assumptions, repeatable calculations, and scenario-backed safety margins for sales and operational planning.

Approach: I treat capacity as a function of expected effort per account (E) and available productive hours per SA (H). Estimate E from measurable drivers (ARR, technical complexity, travel, implementation scope, vertical specialization) and then compute concurrent accounts ≈ H / average E, adjusting for ramp, admin, and team support.

Influencing factors (how they change E):

• Account ARR: higher ARR → more stakeholders, review cycles, and governance → increases E. Example bands: low (<$50k), mid ($50k–$500k), high (>$500k).
• Technical complexity: bespoke integrations, multi-cloud, strict security/ compliance double or triple E versus standard SaaS configs.
• Travel: frequent onsite workshops/POCs add days per quarter; convert travel to equivalent weekly hours.
• Implementation scope: long professional services or multi-phase rollouts increase E linearly with phases.
• Vertical specialization: regulated industries (healthcare/finance) require domain expertise, audits, and extra artifacts → higher E.

Sample capacity ranges (per full‑time experienced SA, with ~1,200 productive hours/year):

• SMB (ARR < $50k, low complexity, minimal travel): 12–20 concurrent accounts. Justification: low per-account setup and mostly templated solutions; SA spends ~60–100 hours/year/account.
• Mid‑market (ARR $50k–$500k, moderate complexity, occasional onsite): 6–10 concurrent accounts. Justification: ~120–200 hours/year/account for architecture + demos + stakeholder sessions.
• Enterprise (ARR > $500k, high complexity, regular travel, multi‑phase): 2–4 concurrent accounts. Justification: 300–600+ hours/year/account due to architecture depth, exec engagement, and multiple delivery phases.

Adjustments and governance:

• Use weighted scoring (0–5) per factor to compute relative E per account and sum to forecast load.
• Account for team models: overlay SAs, pre/post-sales handoffs, and PS support reduce E per SA.
• Monitor utilization and outcomes quarterly; tune bands by measuring actual hours per account and customer satisfaction.
  This provides a repeatable, data-driven way to size SA workloads while allowing flexibility for special cases.

Approach: break the 6‑month implementation into phases (Discovery, Design, Build, Test, Deploy/Support). For each phase estimate required roles, FTEs per month, training / ramp time, and a contingency buffer. Use a simple table template and a ramp model that increases FTEs early then tapers.

Template (columns for proposal):

• Role (e.g., Solutions Architect, Tech Lead, Dev, QA, SysAdmin, PM)
• Core skills required
• Total FTE-months requested
• Monthly FTE ramp (M1..M6)
• Training / onboarding days (per FTE)
• Notes / dependencies

Method:

1. Phase mapping: assign % effort by phase (e.g., Discovery 15%, Design 20%, Build 35%, Test 20%, Deploy/Support 10%).
2. Role baselines: define nominal FTEs for peak build (example for medium project): Solutions Architect 0.5–0.8 FTE, Tech Lead 1.0, Developers 3.0, QA 1.5, SysAdmin/DevOps 0.8, PM 0.5.
3. Ramp schedule: assume 2‑week onboarding for each new role. Model monthly ramp as: M1 50% of peak, M2 80%, M3‑M4 100% (peak), M5 80%, M6 60% for support/decommissioning.
4. Training: allocate 8–16 hours per role for product specifics + 2 days for environment access/security; convert to FTE-days and add to M1 ramp demand.
5. Contingency: add 15% buffer to total FTE‑months for risk (knowledge gaps, rework, scope creep). For high-uncertainty projects use 20–25%.

Example (summary numbers):

• Developers peak 3.0 FTE → M1 1.5, M2 2.4, M3 3.0, M4 3.0, M5 2.4, M6 1.8
• QA peak 1.5 FTE → M1 0.75, M2 1.2, M3 1.5, M4 1.5, M5 1.2, M6 0.9
• Add training: 1 developer-day per dev in M1 (counts toward M1)
• Add 15% contingency added across each month as separate “buffer” line item

Skills matrix: map each role to must-have and nice-to-have skills (e.g., Dev: Java, REST, CI/CD; SysAdmin: Terraform, Kubernetes). Use this to recruit or upskill existing staff; if upskilling required, increase training allocation.

Why this works: phasing ties effort to deliverables; ramp models reflect hiring/onboarding realities; explicit training prevents hidden schedule slips; contingency quantifies reserve rather than leaving implicit. Provide the template table in the proposal and attach monthly FTE chart (stacked by role) so stakeholders can see cost/timeline impact.