New RevOps Role? 5 Things to Get Right First

You just started a new RevOps role. Congratulations. You're now responsible for a function that touches sales, marketing, customer success, and finance — and most likely, you've inherited a stack of half-built dashboards, a CRM with thousands of half-filled fields, and a forecast that no one fully trusts.

Your first instinct will be to fix things. That instinct is half right.

There's a lot of RevOps content on the internet that tells you to do nothing for 30 days — just listen, take notes, resist the urge to ship. That advice is well-meaning but overcorrects. The new RevOps leaders who land best in their first 90 days do two things in parallel: they knock out the obvious quick wins immediately — the broken routing rule, the misnamed deal stage, the report Sales has been asking for since January — and they hold the line on bigger structural work until they've done real discovery. The ones who fail usually fail one of those tests: they either freeze for a month and look like they're not doing anything, or they push a system-wide redesign in week three and lose credibility before they've understood what credibility means inside this particular company.

We talk to RevOps leaders every week at Finrite — most of them in the messy middle of a HubSpot or Salesforce stack feeding Stripe, Chargebee, or NetSuite. Here's the pattern we keep seeing in the ones who land well.

1. Run a Stakeholder Listening Tour Before You Touch the Stack

The most-repeated piece of advice from senior RevOps operators is some version of: do not make structural changes in your first month. That doesn't mean doing nothing — it means resisting the urge to redesign critical data models (e.g. deal stages) or make major new tooling suggestions. Listening comes first because almost every decision downstream of it gets better with context.

Book 30-minute conversations with every leader whose team you'll touch — CRO, VPs of Sales and Marketing, Head of CS, CFO, and ideally a few individual contributors who actually use the systems every day. In every conversation, ask three questions:

• What are you trying to achieve this quarter and this year?
• How do you measure whether you're achieving it?
• What do you think is currently in the way?

That's it. Resist the urge to diagnose. Take notes verbatim where you can. Pay attention to where stakeholders' answers contradict each other — those contradictions are the most valuable signal you'll collect all year. If Sales tells you the pipeline is healthy and Finance tells you the forecast is consistently off, that's not two opinions. That's a problem hiding in the data layer between them, and it's almost always where the highest-leverage RevOps work lives.

A few practical notes from people who do this well: keep good notes where you log what you observed, who said it, and what surprised you. By week three, patterns emerge that no individual conversation reveals. Make this a living artefact — it'll be an important part of what you achieve for the rest of the year.

2. Audit the Systems You've Inherited, Not Just the Dashboards

Once you have stakeholder context, turn to the systems. The mistake here is to start with the dashboards. Dashboards are downstream artifacts — they're as good or as bad as the data underneath them. If the underlying data is wrong, a beautiful dashboard just makes wrong information easier to share confidently.

Start with the CRM. For every object you care about — deals, opportunities, contacts, accounts — answer these questions:

• What fields exist, and how many are actually being filled in?
• Who updates each field, and how (manual entry, automation, integration)?
• Are field definitions consistent across teams? Does "MQL" mean the same thing to Marketing and to Sales? Does "deal stage" map cleanly to a real-world step in the sales process?
• What's the integration topology? What flows into the CRM (forms, enrichment, sales engagement tools), and what flows out (billing, finance, BI tools)?

Then do the same for the billing system. If you're in a sales-led SaaS company, this is often where the deepest data problems live — and where they're hardest to see, because Finance and RevOps frequently work from different sources of truth. We've watched companies discover, two months into a new RevOps hire, that the MRR number in their CRM and the MRR number in their billing system disagree by 10%+, and nobody could fully explain why.

The deliverable from this phase isn't a fix. It's a map. A clean document that shows: here's what we have, here's what's working, here's where the gaps are. That map is what makes every subsequent decision defensible.

3. Establish Trust in the Data Before You Ship Anything New

Here's a question worth sitting with: do the executives and reps in your company trust the data they're looking at?

If the answer is no, that's the single most important thing for you to fix, and you have to fix it before you build any new reporting on top. New dashboards built on distrusted data don't get used. New forecasts built on distrusted pipelines don't change behavior. New automations built on misaligned definitions just propagate the misalignment faster.

Building data trust is unglamorous work. It usually looks like this:

• Pick the two or three metrics that leadership actually steers the company by. Pipeline coverage, net new ARR, churn — whatever they discuss in the weekly business review.
• For each one, trace the number back to its source. Where does it come from? How is it calculated? Does the calculation match what people think it is?
• Publish a definitive version, with a written definition and a known refresh cadence. One number, one place, one definition.
• Quietly retire the four other dashboards that show different versions of the same metric.

When the CRO can walk into a meeting and say "the pipeline number is X, and I trust it," you've done more for the company than any tool rollout. That trust is also what buys you the political capital to do bigger things later.

4. Ship the Obvious Quick Wins Early, but be Hyper Targeted

By the end of your first couple of weeks you'll have a list of things that could be improved. Some of them are obvious — a routing rule that's clearly broken, a stale dashboard, a report that someone has been asking for forever. Ship those. Don't wait for the 30-day mark to put points on the board.

For anything that's structurally complex like redesigning the deal stages, consolidating CRMs or rebuilding the forecasting model, however, do the discovery work first. Anything that's a clean, contained fix you can complete in two to three weeks should go out the door as soon as you spot it.

A useful filter when triaging: quick wins are visible to leadership, pretty painful to your key stakeholders, but also small enough to fully complete in a short window without requiring and are ideally contained inside a single system. The moment a problem crosses systems (CRM to billing, marketing automation to CRM, CRM to data warehouse), it stops being quick. Cross-system work touches multiple owners, multiple data models, and multiple failure modes, and the resolution cycle is rarely short enough to ship in your first 60 days. Save those for the longer plan.

Examples we've seen work well in the first 60 days:

• Fixing a broken lead-routing rule
• De-duplicating the account and contact records that were never consolidated.
• Building the one report Sales has been asking for

Whatever you ship, do it visibly. Tell people what you're doing and why. When it lands, attribute the win to the team, not to yourself. The credibility you bank in this stretch is what funds the larger projects you actually want to do in months four through twelve.

5. Build a 30/60/90 Plan Anchored to What Leadership Measures

By the end of your first month, you should be ready to write a plan. Not before. A plan written before you've done discovery is just a guess dressed up in a Google Doc.

Three principles for the plan:

Tie every initiative to a metric leadership already cares about. If the CFO is anxious about forecast accuracy, your data hygiene work needs to be framed as "improving forecast accuracy from X% to Y% by Q3." Initiatives without an executive-stated outcome on the other end do not get prioritized in the budget cycle, no matter how technically right they are.

Sequence by dependency, not by urgency. The loudest problem is rarely the first one you should solve. If your pipeline numbers are wrong because your billing data is disconnected from your CRM, fixing the pipeline dashboard before fixing the underlying integration just gets you a prettier version of the same wrong number.

Plan past 90 days. The 30/60/90 framework is a useful default, but the real RevOps roadmap is 18 months long. Map out where you want the GTM data architecture to be a year from now — what systems, what integrations, what processes — and let the first 90 days be the foundation that the next 18 months stand on.

One more thing that doesn't fit neatly into the five steps but matters more than people admit: find a community. RevOps is one of the loneliest functions in a SaaS company — you're often a team of one, sitting between teams that don't fully understand what you do. RevGenius, RevOps Co-op, Pavilion, and similar communities are full of people who've been where you are. Get a mentor. Lurk in the Slack groups. The advice you get from someone three months ahead of you on a similar problem is worth more than any framework.

The Pattern

The new RevOps leaders who succeed have one thing in common: they understand that the job isn't about controls or dashboards or tools. It's about turning a chaotic system into one that people trust. Trust gets built through discovery, demonstrated through quick wins, and scaled through systems that don't lie to you.

Everything else is downstream of that.

Where Finrite fits in

The cross-system caveat in step 4 is worth lingering on, because it's the gap where most new RevOps leaders eventually get stuck. The single most common cross-system problem we see is the handoff between Contracts, the CRM and billing system. Deals close in HubSpot or Salesforce, and then someone (usually Finance or accounting, but sometimes reps) copies the details into Stripe by hand. Line items get mistyped, start dates slip, and by the time anyone notices, the MRR number in the CRM and the MRR number in Stripe disagree by enough to cause a headache at the next board meeting. It's exactly the kind of problem you can't ship a clean two-week fix for, which is why it tends to sit on the backlog quarter after quarter.

That's the problem Finrite was built to solve. We automate the contract-to-billing handoff. What's different about us is that we meet you where you are: no platform migration, no new system for your team to learn, just a clean bridge between the two systems you already use.

If you're new in a RevOps role and you're trying to figure out what your first quick wins should be, we're also happy to be a sounding board. We've watched dozens of new RevOps leaders walk this exact path — what to prioritize, what to leave for later, what's a one-system fix vs. what's a cross-system project hiding in a quick-win wrapper. Email us, book time, or just send us your list. We like talking to RevOps leaders.

Frequently Asked Questions

What should a new RevOps leader do in the first 30 days?

Listen. Run a stakeholder tour with the CRO, sales and marketing and CS leaders, and the CFO. Take verbatim notes. Resist the urge to redesign anything structural. The contradictions between teams are usually the most valuable signal you'll collect all year.

What's the biggest mistake new RevOps leaders make?

Two patterns. Freezing for a month and looking like they're doing nothing, or pushing a system-wide redesign in week three before they've earned the credibility to ship it. The best new leaders knock out obvious quick wins immediately while holding the line on structural work until discovery is done.

Should I rebuild dashboards or fix the underlying data first?

Fix the data. A beautiful dashboard built on distrusted data doesn't get used — and new automations built on misaligned definitions just propagate the misalignment faster. Build trust in the two or three metrics leadership actually steers by, then build new reporting on top.

What's a good RevOps quick win?

Visible to leadership, painful to your key stakeholders, contained inside a single system, and shippable in two to three weeks. Examples: fixing a broken lead-routing rule, deduplicating account and contact records, building the one report Sales has been asking for forever.

Related reading: why connectors are iceberg problems · what is CPQ? · the best HubSpot to Stripe connectors