Most B2B technology companies that decide to build a RevOps function make the same mistake. They hire a RevOps leader, give them a technology budget, and expect a functioning revenue operations infrastructure within 90 days. What they get is a well-intentioned person buying tools to solve problems that are fundamentally organizational, not technical.
Building a genuine RevOps function from scratch takes 6 to 12 months and requires organizational decisions before it requires technology decisions. This guide covers the sequence: what to do first, what to do second, and what to stop doing because it looks like RevOps but produces none of the outcomes.
Phase 1: Establish the Organizational Foundation (Month 1 to 2)
Before any system is configured or process is designed, three organizational decisions need to be made and communicated.
Decision 1: Where does RevOps report?
This is the most consequential decision in building a RevOps function and it is the one most organizations get wrong. If RevOps reports to the CRO, it becomes sales operations with a broader title. Sales ops needs the CRO to push marketing alignment, which produces the same misalignment problem with better tooling. If RevOps reports to the CMO, the dynamic inverts: marketing ops with a broader title. Sales alignment is driven through a CMO who has to negotiate with the CRO.
The organizational structure that produces genuine cross-functional RevOps is a VP of Revenue Operations or Head of RevOps who reports to the CEO or COO with dotted-line relationships to the CMO, CRO, and VP of Customer Success. That structure provides the authority to drive alignment without belonging to any single function's organizational hierarchy.
At companies below $50M ARR where a dedicated VP of RevOps is not yet justified, the equivalent is a RevOps function led by someone with explicit authority from the CEO to set shared data standards and shared pipeline definitions across all three commercial functions.
Decision 2: What is the scope?
Write down explicitly what RevOps owns and what it does not own. RevOps owns the data architecture, the process design for cross-functional handoffs, the shared reporting infrastructure, and the technology governance for the commercial stack. RevOps does not own campaign execution, sales quota, or customer success relationship management. Those remain with their respective functions.
Scope clarity prevents the two failure modes that most commonly end RevOps initiatives early: scope creep (RevOps tries to own everything and becomes a bottleneck) and scope collapse (RevOps becomes a reporting function with no operational authority).
Decision 3: What are the shared metrics?
Before building anything, agree on five metrics that all three commercial functions will be held accountable to together. Recommended starting set: marketing-sourced pipeline as a percentage of total pipeline, win rate on marketing-sourced pipeline, average time to close, net revenue retention, and expansion pipeline contribution from the existing customer base.
Get those five metrics agreed upon in writing by the CMO, CRO, and VP of Customer Success before the first RevOps system is configured. Every RevOps infrastructure decision that follows should be evaluated against whether it produces reliable data for one or more of those five metrics.
Phase 2: Data Foundation Audit (Month 2 to 3)
With organizational foundation in place, audit every data asset before building anything.
CRM audit. Pull the contact and account data quality report. Document the duplicate rate, the contact-to-account association completeness rate, the custom field population rates, and the pipeline stage distribution. Flag the data quality gaps that will produce inaccurate reporting if the RevOps infrastructure is built on top of them without remediation.
MAP audit. Review the MAP configuration: active workflows, lead scoring model, attribution field mapping to CRM, UTM taxonomy consistency. Identify where campaign data is being lost between MAP and CRM. Identify where the lead scoring model has not been validated against closed-won data.
CS platform audit. Review the customer health scoring methodology, the account data association between the CS platform and CRM, and the expansion signal data that CS is tracking. Identify whether expansion opportunities surfaced in the CS platform are visible to sales and whether marketing has visibility into customer adoption data for expansion programs.
Integration health assessment. For each point where two systems in the commercial stack should be exchanging data, test whether that exchange is actually happening correctly. MAP to CRM. CRM to CS platform. CS platform to CRM. Identify every integration gap where revenue-relevant data is not flowing between systems reliably.
The data foundation audit produces a prioritized remediation list. Work through that list before building any new RevOps process or configuring any new reporting. RevOps built on bad data produces confidently wrong revenue numbers.
Phase 3: Shared Definitions and Process Design (Month 3 to 5)
With clean data, design the processes that govern the cross-functional handoffs.
ICP definition workshop. Facilitate a structured session with marketing, sales, and CS leadership to produce a written ICP definition that all three functions agree to. The ICP should include firmographic criteria, technographic criteria, behavioral signals that indicate buying intent, and disqualifying signals that indicate a prospect or customer should not receive premium attention or resources. The workshop output is a single written document signed by all three functions.
Lead management process design. Design the full lead lifecycle from first marketing touch to SQL handoff and SQL to opportunity conversion. Document every stage with entry criteria, exit criteria, SLA, and the system workflow that enforces it. The output is a documented lead management process that is enforced in the MAP and CRM without relying on human memory or individual judgment.
Customer lifecycle process design. Design the customer lifecycle from contract signature through onboarding, adoption, renewal, and expansion. Document each stage with success criteria, CS ownership, marketing support touchpoints, and the expansion signals that trigger sales involvement. The output is a customer lifecycle playbook connected to the CS platform and CRM.
Handoff design. For every transition between functions, document the handoff criteria, the system workflow that executes it, the SLA that governs the response, and the metric that measures compliance. The output is a handoff documentation package that all three functions have reviewed and agreed to.
Phase 4: Technology and Reporting Infrastructure (Month 4 to 6)
With processes designed and data foundations clean, build the technology and reporting layer.
Attribution model implementation. Implement the multi-touch attribution model agreed upon during the organizational foundation phase. Configure UTM taxonomy enforcement across all channels. Build the marketing-sourced pipeline dashboard. Validate the attribution data against known closed-won deals before presenting it to leadership.
Forecast infrastructure. Build the CRM pipeline report and forecast methodology that the CRO and CEO will use for board-level revenue reporting. The forecast should be producible from CRM data without manual spreadsheet assembly.
Customer health dashboard. Build the customer health scoring model in the CS platform and connect it to CRM so that sales has visibility into health scores for their accounts. Build the dashboard that shows health score distribution, churn risk accounts, and expansion signal accounts.
RevOps performance reporting. Build the reporting that measures the RevOps function itself: the five shared metrics agreed upon in Phase 1, the lead management SLA compliance report, and the data quality metrics that measure whether the foundation is staying clean.
Phase 5: Enablement and Iteration (Month 6 to 12)
RevOps is not a project that completes. It is a function that iterates.
Enablement. Train every function on the shared definitions, the new processes, and the new reporting. The training is not about the technology. It is about why the process is designed the way it is, what the metrics mean, and how each function's work connects to the shared revenue outcomes.
Governance cadence. Establish a regular RevOps governance meeting with representatives from marketing, sales, and CS. The agenda covers the five shared metrics, the lead management SLA compliance report, any process design issues that have surfaced, and upcoming changes to the stack or the process that require cross-functional coordination.
Quarterly review and iteration. Every quarter, review the RevOps infrastructure against the shared metrics it was designed to produce. Where performance is below target, diagnose whether the issue is a data quality problem, a process design problem, or an accountability problem. Fix the root cause, not the symptom.
Frequently Asked Questions
How many people do you need to run a RevOps function? At $10M to $30M ARR, one strong RevOps manager plus one data/analytics resource is the minimum viable team. At $30M to $100M ARR, add dedicated marketing ops and sales ops specialization under the RevOps umbrella. Above $100M ARR, the RevOps function typically needs a VP of RevOps plus four to six specialists covering technology, data, analytics, and process design for each commercial function. Scaling the RevOps team below these thresholds produces a function that is perpetually behind on execution and never has time to do the strategic work that justifies the investment.
What technology does a RevOps function need? At minimum: a MAP and CRM that are properly integrated, a CS platform connected to CRM, and a BI or reporting tool that can pull data from all three. The most common RevOps technology mistakes are adding more technology before the existing stack is producing reliable data, and building custom integrations before evaluating whether native connectors between existing platforms can solve the same problem.
How do you build cross-functional alignment when the CMO and CRO have competing priorities? Shared metrics are the answer. When the CMO is accountable to win rate on marketing-sourced pipeline and the CRO is accountable to marketing-sourced pipeline as a percentage of total pipeline, their incentives become aligned rather than competing. Revenue leadership teams that resist shared metrics are usually protecting their ability to optimize for their own function's metrics at the expense of the revenue outcome. That resistance is an organizational problem that RevOps alone cannot solve without executive sponsorship.
What is the most common RevOps implementation failure? Technology before process. The organization buys a RevOps platform, configures it against existing broken processes, and produces automated broken processes. The right sequence is process design first, technology implementation second. A CRM configured to enforce a well-designed lead management process is RevOps. A CRM configured to automate a poorly designed lead management process is automation debt.
The Pedowitz Group has been building revenue marketing and revenue operations infrastructure for B2B technology companies since 2007. The RM6 diagnostic assesses your current RevOps maturity across 49 capabilities and identifies the specific gaps to close first. Talk to TPG.