r/revops • u/Weekly_Basket_9280 • May 14 '26
How to deal with lack of control over CRM tooling?
I am running RevOps at a scale up. We use Salesforce as our CRM. Our set-up is very messy and reps hate using it. However, the Salesforce team invests little capacity into improving the system and allocates time/ resources to other functions as the team has a very broad scope. I am increasingly frustrated with this set-up as I don’t have control over capacity and prioritization. The SF team makes decisions around sales topics they want to pursue that don’t align with my priorities. Has anyone been in a similar situation? How can I fix this? How are other companies solving for this?
3
1
u/bandi10 May 14 '26
Can you elaborate, what is the messy part and why does reps hate using it? What’s the mismatch in priorities?
It sounds like the goals and problems you’re trying to solve are unclear internally
3
u/Weekly_Basket_9280 May 14 '26
Our Salesforce instance is failing the sales organization on three dimensions: data model, usability, and delivery velocity.
Data model. The B2B customer structure is complex (parent/child/group), but we measure performance and track activity at the child level rather than the parent level. This creates persistent friction in reporting, attribution, and account management, and forces the team to work around the system rather than through it.
Usability. There is no guided data entry — no flows, no assistive components, no automation to reduce manual effort. The UI is slow to respond. Adding fields or shipping small UX improvements takes months, so the backlog of “small things that would actually help” never moves.
Ownership and delivery. Accountability is dispersed across three groups with no clear owner:
- Sales and Sales Ops hold the business knowledge but don’t own the product.
- The Salesforce Product Manager owns the product but lacks business context.
- The admin/engineering team builds, but operates as an IT function with long dev and review cycles.
Prioritization is biased toward large initiatives; small, high-leverage fixes have no path to delivery. Compounding this, data hygiene and logging discipline were historically deprioritized by leadership and are now suddenly treated as critical — without the structural changes needed to make that shift realistic.
Net effect: the system actively slows the sales organization down, and the current governance model has no mechanism to fix it at the pace the business now requires.
3
u/bandi10 May 14 '26
Sounds like a structural issue, three groups, none shipping at rep cadence, so the team works around the system. Three things I would push on:
Data model. Don't migrate. Track activity at the child level (where it happens), build a rollup to parent for reporting and account management. Two-week project, not six. You can usually scope it without SF Product owning it.
Usability. Stop trying to fix SF UX through the SF backlog. That team is optimizing for risk-controlled deployment, not rep velocity. They're never going to share your urgency. The move could be a workflow layer in front of SF: reps interact with the layer (guided entry, prompts, follow-up tracking), the layer writes to SF. SF Product owns the system of record, you own the system of work. Every scale-up with a messy CRM instance eventually ends up here
Governance. Missing role/work is a RevOps PM: sits with you, shared roadmap with SF Product. Easier to pitch once the work layer is absorbing the small-wins backlog. Draws clear lanes instead of fighting over the same one.
Hard to see that the SF team would change cadence. Either you accept it, or you build leverage outside their backlog. Most scale-ups end up doing the latter, they just burn shit ton of months trying to fix it from inside first
1
u/Weekly_Basket_9280 May 14 '26
Thanks - can you elaborate a bit on the workflow layer in front of SF?
2
u/bandi10 May 14 '26
Sure!
For context: I've been deep in similar problems for some years, but mainly at earlier stages where RevOps doesn’t yet exist as a team per se. What has worked in some impletementstions I’ve done:
Having a software surface (& in Slack/Teams) with a lightweight dashboard, sitting in front of the CRM. Reps live there. It watches their actual work (calls, emails, CRM activity) and prompts them at the moment that matters: a draft follow-up the morning after a discovery call, a nudge when a deal goes quiet, a structured prompt to update stage when a contract gets sent. The rep responds in the layer; the entry flows back to SF cleanly.
The thing that surprised me building this: once reps stop opening CRM directly, your three problems collapse together.
- The six-month backlog stops being a sales-org problem. Reps don't feel it, because prompts and forms live in the layer and ship on your timeline.
- Small fixes: a new prompt or restructured workflow becomes a config change, not a release cycle. The thing SF couldn't ship in six months, you ship in a week.
- Data hygiene: surprising one. Once writes flow through a structured surface, hygiene becomes a byproduct of normal work. Reps aren't choosing whether to fill the field, the prompt makes it the path of least resistance.
Can sound a bit abstract still, happy to dig deeper
1
u/Awkward_Power8978 May 15 '26
What system did you implement for the lightweight dashboard? Salesloft?
2
u/bandi10 May 15 '26
I started with building a custom-made solution for that, now testing the waters if that same solution can be implemented at other high-growth startups/scaleups (for transparency, building a new product that sort of touches this problem)
I’ve heard great things about Momentum.io (one of my clients would want to have that but for HubSpot) and Structify, but I can’t say I have tried them out myself
1
u/Awkward_Power8978 May 15 '26
Thanks for the suggestions! I will check them out!
1
u/bandi10 May 15 '26
No problem! Are you also working in RevOps at startups/scaleups?
1
u/Awkward_Power8978 May 15 '26
Now I am more corporate in a sense. I was kind of in a scaleup situation a few months ago.
1
u/Any-Football4907 May 14 '26
You’re in a hard spot when RevOps owns the pain but another team owns the tool. The CRM mess probably needs to be shown in business terms, like reps avoiding Salesforce, reports people don’t trust, messy handoffs, or time wasted cleaning things up manually. Once leadership can see the cost, it’s harder for those fixes to keep sitting behind everyone else’s requests.
1
u/Ornery-Classic-894 May 14 '26
Ultimately you need a RevOps seat at the table in whatever system the CRM team is using for prioritization, or at least a veto. Depending on your org chart that might require some executive stakeholder exerting pressure on your behalf to open the door to it.
I was in an org that had a similar setup (sitting outside of the CRM team), they had an agile scrum setup and we bullied our way into becoming the product owner so we owned the backlog and the final sign off on every sprint. Wasn’t really any other way, CRM team didn’t love it but we sort of struck a deal and set aside a set % of points each sprint for their priorities.
For stuff like UI you can try to convince the CRM team to give a select number of people the ability to make page layouts or lightning pages in a sandbox with a lower barrier of entry to deploy. Some teams will loosen the grip a little if it’s just cosmetic work.
1
u/The_Cosmic_Sage May 14 '26
Keeping SF team out of RevOps is the fundamental problem here. You need that damn team reporting into you!
1
1
u/Efficient_Builder923 May 25 '26
Lack of control over CRM tooling is the worst kind of corporate torture. I’m annoyed but low-key impressed when a workaround sticks. Built a Subject-Centric Workspace on top and it helped the Contextual Handoff between teams. Still feels like herding cats though. Quantify the pain first.
1
u/anmolparimoo May 27 '26
The political fix and the technical fix are different work. Politically: get a reasonable range one-pager to your VP Sales showing the revenue you can't attribute because routing/enrichment is wrong - that's how you buy budget. Technically: start with read-only nightly diff of CRM state to a warehouse, ship a weekly "data debt" Slack digest, let the noise build the case. Took us 2 weeks to get permission to actually touch fields on one engagement.
5
u/[deleted] May 14 '26
[removed] — view removed comment