Blog Article

Blog Article

Blog Article

Why PLG RevOps Struggles with Stripe Data

May 1, 2025

Alt title: "I ran into this problem 3x as a RevOps leader, which is why we started ClearSync 😎"

by Joss Poulton, Co-founder & CEO, ClearSync

Revenue Operations was supposed to be the answer to chaos. A way to align sales, marketing, customer success, and finance. A role born out of necessity, because nobody else was going to own the systems and data across the customer experience that modern GTM teams depend on. But there's an uncomfortable truth:

You can have 30 required fields, beautifully built attribution models, and customer automation that rivals the best, but if your CRM's recurring revenue data isn't accurate, none of it makes sense.

You can't trust the data enough to connect critical parts of the buyer's journey across CRM objects. As a result, you lose the ability to achieve the highest calling of RevOps — to orchestrate a top-notch customer experience and dollar-based feedback loop.

The revenue data disconnect is especially pronounced for PLG companies, who often use Stripe to bill customers and HubSpot to run GTM. A pairing that, on the surface, seems ideal. Stripe is clean, powerful, and developer-friendly. HubSpot is intuitive, cross-functional, and built for the GTM team. But underneath, right from first oAuth, there's a widening data gap.

Stripe's data model centers on 'Customers', Subscriptions, Invoices, and other events. It's elegant in the way that developer tools often are, but also abstract and deceptively complex. A single Company in HubSpot might have multiple subscriptions, but in Stripe, a 'Customer' is an email address.

A user might sign up using a Gmail an enter "First Last" in the Customer Name field. Which HubSpot Company should their subscription be routed to? Revenue can move without human involvement, and that can be a scary prospect to an unexpecting CRM.

So, when you try to ask questions that require both systems, questions like:

  • Which campaign led to the highest-paying customer?

  • What kind of customers are upgrading? Downgrading? Canceling? (By employee size, geo, industry, etc.)

  • What Enterprise accounts did we gain access to through freemium/PLG?

  • How much revenue have we generated from this company over time, across subscriptions?

  • Are we differentiating and capturing revenue events correctly (including all MRR change events and segmenting them)?

  • Who owns this customer, and when is their account up for renewal?

…you get blank stares, patchy data imports, and Zaps that don't tell the whole story, as well as countless exports to and from Excel or Sheets. And at the heart of all the chaos? Often a silent assumption that Stripe should answer questions it was never designed to.

Stripe ≠ SaaS GTM-Ready. And that’s ok if you acknowledge it.

Stripe is phenomenal at making it easy for developers and product teams to charge money and manage a customer's subscription within a web app. It can do a lot of really cool things, especially if a SaaS product team has created a mechanism, either triggered by the user self-service or within a company's internal admin console by finance or (gasp) the sales team, to make things happen in Stripe. Many of Stripe's most important features like proration control, subscription schedules, or custom metadata are only accessible through the API. That's great for devs, frustrating for finance.

Other data challenges abound behind the veil of self-service. As RevOps leaders, we want to:

  • Match billing and subscription data to all relevant HubSpot records based on whatever data morsels we have.

    • Find out if a Gmail signup is actually a VP at a Fortune 500 company

  • Navigate the friction between self-service and sales-led GTM when someone purchases in-app at a Company with an open Deal

  • Sync Renewal deals with live subscription data

Ultimately, Stripe isn't designed to answer these questions about what transactions mean to a SaaS company in their language and CRM system. But it is our job, as RevOps, to bridge the gap between billing data and GTM execution. To turn transactions into insights and to make revenue a shared language inside the CRM.

The Vision: Subscription Revenue as a Shared Language

Imagine if Stripe subscription and MRR data wasn't something you had to pull from another system yourself, fix in Excel, or debate in a meeting. Imagine if it lived inside the CRM — structured, timely, and meaningful. A set of high-quality records, not an afterthought:

  • GTM teams would stop disagreeing over revenue data and start acting on it

  • CS would have access to key customer data they can't see today

  • Sales would know which self-serve accounts are enterprise whales in disguise

  • Marketing could finally connect to a good revenue data set for attribution and segmentation

Dashboards would stop lying. Workflows would trigger accurately. And every team could trust the numbers they're seeing — ARR, NRR, and expansion — as the actual numbers.

RevOps can lead the way. But only if we stop accepting broken models, bad handoffs, and duct-taped reports or data streams as the norm. Let's operationalize some revenue data, it's in our title after all 📈🕺📈!

Get Monthly Updates

Subscribe to a monthly email with a roundup of our latest content about Stripe & HubSpot, PLG & Sales-led, and RevOps & Finance

Get Monthly Updates

Subscribe to a monthly email with a roundup of our latest content about Stripe & HubSpot, PLG & Sales-led, and RevOps & Finance

Get Monthly Updates

Subscribe to a monthly email with a roundup of our latest content.

Get Monthly Updates

Subscribe to a monthly email with a roundup of our latest content.