Global SBS CRM Analytics dashboard - 400K opportunities tracked, hundreds of daily users.

01The headline

The Scaled Business Solutions team at Indeed shifted to a new opportunity-measurement model mid-2025: new targets, new Gong Call goals, new business logic. The dashboard the team relied on every day didn't reflect any of it. I led the rebuild end-to-end - 400K opportunities tracked per quarter, with the ~30K that convert to clients visible in the same view. Used daily by hundreds of users across SBS, GTM, and Support. One quarter from spec to launch.

02Context & constraints

The SBS team supports Indeed's largest book of clients. In 2025 they transitioned to a new opportunity-measurement workflow - new fields, new calculations, and a target on Gong Calls. The existing dashboard the team used daily didn't model any of it.

A few constraints shaped the build:

• The numbers had to be exactly right. Reps were scored on what the dashboard showed. A bug in the calculation was a bug in someone's quarterly review. Higher accuracy bar than a typical reporting dashboard.
• One quarter, hard deadline. The team needed the new view in production before the next quarterly planning cycle. Slip the deadline and reps spend a quarter without working numbers.
• New business logic. The opportunity-measurement model was new across the org. I had to learn the rules before I could code them.
• Data lived in AWS, not just Salesforce. Some of the goaled metrics came from AWS-hosted tables outside the Salesforce object model. The dashboard had to read both and reconcile them. I queried AWS directly to validate numbers against the source-of-truth tables before they landed in production.

03The decision

I built the project around a scored requirements sheet and held the line on it.

Every potential feature got two ratings: how badly does the team need this, and can we build it in one quarter. The intersection of high-need and feasible-in-Q became the v1 cut. Everything else either pushed to v2 or got dropped. Once the must-haves were in production, I worked through the nice-to-haves as time allowed - by launch, the v1 had every essential goaled metric plus several quality-of-life additions stakeholders had asked for.

04Process

Four phases, roughly:

• Phase 1: requirements and scope. Set the project meeting cadence, documented every requirement, and scored each one for need + feasibility. Closed the list with stakeholder sign-off.
• Phase 2: alignment and timeline. Met with Data Engineering (the source owners) and the SBS stakeholders separately. Walked each side through what was in scope and what wasn't, then set realistic timelines for each piece.
• Phase 3: build, test, iterate. Initial build, presentation to stakeholders, review, changes. Then testing with the SBS team before launch. Caught a handful of calculation issues here - the kind that would have been embarrassing in front of reps who saw their own number on the dashboard.
• Phase 4: launch + fast-follows. Pushed live in production. Worked through the post-deadline requirements as individual tickets, prioritized by which reps were missing what.

Almost killed it: scope creep. After requirements closed, stakeholders kept proposing additions, and most of the proposals were legitimately useful, which made them harder to refuse. The fix was structural - I drew a hard "requirements closed" line at the end of week 2, set the expectation up front that anything after that became a fast-follow, and stuck to it even when the late asks were good ones.

05Results

The dashboard surfaces every opportunity in the SBS book - around 400K per quarter - and the ~30K that convert to clients within the same view. Reps use it daily to track their own pipeline against the new goaled targets; managers use the same view for coaching conversations. The cumulative-DAU chart on the work-index card shows adoption climbing through the first months post-launch.

06Tradeoffs & what I'd do differently

• Would do again - lock requirements before anything else. The first two weeks went entirely into the scored requirements sheet before a single calculation got written. It felt slow at the time. It's the reason the project shipped on time. Same call without question.

• Would revisit - the testing window. I budgeted enough testing time for the must-haves but not for the volume of late-add fast-follows that piled up between launch and the start of the next quarter. The first wave of post-launch bug reports was avoidable with another week of structured pre-launch testing. Next time I'd budget for the bug-finding scrum at the end of the build, not just the build itself.

• Would do differently - close requirements harder. I drew a hard "requirements closed" line and stuck to it, but stakeholders kept floating new items in the gray area between "fast-follow" and "must-have." Next time I'd be more explicit at the kickoff about what becomes a fast-follow versus what gets dropped entirely - the ambiguity is what lets requests sneak back in even after a hard close date.

07Artifacts