Role
Staff Product Designer
Year
2026 - Present
Teams
- Global CRM
Book of Business Quarterly Transfer
Every sales team owns a Book of Business: the customer accounts it manages. Each quarter, teams reshape it by pulling in high-potential accounts, releasing others, and upgrading growing customers to key account coverage. The result decides who manages each customer and whose target each dollar counts toward. And ownership is zero-sum: one team's gain is another's loss, revenue included. A single transfer can lower another team's target, exceed regional capacity, or break a higher-level rule.
The challenge - The process used to run offline. Rules lived in documents, data lived in separate systems, and conflicts surfaced only after decisions were made. Leaders couldn't see the consequences of a transfer, and the regional operations team, rMSO (Regional Monetization Strategy & Operations), had no single view of 60+ teams globally.
But going online was the easy part. Sales leaders wanted speed and freedom; rMSO needed consistent rules, clean data, and fair arbitration. Too loose, and the plan breaks at execution. Too strict, and leaders work around it. So I started with the operating model (who decides what, when, and with what information) and designed the experience around it.
The system - Each decision sits with the people best placed to make it. rMSO sets rules once. Leaders make transfers within them. rMSO settles collisions. A dashboard shows where every team stands. Two principles connect it all. Context travels: a rule becomes a recommendation's reason, then a check on selection, then a flagged conflict. Validation tightens: flexible while leaders explore, strict as execution nears.
One view of the entire operation - rMSO's core question is where the risk is. The dashboard answers it without opening every team. Top metrics size the work; each team row shows its step, status, and deadline. Every signal is an entry point, and conflict counts link straight to resolution. It's where work starts, not a report.
Policy, written once - rMSO defines rules once and applies them across departments. Territory fields appear only when needed, keeping the common case short. The key decision: a rule's name becomes the reason tag on every account it recommends, so leaders see why an account was suggested, not just that it was.
Decisions with consequences in view - Leaders review hundreds of accounts. Instead of a flat search, the flow narrows: recommendations first, quick filters for common strategies, stackable filters for the rest. Each row shows revenue trend and target impact, so the tradeoff is visible before the decision. Recommended and manual picks stay separate, then merge into one summary that runs target, capacity, and exception checks.
Disagreement is data, not an error - When teams claim the same account, letting the first or latest request win would hide the disagreement. Instead, competing requests stay side by side until rMSO decides, grouped under the parent company for context. Bulk actions clear routine cases; only moving accounts to a new team requires a reason. Friction goes where the stakes are.
The takeaway - The real design work was deciding where each decision lives and making sure its reasoning reaches the next person. In a system with competing goals, the experience is only as good as the operating model underneath.
That groundwork is also what makes the system legible to AI. Once every recommendation carries its reason and every decision has a clear owner, the same structure can support agents that draft the plan and surface the tradeoffs — not just tools that display them.