By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Revenue Operations

The Third Era of GTM: Why Data Rot Is the Real AI Problem

swirled squiggle accent

Most revenue teams building an AI-powered go-to-market motion are stuck solving the “shadow ops” and context problems. They invest in orchestration tools, enrichment workflows, and agent infrastructure—and then watch their SDRs send emails that go rogue on the messaging guidelines they were given, their agents confidently act on signals that went stale six weeks ago, and their lead-scoring cards deliver grades that go unused.

‍

In a recent RevOps Co-op webinar, Matthew Volm, CEO and founder of RevOps Co-op, hosted Jordan Hamilton, Head of Marketing at Sumble, and Camela Thompson, Head of RevOps at Funware and a longtime revenue operator, for a conversation on what they're calling the third era of go-to-market (GTM) data — and why fixing the foundation before scaling the agents isn't optional.

‍

The session opened with a live audience poll on the biggest GTM data constraint teams are facing. Freshness landed at the top of the list — which, as Hamilton put it, is not surprising. "Our world is changing," he observed. "There're more people moving in organizations, more technologies being brought in. Large organizations are starting to act a little bit more agile." The implication for data: what was accurate two quarters ago may be actively misleading today.

‍

What "Data Rot" Actually Means — And Why It Compounds

Hamilton introduced the term data rot not as a metaphor for general messiness but as a precise description of how fragmented, aging data degrades the usefulness of any downstream action — whether that action is taken by a human rep or an AI agent.

‍

The mechanism is a compounding error problem. Most organizations are operating with multiple data sets — a company list, a people list, a tech stack list — that they join on a common attribute like company domain. Each of those lists carries its own error rate. If your company data is 80–90% accurate, your people data is 80–90% accurate, and your tech stack data is 80–90% accurate, the actual completeness of your view of any given account isn't the average of those rates. It's the product.

‍

"If you look at the compounding errors from those data sets... your actual view is in the neighborhood of 40 to 50% in terms of completeness and accuracy." — Jordan Hamilton

‍

That number is not a knock on any specific data vendor. It's an honest accounting of what happens when you try to assemble a coherent picture of a dynamic organization from static, separately sourced data. And it has real operational consequences: reps who sound uninformed on calls, agents that act confidently in the wrong direction, and signals that land with the wrong person entirely.

‍

Titles compound the problem further. Hamilton flagged the rise of what he called "the vague title" — roles like "Member of Technical Staff, GTM" or just "GTM" — as a real obstacle to accurate people-level targeting. When you can't reliably classify what someone actually does from their title alone, the entire downstream workflow built on that classification inherits the ambiguity.

‍

The Three Eras: From Phone Book to Context Layer

Hamilton framed the current moment as a transition between distinct eras of GTM data, each defined by how organizations understood and acted on prospect information.

‍

Era one was the phone book era — a list of names, companies, and titles, largely static, used as fuel for high-volume outreach. The underlying assumption was that data quality was imprecise but acceptable because the model was brute force anyway.

‍

Era two brought workflow sophistication. Enrichment tools, scoring frameworks, and orchestration platforms like Clay entered the stack. Teams got meaningfully better at moving data through systems and routing it to the right people. But the fundamental problem — whether the information itself was accurate and contextually complete — wasn't solved. It was automated around.

‍

"The workflows really haven't solved the foundational problem. We got really good at moving data around. We got really good at piping it into different systems... But we're starting to see GTM teams that are starting to get bit by the notion that agents are acting confidently and prolifically on that data." — Jordan Hamilton

‍

Era three — the one Hamilton argues we should be entering — is characterized by context-layer data: connected, continuously updated information that links not just company names and job titles, but internal team structures, project-level initiatives, technology usage at the team level (not just the organizational level), and organizational dynamics like hiring trajectory and reporting relationships. The goal is to give reps and agents what they'd know if they were walking the halls of the account themselves.

‍

The ICP Trap: Defining Fit Around the Data You Have

One of the sharper observations in the session came from Volm, and it's worth sitting with. Most revenue teams define their ideal customer profile (ICP) based on the data points they have access to — firmographic variables like company size, headcount range, revenue band, industry code — because those are the fields that exist in the databases they subscribe to.

‍

This is backwards.

‍

"I feel like a lot of operators, we have this baggage that we've brought with us from these pre-AI days where... we need to define our ICP based on the data points that we have available. But that way doesn't need to exist anymore." — Matthew Volm

‍

Volm illustrated this with his own company's use case. In a traditional pre-AI framing, he'd target his event marketing platform Eventful at VPs of Marketing at software companies with 200-plus employees — a reasonable approximation of "people who run events." But starting from first principles, the real ICP looks completely different: revenue technology companies that exhibit a high frequency of conference sponsorship behavior, because those are the organizations that already value in-person GTM and would benefit from badge scanning and side-event management tools.

‍

The difference between those two definitions isn't minor. One is a proxy forced by data availability. The other is the actual answer — and it's now increasingly possible to find it. Hamilton's point was that LLMs and structured data providers can now help teams build machine learning models from behavioral and contextual signals that would have been invisible to a Boolean filter even a few years ago. The Sumble team built exactly this kind of model for Nooks, helping them identify outbound SDRs across their total addressable market (TAM) in a landscape where the title "SDR" itself has fragmented into BDR, XDR, GTM, CLADR, and a dozen other variants that no keyword filter reliably catches.

‍

This connects directly to a broader challenge that RevOps practitioners are grappling with around AI readiness — the inputs to AI workflows determine the quality of their outputs, and most teams haven't interrogated their inputs with the same rigor they've applied to their tooling.

‍

Signal Overload: When More Data Becomes a Trust Problem

The session's second poll asked how often signals go stale before a team acts on them. The responses underlined a related problem: even when data quality is reasonable, the signal-to-noise ratio in most GTM stacks is terrible enough that reps have learned to ignore the alerts entirely.

‍

Volm named this directly:

‍

"I feel like literally everything gets a score these days. Lead scores, account scores, engagement scores. Everything gets a score. So then if everything is scored, nothing actually has a score, 'cause it's just ignored. And I feel that way with signals, too." — Matthew Volm

‍

Thompson added a field-level observation: the reps on her team who are most capable — the ones with the initiative to solve their own problems — are also the most likely to build their own workflows and tools in the shadows, independent of what RevOps has configured. The signal problem and the adoption problem are intertwined. If the signals RevOps serves up aren't precise enough to interrupt a rep's day and actually change their behavior, those reps route around them.

‍

The practical implication is that signal design is as important as data quality. Hamilton's framework for this: make signals source-verifiable. If a rep can't trace a signal back to its underlying evidence — a job posting, a LinkedIn change, a specific technology flag — they won't trust it. And an untrustworthy signal that reaches 1,000 reps is worse than no signal at all, because it trains the team to ignore the feed.

‍

This is a harder ask than it sounds. As Thompson noted, her team's automations surface false breaks from AI several times a week because the marketing team is prompting incorrectly. The infrastructure for clean signal delivery requires ongoing calibration, not just a one-time build. For more on the patterns that tend to break in these setups, the RevOps Co-op community has documented twelve common CRM and MAP issues worth auditing before layering AI workflows on top.

‍

Change Management: Getting Sales Teams to Trust the Data You've Built

The final portion of the session shifted from data architecture to organizational behavior — specifically, how RevOps teams get sales reps to actually use the systems they've built rather than building their own.

‍

Thompson offered a change management approach she's seen work consistently: identify the loudest objectors and bring them into the build process early. Let them set requirements. Make them guinea pigs for the first rollout. The payoff is counterintuitive but reliable — vocal critics who become believers don't just adopt; they evangelize.

‍

"The loud objectors become the loudest champions and will tell everybody how awesome it is when you roll it out to the rest of the team. That's, like, a hack that I've seen work over and over again." — Camela Thompson

‍

Beyond individual buy-in, Thompson urged fellow operators to own rhythm-of-business meetings as a credibility play (you can read more about that in our article on Creating a Forecast Muscle). By running Monday team data reviews, weekly cross-functional syncs, monthly look-backs, and quarterly business reviews, RevOps earns the standing to frame what good data looks like and to surface problems before they become complaints. The person who runs the meeting shapes the conversation.

‍

Hamilton added a calibration-specific tactic from Sumble's work on territory design: when presenting a new ranking or book of business to a sales team, make the data visible and ordered on screen, then ask the SME whether rank 42 actually belongs above rank 43 — and why. That kind of iterative calibration, done with the people who will live with the output, builds far more trust than handing over a spreadsheet and asking for feedback in the abstract. This directly supports the kind of territory design work that tends to generate the most internal friction when it isn't grounded in shared data.

‍

For teams facing cross-functional misalignment that goes beyond the sales team — marketing and sales fighting over definitions, executives whose conflict has trickled down — Thompson's recommendation was to bring in a neutral authority: a CFO, a CTO, or a CMO who's operationally minded and can play peacekeeper in the room where account definitions and ABM strategy get debated. Having executive air cover for the RevOps position isn't a sign of weakness; it's a structural shortcut that prevents those debates from stalling indefinitely.

‍

The change management challenge is one that shows up everywhere in RevOps, and it's worth noting that influence without formal authority is one of the core capabilities that separates operators who get things built from those who get stuck in endless alignment cycles.

‍

What Good Context Actually Looks Like in Practice

To make the abstract concrete, Hamilton walked through what third-era context looks like applied to the most basic GTM artifact: an outbound email. The session opened with a version of a bad one — a message that referenced the recipient's first name, their job title, and a LinkedIn post they'd made, without connecting any of those signals to a specific reason the message was relevant. Thompson's read: "This doesn't tell me what you do and how you solve it, and as a technical buyer, I want to jump there really, really quickly."

‍

The improved version Hamilton showed later in the session named a current initiative, referenced work the recipient was actually involved in, and framed the ask around relevance rather than generic value props. The gap between the two examples isn't just better writing — it's better inputs. The improved email is only possible if you know which team within the organization owns a particular project, whether the recipient is actually involved in it, and what the timing of that involvement looks like.

‍

That level of context — what Hamilton described as understanding "how they're operating today, as if you were walking the halls yourself" — is what separates a message that gets replied to from one that trains the recipient to delete your domain on sight. At scale, the difference in email deliverability and domain reputation from that quality gap is not small. Sending 100 emails with 40–60% irrelevant addresses doesn't just waste rep time; it damages the infrastructure that every future send depends on. Cold outbound is already broken in most stacks — context quality is one of the few levers that can fix it without adding volume.

‍

Key Takeaways

  • Data rot compounds across sources. If your company, people, and tech stack data are each 80–90% accurate, your actual account-level view is closer to 40–50% complete — because errors multiply, not average.
  • Define ICP from first principles, not from the data you have. The most precise target market definitions start with behavioral and contextual signals, not with the firmographic fields that happen to exist in a database.‍
  • Signal overload means no one looks at the signal. Too many alerts and scores mean that reps will ignore the feed entirely. Fewer, source-verifiable signals will always outperform a high-volume alert system.‍
  • Agents amplify whatever the data already is. AI workflows running on stale, fragmented, or contextually thin data don't just underperform — they act confidently in the wrong direction at scale.‍
  • Change management starts with the loudest objectors. Bringing vocal critics into the build process and making them your first rollout cohort turns the most likely source of resistance into the most effective distribution channel for adoption.‍
  • Source verifiability is step one to gaining trust. Reps won't act on a signal they can't understand. Every alert, rank, or score your team serves up should be explainable, not just directional.

‍

The underlying current across this session is a familiar one for any RevOps team that's tried to layer AI on top of an existing data foundation: the sophistication of the tooling and the quality of the underlying data are not on the same improvement curve. Orchestration, enrichment, and agent infrastructure have all advanced quickly. The actual accuracy and contextual depth of account-level data has not kept pace — and at the speeds that AI agents operate, that gap is no longer a quality-of-life issue for reps. It's a strategic liability.

‍

Learn more about how Sumble helps revenue operations teams build connected, continuously updated account intelligence that gives reps and agents the context they need to reach the right person with the right message at the right time.

‍

Looking for more great content?

Check out our blog, join our community and subscribe to our YouTube Channel for more insights.

Related posts

Membership Options

Pick your path

Join 21,000+ RevOps pros. Start free, or unlock the full community and everything that comes with it.

Free 👋
Free forever

A newsletter full of best practices and lessons learned, plus a heads-up on upcoming in-person and digital events.

Get started
Starter 🕺 Popular
The full community

Our community of thousands of RevOps pros, plus a peer-to-peer matching program.

Join Now
Rise 🚀
Everything, leveled up

Everything in Starter plus course and conference discounts, our knowledge hub, career coaching, and more.

Join Now

Reach your RevOps goals

Our average member has 5+ years of RevOps experience — so you'll have real-time access to seasoned pros. All we ask is that you're generous with your knowledge in return.

Become a Member →