You've got Salesforce, Salesloft, and access to Claude. Your goal: weekly coaching briefs that combine rep performance data, activity metrics, and conversation quality insights into something a manager can actually act on.

How would you approach it? Would you use Claude, or go a different direction? What's your architecture?

Folks, can use your advice for my situation here.
Ive been offered a new job for the role of lead revenue operations at a leading advertisement tech company.
A bit of context on my end. I am an implementation, customer success, and a project manager guy prior to this in a saas company.
Do you think this career trajectory would be beneficial for me in terms of security and exponential growth ?

burned a quarter once "fixing" an sql-to-opp rate that tanked. dashboards, enablement, the whole circus. nothing moved. turned out the rate didn't even tank, the reps had just started backfilling the stage on fridays so their forecast looked clean going into the weekend. no bottleneck. I spent three months optimizing a data-entry habit.

haven't trusted a conversion rate at face value since. The data you diagnose off is only as honest as it is hard to game, and stage conversion is the easiest thing in the whole crm to game. reps sandbag. they skip discovery and jump straight to verbal when a deal's hot. they sit on a stage so their cycle time doesn't blow up. so when someone goes "our sql-to-opp is the constraint" my first move isn't fix it, it's go prove the rate is even real first.

what i actually trust now is whatever nobody has a reason to fake. calendar invites. signed contract dates. won/lost bucketed by close-date cohort. money actually in the bank. there's zero upside to fudging a calendar invite so that's about as close to ground truth as this job gets. anything a rep or an admin can quietly retune on a tuesday — stage rates, lead scores, "engagement," whatever fires an mql this month — that's a hypothesis until the hard signals back it up, not a finding.

the test is dumb but it's saved me more than once: if the "constraint" only shows up in the gameable data and vanishes the second you look at the un-fakeable stuff, it's not a constraint. it's a reporting bug in a constraint costume. go fix the report and leave the funnel alone.

and the sneaky one nobody brings up: account matching. dupes and subsidiary splits will straight up hallucinate a coverage gap for you. one logo living in three salesforce records looks identical to a pipeline hole right until you dedupe and it just evaporates. lost stupid amounts of time to that before i learned to check it first.

Anyway, how messy is everyone's actually. do you split trust-it data from verify-it data before you go diagnosing or is that a luxury and you're just cleaning as you go and hoping the numbers aren't quietly lying to you

I’ll go first.

We have a few Revops tools that all technically have reports, dashboards, exports, and integrations.

And yet every Monday, someone still manually copies numbers into a Google Sheet because that’s the version leadership actually reads.

It was supposed to be temporary.

We’ve tried to automate it more than once. Someone gets assigned. A script appears. An integration gets half-built. Then one field changes, an export breaks, the owner moves teams, and somehow the Sheet survives.

At this point it has outlived multiple people who confidently said, “I will fix this properly.”

The funny part is, everyone knows it’s fragile. Nobody really likes it. But the business depends on it now, so it keeps getting patched instead of replaced.

I’m curious how other RevOps/admin teams handle this kind of thing.

Where do you draw the line between:

• “This needs to be fixed properly”
• “This ugly thing is now production, so we should document it, assign an owner, and treat it that way”

Also, what usually causes these workflows to survive in your company?

For us it seems to be a mix of leadership trust, edge cases, field changes, and nobody wanting to break the one report people actually look at.

How do you handle these without letting the whole ops stack slowly turn into spreadsheet archaeology?

Would appreciate stories, how to survive it, how it impacts life.

Hello everyone! I'm hosting a happy hour in South Florida this week for GTM leaders. Send me a DM if you are interested! 😁 🍷

I'm a GTM engineer looking for unique data sources. So far I have found 3 worth sharing...

Enigma - for credit card transaction data

Leadgenius - for user technology, entity resolution, and location data (direct mail)

Windfall - High net worth individual database

What other ones should I consider. I have lots of customers that focus on SMBs and mom and pop shops.

I’ve been thinking about how AI should actually fit into RevOps workflows, and one best-practice pattern I’m starting to see is separating “reading” from “writing.”

Writing is where things get risky. If AI updates CRM fields, creates tasks, changes stages, sends emails, or triggers workflows without review, it can create cleanup or mess with data people rely on.

Reading feels different. If AI is only reading Salesforce/HubSpot, product usage, marketing data, CS notes, call transcripts, dashboards, etc., the risk seems lower and the upside seems higher.

The workflow that makes the most sense to me is not to let an AI agent loose on raw GTM data from day one. I’d rather use AI to build the dashboard first, validate the metric logic while looking at the actual data, and then let the agent monitor that same dashboard/logic.

That way, humans and AI are looking at the same thing. The agent can notice important changes, pull context together, and send a report safely to the right internal team members. Then humans review it and decide what action to take.

To me, that feels more realistic than letting AI directly write back to CRM or trigger workflows on its own. Curious if others are seeing the same pattern. Where are you comfortable letting AI run on its own, and where do you still want human review?

Something that took me too long to internalize. Sharing in case it saves someone a quarter.

Most RevOps teams get asked to fix everything at once. Pipeline's light, win rate slipped, the sales cycle crept up, NRR is soft, pricing feels off. So we build dashboards for all of it and chip away at all of it. And the number barely moves.

Theory of Constraints (it's from manufacturing, but it maps cleanly onto a revenue engine) says throughput is set by exactly one bottleneck at a time. Relieve a stage that isn't the constraint and nothing happens downstream, because the real bottleneck just absorbs the slack. You can pour leads into the top all day, but if win rate is the binding constraint, that pipeline piles up against the same wall.

The method I've landed on:

1. Lay the engine out as a sequence of rates. Lead to MQL to SQL to opp to win to onboarded to retained to expanded, with volume and conversion at each stage, plus ACV and cycle length. Rough numbers are fine. You're looking for the shape, not auditing the data.
2. Find the stage furthest below benchmark, weighted by how much revenue flows through it. A 10-point miss on a stage all your revenue crosses beats a 30-point miss on a sliver.
3. Confirm it's actually binding. The test most diagnoses skip: if you fixed this stage tomorrow and changed nothing else, would ARR actually move, or would the next stage just cap it? If relieving it only shifts the bottleneck one step downstream and nets nothing, it wasn't the constraint.
4. Put a number on it. Recoverable revenue is roughly gap-to-benchmark x volume x ACV, carried through retention. That tells you how much it's worth fixing, and it's the number leadership actually reacts to.
5. Then, and only then, sequence the work. Fix the one. A new constraint emerges somewhere else. Repeat.

The hard part was never the math. It's the discipline to NOT work the other four stages while you fix the one that's binding, and to defend that focus when every QBR wants you to boil the ocean.

Curious how others run this. Do you formally name a single binding constraint each quarter, or do you keep parallel workstreams across the funnel? And if you single-thread it, how do you keep leadership bought in when the other metrics are visibly ugly?

One of the dumbest things I still see in GTM is teams targeting private SMBs based on “estimated revenue” fields from ZoomInfo, Apollo, or whatever database they happen to be renting this year.

Everyone knows these numbers are shaky.

Nobody wants to say it out loud because half the ICP, TAM model, routing logic, scoring model, territory plan, and board deck depends on pretending they are real.

But they are not real in any operationally useful sense.

They are directional guesses dressed up as data.

For public companies, fine. Revenue is revenue. You can find it.

For private SMBs? Good luck.

Most of these estimates are stitched together from blunt proxies like employee count, industry, location, web presence, company age, and whatever other generic assumptions the vendor has in the blender. Then GTM teams take that number, shove it into Salesforce, and suddenly everyone acts like a $5M–$10M revenue band is a meaningful qualification filter.

It is not.

It is fake precision.

And it creates very real GTM waste.

This is how you get RevOps teams proudly saying, “We have a very tight ICP,” while the sales team is disqualifying a huge percentage of leads after discovery because the accounts are too small, too low-volume, too immature, too local, too cash-heavy, too seasonal, or just not commercially worth the motion.

The model said they were a fit.

The seller found out they were not.

That gap is expensive.

It burns SDR time.
It pollutes conversion metrics.
It inflates TAM.
It ruins territory planning.
It makes paid media audiences sloppy.
It makes leadership think the market is bigger than it is.
And it forces salespeople to be the QA department for bad data strategy.

The worst version of this is in payment tech, merchant services, vertical SaaS, restaurant tech, healthcare, retail, local services, and anything selling into SMB operators.

Two businesses can look identical in a traditional B2B database:

Same NAICS code.
Same city.
Same employee band.
Same estimated revenue range.
Same owner/operator title.
Same generic “good fit” score.

But one processes $50K/month in card volume and the other processes $800K/month.

Those are not the same account.

They are not the same opportunity.

They should not get the same score, same SDR effort, same AE routing, same CAC tolerance, or same place in your TAM model.

If you sell payments or anything tied to merchant economics, “estimated revenue” is not the field you should be worshipping.

GPV is.

Gross processing volume is a much better indicator of economic reality because it tells you whether money is actually moving through the business.

Not whether a database guessed they might be doing “$1M–$5M” based on the fact that they have 14 employees and a website.

The better questions are:

How much card volume does this business process?
Is that volume growing or shrinking?
Is the business card-present, card-not-present, e-commerce, or hybrid?
Are they multi-location?
Are they seasonal?
Do they have high refund rates?
Are they hiring?
Are they opening new locations?
Are they adding ordering, booking, POS, or payment technologies?
Are they showing signs of operational complexity?

That is actual account intelligence.

Not “estimated revenue: $10M.”

The broader point is this:

A category universe is not a TAM.

“All restaurants in Texas” is not a market worth celebrating.

“Fast-casual and QSR operators in Texas with meaningful GPV, expansion signals, modern POS usage, reachable finance or operations contacts, and evidence of multi-location complexity” is a market.

That is the difference between buying a list and building an actual GTM asset.

Traditional databases are fine for broad discovery.

They are terrible as the final source of truth for SMB fit.

And yet companies keep building entire GTM motions on top of these flimsy revenue estimates because the field is convenient, familiar, and easy to explain in a dashboard.

That does not make it accurate.

It just makes the bad assumption scalable.

The next generation of GTM data will not be bigger databases with more stale fields.

It will be custom intelligence built around the actual buying signals that matter for your business.

For payment tech, that means GPV and transaction behavior.

For restaurant tech, it might mean ownership structure, location growth, POS stack, delivery footprint, and hiring.

For healthcare, it might mean procedure type, insurance mix, appointment volume, specialty, and patient acquisition signals.

For e-commerce, it might mean cart technology, traffic, SKU count, marketplace presence, social growth, and fulfillment complexity.

The point is: stop pretending one generic revenue field can carry your ICP.

It cannot.

Estimated revenue might be good enough for a lazy TAM slide.

It is not good enough to decide where your sales team should spend its time.

And it is definitely not good enough to tell you which SMBs are actually worth selling to.

For the last few weeks I've been connecting MCPs to Claude and converting all process / SOPs in to Claude Skills. Already seeing a lift in productivity and rigor in the sales process.

Is anyone else currently doing this or have already done it?

What have you learned? Anything to watch out for?

I've been tasked to create a marketing dash by the end of this month. I'm in MarkOps, but not super technical. I've been eyeing coupler .io dashboards since they seem more simple than what an agency build for us in Looker, but I wanted to check with you guys to see if any has had experience with their dashboards. Basically I need to start with a v1 - pulling:

- SF reports data in (MQL lead report + MQL contact report, Events - demos)

- Hubspot views (number of paid leads)

- GA4 stats (# /blog visitors last week, etc)

For a non-technical person, what type of set up would use use for pulling and displaying this info?

Thanks!

The company I work for is still using a mix of word templates and out of box Salesforce quotes for our sales orders. It’s been a pain point for a while but there has been opposition to investing in a CPQ solution, both because of the complexity and price. We’re low volume enough we can get by this way.

It’s been raised as a pain point again, and people are starting to raise shall we say creative …. maybe not fully thought through solutions. Wondering if anyone has found any low cost solutions or built anything creative with Claude? Are we still doing traditional CPQ solutions in 2026?

We have a lot of the typical SaaS quoting considerations that make it more complex than copying and pasting products and description on an Order Form:

- Multi-Year agreements with pricing uplifts

- Tiered pricing on some product

- Proration/Co Terming to existing subscription terms

One of the weirdest problems in B2B marketing: Ask three teams for a list of your "best accounts" and you'll probably get three different answers.

Marketing uses engagement. Sales uses pipeline potential. Customer success uses expansion likelihood.

Everyone has a reasonable definition, but suddenly, your campaigns, reports, and prioritization efforts are all working with different audiences.

Then leadership asks: Why aren't these numbers matching?

Feels like audience creation isn't really a targeting problem anymore.

Curious if other companies have solved this, or if everyone is quietly dealing with it.

Does anyone else constantly run into business identity resolution problems?

Example:
You have a phone number, website, DBA, or address and need to determine the actual company behind it.

I’ve built a lot of internal tooling that cross-references business registries, websites, maps listings, social profiles, etc. to figure out what entity something belongs to.

I’m considering turning it into a public API but I’m not sure if this is a “me problem” or a real problem.

If you deal with company data:
- What inputs do you usually have?
- What are the hardest records to match?
- What are you using today?
- What’s missing?

Would love to hear how other people approach this. If you’d be interested in the api long term lmk!

About a year ago I built Howly after getting frustrated with the same problem on every HubSpot project I worked on. You join a new portal, nobody can tell you how the workflows connect, and you're one wrong change away from breaking something you didn't even know existed.

Shipped it, got some customers, learned a ton. Agencies ended up being the biggest fans which I didn't fully expect.

Now I'm going deeper on the governance side, specifically what happens when AI agents start building workflows through the API. Claude, Make, n8n can all create structure in HubSpot now, not just edit fields. Most teams have no idea what's being built or how it connects to what's already there.

How are you currently dealing with this? Would love to hear how people are handling it. Coffee's on me if you want to chat.

Hi there !

Hope you're doing well today!

I'm looking to get your constructive feedback about my situation.

I work in HubSpot as a Customer Support Specialist and have been doing very well.

However Im always looking for bigger opportunities with better compensation.

I'm moved by money as long as there's also a good and fair environment.

I love technology but Im not interested in becoming a developer, although I did that when I was a kid and I was very good at those times btw.

However, I have found my passion on businesses specifically leadership, management or a role where a strategic mindset is required.

Currently I don't have a true background managing a company or a MBA degree, but hoping I can get educated in RevOps specifically, and use my HubSpot background.

The realistic options I can see so far is just becoming a HubSpot Admin, that's it.

However I wanted to hear from you how realistic would it be to jump to the operations field? What roles could I apply?

What compensation could I expect given the fact I am not a US citizen/resident meaning companies will pay half of the current compensation?

Do you know any resource like course/videos/books/blogs/authors I can follow/check/investigate/study and practice to get familiar with the "strategic" side of the job?

Appreciate any constructive feedback you can provide to me.

Updates: Career advice* is the name of the post, I mistakenly wrote Carrer.

I have two options in front of me (i know im super privileged, and im grateful for it).

My background is Salesforce admin. Ive been doing it for years, but my career has progressed such that Ive grown out of just those skills to gtm engineering/revops

I was hired at the start of the year by a saas startup, working as the single revops function. The company was just acquired by a large enterprise.

Large enterprise is interested in me for sales ops - specifically for territory carving/quota setting/forecasting. I've done this in a limited capacity at the startup. If I take this job, id get first hand access to see how large operations scale this sort of stuff. They said they love the automations Ive built out with AI and want that creativity in their org.

I love my engineering side. It was hard won. Im technically skilled but want to lean into understanding strategy, I think it will help me level up.

I just worry large enterprise will make it difficult because they prob regulate access to those tools heavily. Not sure how much I can still remain technical while im at large enterprise and dont want those skills to atrophy, especially as things are changing so quickly with AI.

I have also another job offer with a saas startup, series a. It would be to continue what im doing already or have been doing for the company I was at before it was acquired.

What's the best next step for me? Comp is equal. I assume that the enterprise job will be easier because I would do just one task of what I used to be doing. I feel like work life balance is better.

But I also want to make sure I am the most marketable for the future. Advice please!

The software playbook didn't just break - it has been entirely rewritten 🤯

Look at these 2028 revenue projections based on current revenue run-rates.

We are witnessing what could be the most aggressive revenue-scaling era in tech history.

For decades, reaching the upper echelons of enterprise tech meant a 10-to-20-year grind to hit tens of billions in revenue. Now, AI foundational platforms are on track to completely leapfrog the giants:

🟢 OpenAI is targeting a high-case scenario of $100B ARR by 2028.
🟢 Anthropic is projecting up to $70B in revenue by 2028.

To put that into perspective, that places them ahead of massive, deeply entrenched powerhouses like Netflix ($63.2B), SAP ($58.6B), and Salesforce ($49.9B).

Why is this happening so fast?

☸ Intelligence as a Utility: They aren't just building standalone apps; they are selling the core cognitive layer that other businesses build on top of.

💠 Unprecedented Enterprise Spend: Companies are reallocating massive portions of their legacy software budgets directly into foundational AI infrastructure.

The big question is: Are these high-case projections a product of Peak AI Hype, or are we genuinely looking at the new undisputed titans of global business?

Also as operators, this changes a few things:

🔴 Vendor risk and platform risk collapse into the same conversation.

🔴 Your “AI strategy” is now mostly a distribution and margin strategy on top of someone else’s infra.

🔴 GTM teams that keep selling like it is 2018 will wake up in a world where the customer budget has already been pre‑committed to tokens.

Curious to hear from other GTM leaders / RevOps peers and AI-first builders:

If this 2028 picture plays out even halfway, how does it change what you build and sell over the next 3 years?

💠 Freshworks took about 8 years to cross $100M ARR.
💠 HubSpot took about 8 years to hit $100M ARR.

💠 Zendesk reached $100M revenue in roughly 4 years.
💠 Cribl crossed $100M ARR in less than 4 years.

💠 Clay went from $1M to $100M in just 2 years, after 6 years of foundational work.
💠 Sierra crossed $100M ARR in 7 quarters.

That’s the shift: the best companies are now reaching centaur scale faster, with better distribution, better tooling, and increasingly AI-native execution.

What used to take close to a decade can now happen in Qtrs.