Português

Common RevOps Pitfalls: 7 Walls You'll Hit at 6-18 Months (and How to Get Through Them)

You're past the new-hire honeymoon. The CRO knows your name. Your queue is full. But something feels off. Sales is annoyed about something you can't quite name. Your dashboards aren't getting opened. The VP keeps asking the same forecast question three QBRs in a row, and you keep giving an answer they don't quite trust.

Welcome to the wall. Every RevOps person hits it somewhere between month 6 and month 18. The work that got you hired (cleaning up obvious messes, shipping the first quick wins) doesn't carry you to Senior. The next gear is different, and nobody hands you the playbook.

So here it is. Seven walls, in the order they usually show up, with the symptom, the actual number that proves it's happening, and what to do this week.

Pitfall 1: Building Salesforce Reports Nobody Reads

Symptom. You ship a dashboard. The VP gives you a thumbs-up emoji in Slack. You feel good for about 48 hours. Then you check the view count and it's flatlined at 3: you, your manager, and the auto-refresh job.

The real number. Run a Lightning Usage report (or whatever your CRM equivalent is) and pull view counts on every dashboard you've built in the last 90 days. The honest cutoff: under 5 unique viewers per month after week 2 means it's dead. Most ops-built dashboards land there. I've audited orgs with 80+ dashboards where the top 5 accounted for 92% of all views.

What to actually say. Next time someone says "can you build me a dashboard for X," ask: "Walk me through the meeting where you'd open it. Who else is in the room? What decision changes based on what it says?" If they can't answer in 30 seconds, the dashboard doesn't exist yet because the decision doesn't exist yet.

The fix. Stop building until someone asks twice. The first ask is a vibe. The second ask, two weeks later, is a real need. Replace 3 unread reports with 1 weekly Slack digest tied to a specific decision: "Pipeline coverage is 2.8x going into Q3, we need it at 3.5x, here are the 4 segments where we're short." That gets read. That gets forwarded. That gets you in the QBR slide.

Pitfall 2: Over-Customizing the CRM (Technical Debt Compounds Fast)

Symptom. Open the Opportunity object in your Salesforce or HubSpot setup. Count the custom fields. If your gut reaction is "yikes," you already know. There are 47 custom fields, 12 record types, and a validation rule from 2024 nobody remembers writing or asking for.

The real number. Two cutoffs. If you have more than 30 custom fields per object, you're in debt. If more than 15% of those fields have under 5% usage across records, you're servicing the debt instead of paying it down. Pull a field-utilization report (Salesforce Optimizer does this for free; HubSpot has Field Insights). The number tells you everything.

Why it matters. Every dead field is a tax on every report, every page layout, every new rep's onboarding, and every integration that has to map the schema. A bloated CRM doesn't just feel slow — it's the reason your forecast model can't trust the data going in.

The fix. Quarterly field-cleanup ritual. Pull the utilization report. Anything under 10% record usage that hasn't been edited in 90 days goes on the kill list. Announce it in #revops-changes for two weeks. Deactivate, don't delete, and document the deprecation in a running CHANGELOG you keep in a shared Confluence page. After three quarters of this, the org gets cleaner instead of dirtier, which by itself puts you ahead of 80% of RevOps people.

Pitfall 3: Skipping the Kill Ceremony for Dead Automations

Symptom. Process Builders, Flows, Workato recipes, and Zaps from 2023 still firing on every record. You opened one yesterday and the description field said "TODO: write description." Nobody knows what half of them do. Nobody wants to turn them off because nobody wants to be the one who breaks something.

The real number. Count active flows in your org. Then count flows that have been touched (edited, debugged, or even opened) in the last 90 days. The gap is usually 40-60%. That's your dead-automation surface area, and every one of them is a future Sev 1 incident waiting for the right edge case.

Why it's hard. Killing automations feels riskier than building them. Build = visible win. Kill = invisible win unless something breaks, in which case it's a visible loss. So the org accumulates flows the way a hard drive accumulates files.

The fix. Monthly kill list review, on the calendar, treated like a real meeting. Three rules:

  1. No active owner (person no longer at the company, no replacement assigned) → kill candidate.
  2. No edits in 12 months AND no documentation → kill candidate.
  3. Logs show <1 execution per month → kill candidate.

Deactivate first, don't delete. Wait 30 days. If nobody screams, delete and write the funeral in your CHANGELOG: what it did, why it died, what replaced it (if anything). The funeral is the point. It teaches the org that killing things is normal, which is how you stop the bloat at the root.

Pitfall 4: Chasing Forecast Accuracy Without Fixing Pipeline Hygiene

Symptom. The CRO wants ±5% forecast accuracy. You're building weighted-pipeline models, layering in rep-call sentiment, maybe even piloting an AI forecast tool. Meanwhile, 38% of open opps in the system have a close date in the past. You're solving the wrong problem.

The real number. Pull the percentage of open pipeline where close date is more than 14 days past today. Healthy orgs sit under 10%. Unhealthy orgs sit at 30-45%. A forecast model fed by stale dates is a calculator with random inputs, and no amount of model sophistication will save it.

The honest conversation with the CRO. "We can't hit ±5% accuracy on a pipeline where 38% of opps are stale. The math literally won't work. Give me 6 weeks on hygiene, then 6 weeks on the model. If we skip the hygiene step, we'll just be wrong more confidently."

The fix. Hygiene first, model second. Ship a weekly stale-data report tied to rep scorecards: stale opp count, stale opp $ value, days since last activity. Make it visible in the sales leadership channel. Tie it to forecast call accountability — if a rep commits an opp and the close date is 3 weeks past, that opp can't be in commit. Once stale-rate drops under 12%, then talk about models. Pipeline coverage you trust beats forecast methodology you don't.

Pitfall 5: Becoming the "Ticket-Taker" Instead of the Strategist

Symptom. You open Jira on Monday. Forty-three tickets. "Add picklist value." "New report for region 4." "Fix typo in stage definition." It's now Friday. You've shipped 41 of them. You haven't moved a real project forward in six weeks. You're exhausted and somehow also embarrassed.

The real number. Track your time for two weeks (Toggl, Clockify, even a spreadsheet works). If under 20% goes to project work and over 80% goes to tickets, you've been absorbed. You're not RevOps anymore, you're CRM helpdesk. The career impact is brutal: Senior RevOps roles get filled by people who shipped projects, not people who closed tickets.

Why it happens. Tickets feel productive. Each one closes with a green checkmark. They're also infinite, because every team treats RevOps as their personal admin once one person says yes to one thing.

The fix. Office hours model. Block your calendar. Tickets get triaged twice a week, in two 2-hour windows (say Tuesday 1-3pm and Thursday 1-3pm). Outside those windows, the queue is closed unless something is genuinely on fire (production-down, comp-impacting, deal-blocking). Protect 2 full days for project work. Tell your manager exactly this: "If I want to ship the territory model and the forecast rebuild this quarter, I need 2 protected days a week. Here's what won't get shipped if I don't get them."

The first week feels uncomfortable. The fourth week, the org adapts. The eighth week, the requesters start solving 30% of their own tickets because the friction made them think first. That's the whole point.

Pitfall 6: Re-Cutting Territories Too Quickly

Symptom. You re-cut territories in Q2 because "the data said so." Reps revolt. Three top performers threaten to leave. The CRO walks the change back in Q3. You've now spent six months running a change that produced negative pipeline and burned political capital you can't easily earn back.

The real number. Internal benchmarks across mid-market sales orgs put it at 15-25% pipeline-coverage destruction during a territory transition, recovered over 6-9 months if the cut was good and 12+ months if it was bad. That cost is invisible on a spreadsheet but catastrophic on a board deck.

Why it happens. RevOps people see imbalance in the data (Rep A has 2.3x the named accounts of Rep B), and the optimization brain says "fix it." The optimization brain forgets that territories are also relationships, ongoing conversations, half-closed deals, and a rep's mental model of who they're working. You're not just moving accounts on a spreadsheet, you're cutting through ten months of context.

The fix. Three rules.

  1. Twelve-month minimum between meaningful re-cuts. If you need to re-cut more often, the underlying segmentation logic is wrong, not the territories.
  2. Pilot before global rollout. Test the new logic on one segment (one geo, one industry vertical) for a full quarter. Measure pipeline coverage, deal velocity, and rep satisfaction before propagating.
  3. Reps in the room. Run the proposed cut by the top 3 reps in each segment before locking it. They'll catch the "Account X is in active negotiation, do not move" issues a spreadsheet won't see.

A slower territory plan that holds for 18 months beats a fast one that gets walked back in 6.

Pitfall 7: Not Partnering With Finance on Attribution

Symptom. Marketing claims they sourced 60% of pipeline. Finance closes the books and reports 22%. CRO is in a board meeting trying to explain both numbers. You're the person who has to walk in and clean up. Both Marketing and Finance are technically "right" because they're using different definitions, different date ranges, and different attribution windows.

The real number. If your CRM's sourced-pipeline number doesn't reconcile to Finance's bookings within 10%, you have a credibility problem and you don't yet know it. The board does, though, and it shows up as "we don't trust the marketing number" in conversations you're not in.

Why this matters more than it looks. Attribution disagreements are a stand-in for trust between Marketing and Finance, and RevOps sits exactly in the middle. The RevOps person who fixes this becomes the most-trusted operator in the company within a quarter, because every executive in the building has been silently annoyed about it for years.

The fix. Monthly attribution sync with FP&A. One hour, on the calendar, ruthless. The agenda is always the same:

  1. Reconcile last month's sourced-pipeline number to bookings. Show the math.
  2. Lock the definitions for the upcoming month: what counts as marketing-sourced, what counts as influenced, what date range, what attribution window.
  3. Sign off on the QBR slide together. Same number, same definitions, both sides on the page before either side sees the CRO.

Within two cycles, the gap shrinks from 38% to 8%. Within three cycles, Finance starts copying you on board prep. That's the moment you stop being a RevOps Manager and start being a Director-track operator.

What These Walls Are Actually Telling You

Hitting these walls doesn't mean you're bad at the job. It means you've been around long enough to see the shape of the role.

The first six months reward people who can ship: clean the obvious mess, build the obvious dashboards, close the obvious tickets. The next twelve months reward people who can choose: choose what not to build, what to kill, what conversations to lead, what number to defend in a room with the CRO and the CFO.

The ones who break through stop optimizing for activity and start optimizing for the two questions a CRO actually asks: "What's the number going to be?" and "What changed?" Every dashboard, every flow, every territory cut, every attribution argument either helps you answer those two questions or it doesn't. If it doesn't, it's noise, and the queue is full of noise.

Pick the wall you're closest to right now. Run the diagnostic this week. Ship the fix next week. Then come back and read the next one.

Learn More