First 90 Days in RevOps: A Practical Playbook for New Revenue Operators

The first 90 days in RevOps are not for rebuilding everything.

They are for learning how the revenue system actually works, finding the biggest sources of operating drag, stabilizing the riskiest handoffs, and earning enough trust to change the system deliberately.

New RevOps leaders often fail by moving too fast on tooling or dashboards. The better approach is diagnosis first, focused fixes second, roadmap third.

Use this playbook with the Revenue Operations Framework. The framework gives you the operating layers. The first 90 days tell you how to enter the system without creating more chaos.

Gartner's RevOps guide frames RevOps as an end-to-end model across people, process, and technology. That is exactly why the first 90 days should not start with a tool rebuild. The job is to understand how those layers actually behave inside the company.

Key operating facts

  • The first 90 days should diagnose the revenue system before changing it: records, meetings, handoffs, definitions, tools, and reporting trust.
  • The first month should map reality. The second month should stabilize the highest-risk workflows. The third month should convert evidence into a roadmap leaders can support.
  • Avoid major rebuilds too early unless a workflow is actively damaging revenue, customer handoff, forecast, or compliance.
  • The best 90-day output is not a long backlog. It is a short operating roadmap with clear tradeoffs, paused requests, and the first measurable fixes.

Before day one: get the mandate clear

Before starting, clarify three things with the hiring manager or executive sponsor:

  1. What problem was this role hired to solve?
  2. Which decisions can RevOps make without escalation?
  3. Which functions are in scope: marketing, sales, CS, finance, systems, or all of them?

If the answer is vague, your first deliverable is a RevOps Charter. Without a charter, the first 90 days will be pulled into reports, tickets, and urgent requests before the operating problem is understood.

Forrester's RevOps responsibilities model highlights the breadth of responsibilities across marketing, sales, partner, and customer success operations. A new RevOps leader needs to know which of those responsibilities are actually in scope.

The first 90-day scoreboard

Use a scoreboard to stay focused.

Area First 90-day evidence
Mandate Charter or decision-rights draft reviewed with sponsor
Lifecycle Current stages, owners, and handoffs mapped
Data Critical data-quality risks documented
Reporting Source-of-truth gaps and dashboard trust issues identified
Forecast Forecast packet, category, and inspection risks reviewed
Post-sale Closed-won handoff, renewal, and expansion visibility inspected
Roadmap Top priorities, paused requests, and governance cadence agreed

This scoreboard prevents the first 90 days from turning into a collection of ad hoc wins. Quick fixes are useful, but only if they support a clearer operating model.

Days 1 to 30: map reality

Your first month should answer one question: how does revenue actually move through this company?

Do not start with the official process deck. Start with records, meetings, and interviews.

Review:

  • Lead capture and routing
  • MQL and SQL definitions
  • Opportunity stage criteria
  • Forecast categories
  • Closed-won handoff
  • Renewal and expansion process
  • CRM field completeness
  • Dashboard definitions
  • Current operating meetings

Interview marketing, SDRs, AEs, sales managers, CS, finance, and executives. Ask where the system slows down, which reports are not trusted, and what work happens outside the CRM.

Compare what people say with what the data shows.

Interview questions to ask

Use interviews to find mismatches between official process and actual behavior.

Ask marketing:

  • Which sources create leads sales actually accepts?
  • Which qualification rules are debated most?
  • Which attribution reports are not trusted?

Ask sales:

  • Which lead types are easiest to work?
  • Which CRM fields feel useful, and which feel like theater?
  • Where do deals get stuck before forecast review?

Ask customer success:

  • What context is missing after closed-won?
  • Which promises create onboarding friction?
  • Which churn reasons should feed back into qualification?

Ask finance:

  • Which revenue numbers require manual reconciliation?
  • Which CRM fields affect planning confidence?
  • Which forecast assumptions are weakest?

The point is not to collect complaints. The point is to identify operating gaps that appear across multiple teams.

The first 30-day audit

Pull a small record sample:

Record type Sample size What to inspect
New leads 20 Source, routing, owner, SLA, next action
MQLs 20 Qualification reason, acceptance, rejection reason
Opportunities 20 Stage, amount, close date, next step, forecast category
Closed-won deals 10 Handoff fields, use case, success criteria
Renewal-risk customers 10 Health data, owner, risk reason, escalation path

This audit is usually more useful than a long interview loop. Real records reveal whether the system works when nobody is watching.

Deliverables by day 30:

  • Revenue lifecycle map
  • Source-of-truth map
  • Handoff inventory
  • Dashboard trust audit
  • Data quality baseline
  • List of shadow spreadsheets and manual workarounds

Days 31 to 60: stabilize the highest-risk handoffs

Do not try to fix every workflow.

Pick two or three handoffs where leakage is visible:

  • Lead assigned but not accepted
  • MQL accepted but not converted
  • Opportunity stage changed without evidence
  • Closed-won deal handed to CS without context
  • Renewal risk not escalated early enough

For each handoff, define:

  • Owner
  • Entry criteria
  • Required data
  • SLA
  • Escalation path
  • Dashboard view

The MQL to SQL Handoff Process and Closed-Won to Onboarded Handoff Process are useful patterns.

What to fix first

Choose handoffs by revenue risk, not political noise.

Symptom Likely first fix
Leads age without follow-up Lead assignment SLA and escalation
Sales rejects many MQLs Qualification definition and rejection reasons
Forecast calls are messy Stage criteria and close-date hygiene
CS lacks context Closed-won handoff fields
Finance distrusts CRM Source-of-truth and forecast category rules

The first fixes should be visible enough to build trust but narrow enough to finish.

How to avoid becoming a request queue

The middle 30 days are when a new RevOps leader is most likely to get buried.

People discover you can fix reports, fields, imports, automations, dashboards, routing rules, and process questions. Every request sounds reasonable. If you accept all of them, the role becomes a queue before it becomes a function.

Create three lanes:

Lane What goes here Response
Urgent breakage Broken routing, broken sync, forecast-blocking issue Fix immediately
Operating roadmap Handoffs, definitions, dashboards, governance Prioritize in roadmap
Local preference Nice-to-have field, view, or report Defer or reject

This is not about being unhelpful. It is about protecting capacity for the work RevOps was hired to do.

Days 61 to 90: build the operating roadmap

By month three, you should have enough evidence to propose a practical roadmap.

The roadmap should not be a giant systems wishlist. It should tie operating problems to revenue outcomes.

Problem Revenue risk 90-day fix
Leads age without acceptance Pipeline leakage SLA and reassignment rule
Stage criteria are vague Forecast miss Stage exit criteria and inspection
CS handoff is incomplete Onboarding risk Required closed-won handoff fields
Source data is inconsistent Attribution distrust Source field governance

Use the Revenue Operations Framework to organize the roadmap by process, data, systems, metrics, cadence, and governance.

What the 90-day roadmap should look like

The roadmap should be specific enough to fund and sequence.

Avoid broad items like "improve reporting" or "clean CRM." Write operating work:

  • Define MQL, SQL, opportunity, closed-won, onboarded, renewal, and expansion stages.
  • Add rejection reasons to MQL workflow and review monthly.
  • Create closed-won handoff required fields before onboarding kickoff.
  • Lock source fields and document attribution rules.
  • Build one executive dashboard with governed definitions.
  • Create monthly funnel review and forecast governance cadence.

Each roadmap item should have an owner, expected business impact, dependency, and target completion window.

What not to do in the first 90 days

Do not rebuild the CRM immediately. You may need to later, but a rebuild before diagnosis usually recreates the same process confusion in a cleaner interface.

Do not ship a dashboard no one can act on. Dashboards should support decisions. Start with the decisions leaders already need to make.

Do not accept every request. A new RevOps leader can become a ticket queue quickly. Separate urgent fixes from structural work.

Do not change definitions silently. Lifecycle and forecast definitions affect teams politically. Make changes visible and explain the operating reason.

Do not over-automate. Automation should enforce a clear workflow. If the rule is not agreed, automation will make the disagreement harder to inspect.

First 90-day deliverables

By the end of 90 days, produce:

  • Revenue lifecycle map
  • Handoff risk list
  • Data quality baseline
  • Dashboard trust audit
  • Systems ownership map
  • RevOps charter draft
  • 90-day improvement roadmap
  • Decision-rights proposal
  • First working revenue cadence

These deliverables create shared context. They also prevent RevOps from becoming a vague function that everyone supports in theory and ignores in practice.

How to communicate progress

Executives do not need a running list of every field cleaned or report adjusted.

Report progress in operating terms:

  • Which revenue leaks were found?
  • Which handoffs were stabilized?
  • Which data definitions are now governed?
  • Which reports are now trusted?
  • Which decisions can leaders make faster?
  • Which risks remain?

That is the difference between "RevOps is busy" and "RevOps is improving the revenue system."

First 90 days by company stage

The plan should adjust by stage.

Stage First 90-day emphasis
Early sales-led company Basic CRM hygiene, lead ownership, pipeline stages
Marketing plus sales engine MQL/SQL definitions, routing, source reporting
Sales plus CS motion Closed-won handoff, renewal visibility, customer health data
Multi-segment company Segment rules, dashboard splits, capacity and forecast model
Mature mid-market company Governance, change management, automation readiness

A first RevOps hire at a 40-person company should not spend 90 days building an enterprise governance model. A RevOps leader at a 400-person company should not spend 90 days only cleaning fields. Match the work to the operating complexity.

What to show executives at day 90

The day-90 readout should not be a list of tasks completed.

Use this structure:

  1. Current-state revenue system map.
  2. Top five revenue leaks found.
  3. Data quality baseline.
  4. Handoffs stabilized.
  5. Decisions made or pending.
  6. Risks that still need executive support.
  7. Next 90-day roadmap.

Keep the story practical. Leaders should leave knowing what the revenue system can now do, what still cannot be trusted, and which decisions require their help.

Common first-90-day mistakes

Over-indexing on tooling. Tools matter, but a new admin layout does not fix unclear lifecycle definitions.

Trying to satisfy every stakeholder. RevOps is cross-functional, but it cannot be a personal reporting team for every leader.

Avoiding political decisions. MQL definitions, forecast categories, and required fields are political because they change accountability. Avoiding those decisions keeps the system weak.

Skipping finance. Finance often knows which revenue data is not trusted. Bring finance into the audit early.

Under-communicating tradeoffs. If RevOps is deprioritizing a request to fix a larger system issue, explain the tradeoff. Silence looks like slow service.

How to decide what waits

Some work should wait until after the first 90 days:

  • Large CRM rebuilds
  • Full tech stack consolidation
  • Advanced attribution modeling
  • AI forecast scoring
  • Broad automation programs
  • Complex compensation redesign

Those projects may matter, but they depend on trusted definitions and current-state understanding. Starting them too early creates expensive rework.

Use the first 90 days to earn the right to do larger work. When leaders see that RevOps can diagnose the system, stabilize handoffs, and create trusted reporting, they are more likely to support the deeper roadmap.

The discipline is simple: fix the leaks that distort revenue decisions first. Then rebuild the larger architecture.

That sequencing also protects credibility. Teams are more willing to accept bigger process changes after they see RevOps solve visible operating pain in the current revenue workflow first, with evidence.

Trust compounds from there.

How to decide what waits takeaway

The first 90 days should create trust before scale. A new RevOps owner should inspect the real revenue system, stabilize the highest-risk handoffs, document decision rights, and build a roadmap leaders can support.

The goal is not a full rebuild. The goal is to prove that the company can run revenue work from shared evidence instead of recurring debate. Once that trust exists, larger systems, automation, attribution, and forecasting work become much easier to justify.

That is the real onboarding milestone.

If the company trusts the diagnosis and the first fixes, the next roadmap has a much better chance of adoption.

Weekly operating rhythm

The first 90 days should have a simple weekly rhythm. Without it, discovery turns into random stakeholder conversations and the new RevOps owner becomes reactive too early.

Week Main focus Output
1 Mandate, stakeholders, systems access Sponsor agreement and interview list
2 Lifecycle and record audit Current-state funnel map
3 Reporting and dashboard audit Source-of-truth risks and manual reporting list
4 Handoff audit Top broken handoffs with owners and evidence gaps
5 Quick fix selection One or two high-impact fixes approved
6 Handoff or data cleanup launch New rule, field, SLA, or review process
7 Forecast, pipeline, or funnel review redesign Cleaner review packet and decision owner
8 Systems governance draft Intake rules and change log
9 Roadmap build Prioritized operating backlog
10 Leadership review Decisions on scope, tradeoffs, and capacity
11 Finalize first-quarter assets Charter, lifecycle map, scorecard, and roadmap
12 Day-90 presentation What changed, what remains, and what needs authority

This rhythm gives the new owner a path without pretending every company has the same problem. The weekly outputs can change, but each week should create an artifact leaders can inspect.

Day-90 decision packet

The day-90 presentation should not be a long activity report.

It should answer five decisions:

  1. Which operating problem is costing the company the most?
  2. Which definitions or handoffs are now governed?
  3. Which metrics can leadership trust now?
  4. Which work requires executive tradeoff next quarter?
  5. Which requests should RevOps stop or defer?

If the presentation does not lead to decisions, the first 90 days stayed too descriptive. RevOps should leave day 90 with a clearer mandate, a ranked roadmap, and permission to protect the operating system from low-value work.

FAQ

What should a new RevOps leader do first?

Map the current revenue process and compare the official process to real records, reports, and team behavior. Do not start with tooling.

What is the best first RevOps win?

Fix a visible handoff that leaks revenue, such as lead assignment, MQL acceptance, or closed-won handoff completeness.

Should the first 90 days include a CRM cleanup?

Only enough cleanup to stabilize critical workflows. A broad CRM cleanup should follow field governance and process changes, or the data will decay again.

How much should RevOps change in the first 90 days?

Enough to stabilize obvious leakage and earn trust. Save major system redesign for after the audit and roadmap are accepted.

Learn more