Account
Pull live operating context
Google Apps Script pulls live ARR, product subscriptions, renewal dates, and health metrics from Totango and Salesforce APIs into the working dataset.
Case Study
CSM Assignment Engine
A dynamic workload optimization engine that routes accounts based on a Constrained Greedy Heuristic, balancing representative capacity, account complexity, and strategic risk.
System: constrained greedy assignment
01
The Problem
Hidden complexity creates false balance
Naive assignment models treat a $50K single-product account and a $500K five-product account identically — overloading reps with lower headcount but higher complexity.
Assigning SaaS accounts based purely on "current account count" creates a hidden imbalance. A $50K single-product account and a $500K five-product account require vastly different operational lift, yet naive assignment models treat them identically. As a result, reps with a lower absolute headcount are frequently the most overloaded due to hidden account complexity. Building a pure mathematical solver (like Linear Programming) to fix this is too resource-heavy and will consistently time out within Google Apps Script's execution limits.
02
Auditable Decision Trace
Account → weighted capacity → human exception → balanced book
This system trades academic perfection for operational reality. It separates pure mathematical scoring from the human-in-the-loop workflow, ensuring automation enhances — rather than overrides — management strategy.
Weighted capacity
Score the current book
The ScoringEngine evaluates current CSM portfolios against the four-dimension matrix. A single-product $50K account and a five-product $500K account are no longer treated as equal weight.
Human exception
Stage before committing
The AssignmentWorkflow ranks eligible CSMs, stages the highest-scoring candidate, and allows for manual manager override before committing. The Bouncer halts automation for Enterprise accounts.
Balanced book
Recalculate after every move
Upon commit, capacity is re-calculated dynamically. The next account is assigned to the CSM with the most remaining capacity. Results are logged for audit and rebalancing.
The engine uses a custom greedy assignment loop where accounts are pre-sorted by complexity (descending), and capacity is re-calculated dynamically after every single assignment.
03
Scoring Matrix
Four-dimensional capacity evaluation
Volume
Proximity to total account headcount ceilings. Prevents overloading reps who are already at capacity.
ARR
Proximity to financial portfolio caps. Anchored strictly to Annual Recurring Revenue, ignoring TCV to avoid inflating multi-year deal workload.
Renewal Balance
Smoothing out quarterly renewal distributions so reps aren't buried in a single quarter. Prevents seasonal overload spikes.
Portfolio Risk
The current proportion of at-risk accounts, ensuring reps with struggling books aren't handed more turbulence.
04
Design Patterns
Human-in-the-loop guardrails
The Bouncer Pattern
Automation handles the bulk, but human intuition handles the exceptions. If the system detects a high-value "Enterprise Alert" account (top-tier segments under ~300 total accounts), the assignment loop halts. The engine intentionally blocks direct automation for these targets, alerting leadership that a white-glove, manual match is required based on executive alignment and historical relationships.
ARR vs. TCV Anchoring
Capacity limits are anchored strictly to ARR, ignoring TCV. A 3-year deal at $100k ARR evaluated as $300k TCV instantly eats up rep capacity. When renewed for a standard 1-year term, the math incorrectly registers a massive retention penalty. Anchoring to ARR keeps workload grounded in present-day reality.
The New Hire Magnet
Ramping reps need repetitions, not complex math. The engine applies a flat volume boost (Score = 85) to new hires. Protected by the Bouncer preventing them from taking Enterprise accounts, this logic turns new reps into magnets for standard accounts until they hit their targeted ramp capacity.
Evidence dossier
CSM Assignment Engine
Approved visitor-safe summary derived from the evidence ledger. Sanitized depictions remain separated from raw operating evidence.
Ledger source: docs/proof/evidence-ledger.md
Publication classes: Public, Sanitized depiction
- RolePublic
- System design separated mathematical scoring from the human-in-the-loop workflow.
- ConstraintsPublic
- Account-count assignment hid material differences in account complexity, ARR, product footprint, renewals, and portfolio risk.
- JudgmentPublic
- A constrained greedy heuristic favored practical execution over a resource-heavy exact solver, with dynamic capacity recalculation.
- Visitor-safe evidenceSanitized depiction
- The inline diagram depicts Pull -> Score -> Bouncer -> Assignment -> Balance, plus ARR anchoring and new-hire handling.
05
Results
Operational impact
1,200+
Accounts assigned dynamically
4D
Scoring matrix (Volume, ARR, Renewal, Risk)
0
Manual spreadsheet passes required post-deployment
06
Implementation
Systems and operating method
Connected Systems
Google Apps ScriptTotango APISalesforce APIGlean API
Design Patterns
Constrained Greedy HeuristicBouncer PatternARR AnchoringNew Hire MagnetStaging → CommitCheckpoint/Resume
Discover
Manual process mapping & pain analysis
Design
Four-dimension scoring matrix & greedy heuristic
Deliver
Google Apps Script engine with API integrations
Govern
Bouncer pattern & human-in-the-loop guardrails