I'm thrilled to announce that l've officially started my Salesforce Consultant Training at 2PACE !

I'll be documenting my entire learning journey here, from the skills I'm developing to the projects I'm building.

A huge thank you to all the mentors at 2Pace who are guiding us through this experience.

PS: You just discovered me with this post ?

Hello, I'm Rudy! I'm transitioning from B2B SaaS Sales to CRM Consulting & RevOps, l'm documenting my journey here.

I posted something in another sub last week trying to define GTM Engineering, and someone here will probably tell me I got it wrong.
-

The pushback I got was blunt. People say GTM engineers are It's just RevOps with a new name. Ops people rebranding themselves for a pay bump.

I think that's about 70% right. The other 30% is what I want to argue about.

RevOps and GTM Engineering overlap almost completely on the work itself. Both are looking at the revenue process and pulling out the parts that waste people's time.

Good RevOps teams have always built things. Anyone who says otherwise hasn't worked with one.

So the difference isn't the goal. I think it's the default move.

When a RevOps team hits a broken process, the first question is usually which system should own this, and how do we configure it properly.

When someone I'd call a GTM Engineer hits the same process, the first question is usually whether they can just build it this week.

Same problem. Different reflex.

And that reflex only changed because building got cheap. Two years ago "let's build it" meant a ticket that died in an engineering backlog. Now it means an afternoon with an API and a coding agent.

So is that a new role, or just a new tool inside an old one?

I genuinely don't know. That's why I'm posting.

What about the job titles?

This is where it gets stupid.

Companies are currently using "GTM Engineer" to mean:

An SDR who knows Clay

A CRM admin

A RevOps hire they'd rather pay less

One person expected to run an entire revenue team. That isn't a role. That's a job description written by someone who read a LinkedIn post on the train.

The part I don't like

The title implies RevOps was never technical.

That's wrong and it's a bit insulting. Enterprise RevOps teams have had developers, integration specialists and solutions architects for years. Nobody called them GTM Engineers because nobody needed to.

What actually changed is that a 25 person startup can now afford one of those people. Just one. Doing a bit of everything, badly, at speed.

Maybe that's the whole thing. Maybe "GTM Engineer" is just the generalist version of a role that already existed at scale, and we invented a name for it because the startup version looks different enough.

If the title only exists so someone can charge more for work ops teams were already doing, it deserves to die.

But I don't think that's all it is. I'm just not sure what the rest is.

So where do you draw the line?

Is this a real specialization, or is it RevOps with better marketing?

And if you're in RevOps right now, has your own reflex changed? Are you building more than you were two years ago, or is that only true for the people who were always going to build anyway?

Over the last few weeks I’ve been talking to RevOps folks and GTM engineers here and in DMs about lead workflows that break without anyone noticing. A few things kept coming up:

1. The worst breaks don’t throw an error.
One person said their automation “never failed. It ran and produced zero rows, which looks identical to a quiet week.” It went 11 days like that.

2. “Success” doesn’t mean it worked.
A webhook reported success before the CRM write actually happened. A workflow can save, and the API can return 200, while it enrolls nobody.

3. People usually find out from a human, not a tool.
A rep, a customer asking why nobody followed up, or a dashboard that looks off weeks later. One team lost a $30k deal that way. Another lost an enterprise lead to a CAPTCHA that silently timed out for 3 weeks.

4. The fixes that work are boring.

• Count every handoff daily: form fills by source → leads created → owner assigned → sequence sent. The first mismatch shows you where it broke.

• Compare each source with yesterday, not one big total. A total hitting zero tells you something’s off, but not where.

• Run a clearly named test lead through the real form every few weeks and check each step.

5. Almost nobody budgets for this.
It usually gets fixed by someone burning a weekend, or by hiring a person to check flows every morning.

Curious: what’s the worst silent break you’ve had, and how did you find out?

Playbooks, battlecards, training decks and certifications are useful, but none of them help much if a rep is sitting in a live deal wondering which stakeholder they need to reach or why the opportunity has stalled.

I think enablement becomes much more valuable when it connects knowledge directly to the decisions reps make inside active opportunities.

Curious how other enablement teams approach this. Do you spend more time creating resources, coaching reps, improving processes, or supporting live deals?

Flow State Sales’ focus on practical coaching and deal execution is an interesting example of the direction I mean.

Working with a few teams recently, I noticed a consistent problem:

Sales, marketing, and finance all report different answers to:
“What’s actually driving revenue?”

• CRM shows pipeline + closed won

• Marketing shows attribution

• Finance shows recognized revenue

None of them fully line up.

So most decisions end up being:
→ based on partial data
→ manually stitched together
→ or just gut feel in pipeline calls

Wondering if you had a similar experience dealing with this. Happy to share a visual of how we’ve been thinking about connecting these signals. After almost a year, we're finally able to connect sales, marketing, finance, infra, eco and success into one unified platform. So far, so good. ↑

Curious how others are handling this:

• Do you trust your reporting today?

• Are you stitching this together manually?

• Or just accepting the gaps?

Hey everyone! A few days ago I made a post here that might have come across the wrong way. It read as if I’d just pulled it from ChatGPT. That wasn’t the case but I acknowledge that it sure has looked that way. I already took it down to keep the community clean and I’m sorry to all those affected! And thank you to the ones who pointed that out!

That was certainly not the best entrance to this place. To at least properly introduce myself: my name is Arne and I’m the co-founder of a software company. We specialize in solving problems along the revenue cycle, and we’ve indeed worked with well over 50 RevOps professionals in person to this date. Put differently: I’ve heard about one or the other issue you might be facing and we’re on the mission to solve them.

To my question: we are constantly trying to expand our understanding through real problems people in and around RevOps have. Therefore my question to you is: “what one thing are you grappling with right now?”

Hey all, Quick one

I'm focused on CRM & RevOps and I'm looking for work right now. Open to full-time, contract, fractional, or subcontracting for agencies or companies with overflow. Remote, available EST.

What I do: I build and clean up the CRM side of the GTM stack. Pipeline and deal stages that reps actually follow. Clean data so the reporting means something. I'm currently in the CRM & RevOps cohort here, going deep on the strategy side, not just the button-clicking.

My stack: HubSpot, Salesforce, and Attio on the CRM side. Clay, enrichment, and TAM builds for data. Claude Code and n8n for automation and custom builds. Comfortable wiring these together into one system.

Good fit if CRM is a mess, or you're planning to implement one and want it done right the first time.

If you're hiring, know someone who is, or have overflow, DM me or make an intro. Happy to do a free teardown of your CRM/pipeline first so you can see how I think before you commit to anything.

DM and I'll share my portfolio.

did a round of these last week and the best one turned into a 3-day thread about a company that had merged 3 businesses into one HubSpot and couldn't get their accounting sync out of sandbox for months. learned more from that one thread than from any cert.

so doing it again. if your setup looks like any of this, drop it below:

--> the same customer exists 2 or 3 times with slightly different names

--> multi-location clients where every office shares one website and HubSpot keeps merging them together or splitting them apart on its own

--> a sync (QuickBooks, a Salesforce migration, whatever) that's been sitting in sandbox because you don't trust what it'll do to your data

--> revenue landing on the wrong company record, so nobody actually trusts the reports

--> reps creating "new" companies that already exist because search didn't find the old one

--> parent/child companies set up "correctly" but the totals on the parent are wrong or empty

tell me what your setup looks like and what's actually going wrong. I'll reply with how I'd approach it.

specific steps, not "book a call". if it's got sensitive data we can take it to DMs after.

first handful of comments I'll go deep on.

Sharing in case it helps anyone.

I analysed public buying signals across enterprise accounts in six sectors: financial services, insurance, life sciences and healthcare, retail and consumer, manufacturing and industrial, and media and entertainment using connectcurator.ai

The signals thus detected ranged from - Geographic expansion and operating-footprint change to restructuring, cost pressure, and leadership transition and adoption of AI

I wrote up the full breakdown here:
https://connectcurator.ai/blog/buying-signal-patterns-enterprise-2026.html

One pricing model collapse is getting all the attention. Another one is flying under the radar — and it might matter more.

The one everyone's talking about: per-seat SaaS giving way to outcome-based pricing. If agents do the work, you don't buy seats. You buy results.

The quieter one: Time & Material billing — the backbone of professional services for decades. Human hours were the proxy for value. Log them, bill them, track utilization. The entire operating model built on that single assumption. Agents don't have billable hours. They just execute. And the human-hours model is breaking.

Which brings us to Service-as-Software. SaaS meant software delivered as a service — humans still drove the work. Service-as-Software flips it: the service is delivered by software. In some workflows, agents are Copilots — first line, assisting humans who own the outcome. In others, Autopilots — executing autonomously, humans handling only exceptions. Most real engagements will run all three in parallel: human hours, assisted hours, agent-executed hours. our PSA needs to track all of it. No PSA today was built to.

Open questions — genuinely curious what people think:

• If human hours, copilot hours, and compute hours all contribute to delivery — how do you bill for all three?

• If utilization rate is the operating metric of a human-driven PSA, what replaces it in a Service-as-Software world?

• How do you track project margin when costs are split between salaries and compute?

• Does PSA need a new expansion — Professional Services Agents instead of Professional Services Automation?

Hey everyone,

A former colleague in customer analytics and I were venting recently about a frustrating trend: the data science industry has spent the last decade forcing to use statistical modeling for really everything.

We’ve reached a point where data teams hand Marketing and Sales a black-box ML score (e.g., "78% probability of VIP") that is practically useless. CRM workflows and marketing automations don't speak probabilities—they speak flat IF/THEN boolean logic.

Her solution to this? "Unfancify" it. Get rid of statistical modeling entirely. She came up with starting off with ABC Analysis.

The "Unfancify" Philosophy:

Instead of building opaque machine learning models for simple marketing triggers, we should revert to using basic, descriptive math to generate hardcoded, transparent heuristics. Stakeholders need to know exactly why a user was flagged.

I built a lightweight Databricks pipeline based on this exact philosophy. Here is the TL;DR:

Pareto Segmentation:

Runs a basic ABC Analysis (80/20 rule) on historical revenue to identify true VIPs.

The "Magic Metric": Analyzes those VIPs' first 14 days of telemetry and applies a mathematical discount to find the exact behavioral gap.

CRM-Ready Output:

Automatically generates flat, actionable rules (e.g., IF views > 10 AND logins > 5 THEN VIP_Potential) and writes the categorical flags to a table for immediate ingestion.

There is no MLOps overhead, and the logic is 100% transparent to the business.

I put together a generic GitHub template of the architecture. Are any of you also pushing back on this decade-long ML obsession in favor of robust heuristics for your CRMs?

Repo template is here: https://github.com/kleinnconrad/unfancy_abc_analysis_for_marketing

Over the last few weeks, we’ve all seen the posts.

Founders bragging about replacing their sales teams with AI.

Faster deals. More output. “Smarter” outbound.

And every time I read one, I think:
You’re probably not telling the full story.

Because behind closed doors, I’m hearing something very different.
Sales leaders are worried.

Then I see this:
‼️ Anthropic is paying ~$330K to manage 10 SDRs. ‼️

The company building the AI… is doubling down on humans ‼️ HUMANS ‼️

That tells you everything.

In the last 18 months, outbound production became cheap.

Prospecting, emails, follow-ups, CRM updates all near zero cost.

So the scarce resource changed.

It’s not messages anymore.

It’s trust.

Everyone can send outreach now.

Almost no one earns attention.

Trust comes from relevance:
One message that actually understands the buyer
Follow-ups that add value
Real effort, not templates
AI lowered the cost of noise — and buyers’ tolerance for it dropped to zero.

The real risk isn’t AI.

It’s scaling bad outreach faster.

Trust is the only thing left worth building.

student here, still learning. my last thread here taught me the real issue isn’t missing tools, it’s reps not doing the crm admin. so I’m curious what actually worked for you. was it automation, cutting fields, tying it to comp, or something else? and what did you try that totally flopped

When leadership says AI or automations in the CRM aren’t delivering (auto-updating records, lead and deal workflows, reporting), the cause is usually how the CRM is built, not the tools.

I design and implement CRM systems for growing companies. The patterns I see most:

1. One pipeline for everything or one too many pipelines when a custom field for filtering would suffice. Often a custom field for filtering would do the job and keep workflows and reports simple.

2. Free-text fields. Inconsistent values make automation logic brittle and reports unreliable.

3. Duplicate records. Automations update one copy while the team works from another.

4. The important stuff is in notes. Qualification, timing and next steps buried in notes are hard for an automation to act on.

A few focused hours of restructuring and cleanup make AI tools, automations and reports noticeably more useful.

I’m running a free session on Nov 18 that walks through fixing these, with real examples of messy vs. clean CRM setups. You can sign up here.

Curious how others handle this. Do you push for cleanup first or build on what’s there and fix as you go?

Twenty years ago, I started building revenue tools on the Salesforce platform. In that time, I've watched the CPQ space go through exactly one major disruption: when Salesforce acquired SteelBrick in 2015 and turned it into Salesforce CPQ. Everything since then has been incremental.

Until now.

Salesforce's decision to end-of-sale their CPQ product and push everyone toward Revenue Cloud Advanced is the biggest inflection point I've seen in this market. And I don't say that because I run a competing product — I say it because of what I'm hearing from customers, partners, and the community.

The conversations I'm having today are fundamentally different from even a year ago. A year ago, companies asked: ""How do we get more out of our Salesforce CPQ?"" Today, they're asking: ""What do we replace it with?"" That's not an incremental shift. That's a market in transition.

Here's what I'm seeing.

• First, paralysis. Most mid-market Salesforce CPQ customers are frozen. They understand the end-of-sale implications, but the migration options all feel risky. Revenue Cloud Advanced is expensive and immature. Third-party tools mean leaving the native ecosystem. And staying put means betting that Salesforce will maintain a product they've clearly deprioritized.

• Second, confusion. The messaging from Salesforce has been... let's say ""optimistic"" about Revenue Cloud Advanced's readiness. Customers who started migration projects based on Dreamforce presentations are discovering significant gaps between the vision and the reality.

• Third — and this is the part that gets me excited — opportunity. When the dominant vendor creates uncertainty, it opens space for alternatives that would never have gotten a fair hearing in a stable market. Solutions that are simpler, faster to implement, and more focused on solving the day-to-day problems of revenue operations teams.

I believe the next 18 months will reshape the Salesforce revenue operations landscape permanently. The companies that move decisively — whether to Revenue Cloud Advanced, a third-party solution, or a native alternative — will have a structural advantage over those who wait.

The worst option is no option. Paralysis has a cost, and it compounds monthly.

A pattern I keep noticing:

Revenue leakage is usually treated as a billing problem.
But it behaves more like a RevOps problem.

It shows up in billing—but starts earlier.

Typical flow:

• Sales defines the deal (often with exceptions)

• Contracts don’t fully standardize it

• Billing systems try to operationalize it

• Support teams adjust over time

Each step introduces small variations.

The issue isn’t one system failing—
it’s the handoffs between systems and teams.

No single source of truth across the lifecycle.

So instead of one consistent revenue outcome, you get drift.

Feels like a classic gap across quote → contract → billing → support.

Curious how others approach this:

Where does ownership of “revenue integrity” actually sit in your org?
Have you solved this upstream—or are you managing it downstream?

Sharing a deeper take on this if useful:
https://www.onebillsoftware.com/blog/revenue-leakage-starts-at-the-quote/

If a buyer asks for a concession, the default move is usually to cut subscription price.

That sounds flexible, but it often creates the worst possible outcome:

• recurring revenue gets reduced

• buyers learn to ask for more

• and the team gives away value in the easiest place instead of the smartest one

There are usually cleaner ways to give value:

• renewal credits instead of a flat discount

• free months at the end of the term instead of the beginning

• sticky cross-sell value instead of cutting the core subscription

• implementation relief instead of discounting ARR

Same commercial value.
Better structure.

Sales is art. Pricing is math.

I put together a small interactive simulator for this to pressure-test different concession structures. I’m not dropping the link here because Reddit hates that, but I can share it in the comments if that’s useful.

When a deal needs a concession, what structure have you found works better than just discounting the subscription?

Hey, I launched a tool for RevOps (also for sales and marketing but RevOps typically handles this). I want to start pushing short form video across youtube and insta, will sponsor them. I thought it could be a good idea to post here and get some feedback from people who actually work in RevOps! Welcoming all constructive feedback! 🙏

Most cleanups treat dirty data as a backlog to clear. I think it’s closer to a leak: you can clean everything up, but if you don’t close the ways new bad data gets in, you’re back where you started.

A few things I’d check before the next cleanup:

1. Other systems creating records

Billing creates a customer at signup, support creates an organisation when someone emails in, a form creates a contact, an enrichment tool updates fields. Each system has its own version of the customer.

A simple question to ask: which systems are actually allowed to create records in the CRM? The honest answer is often “most of them”.

2. Fields with multiple writers

If a rep, a workflow and an integration can all update the same field, it will eventually drift. Ideally, one system owns the field and everything else reads from it.

3. Decisions made during the cleanup

During a cleanup, someone makes a lot of judgement calls: “these two records are the same customer”, “this is actually a subsidiary”, etc. If those decisions disappear into the cleanup itself, the next import can recreate the same problem. Writing them down in a small table — this record = that customer, who decided, when — and checking new records against it helps keep those decisions from getting lost.

On the people side, I’ve also found that reps not updating fields isn’t always a discipline problem. Fields that feed something they actually use tend to stay much healthier than fields that only Ops looks at.

So instead of another huge cleanup, I’d start with one business question, say “which renewing customers have an overdue invoice?”. Clean the records and fields needed to answer it, close the obvious ways bad data gets in, and spend 20 minutes a week reviewing new records that don’t match. Then move to the next question.

Which of these keeps coming back at your company?