The promise of agentic AI in revenue operations is compelling: automated enrichment, intelligent routing, real-time account hygiene, agents that work while your team sleeps. But there's a prerequisite that most teams skip, and it's costing them more than they realize. Before any AI can act reliably on your go-to-market data, someone has to make that data worth acting on.
In a recent RevOps Co-op webinar, Ernesto Valdes, CTO at Traction Complete, moderated a panel conversation with three practitioners doing this work at scale: Ablla Feliciano, Senior Director of Global Revenue Operations at Fivetran; Jon-Sun Lu, Senior Director of Marketing Operations at GitHub; and Radu Negru, Head of Data at Inchcape. The session covered the full arc of revenue data architecture — from the current-state chaos most teams are living in, to practical frameworks for building the kind of trusted data layer that actually supports intelligent automation.
The opening poll told the story plainly: when asked where their revenue data layer was breaking most today, attendees spread their answers across nearly every option — conflicting systems, data quality and duplicates, unclear governance and ownership, AI readiness gaps, and tool fatigue. For many, the honest answer was all of the above. What followed was a conversation about how three different operators, in three very different contexts, are working their way out of that exact situation.
Ablla Feliciano is navigating one of the hardest versions of the revenue data problem: a merger. Fivetran recently closed a merger with dbt Labs, and her team is now running two parallel revenue organizations while building toward a unified system at the start of the next fiscal year — one CRM, one sales team, one source of truth.
Her advice for anyone starting this kind of data alignment work cuts through the noise quickly.
"The place where I would start is really on that customer mapping exercise. Creating the customer map of who are your customers, who are our customers, where do we see the same customer shared, and how do we want that reflected in the surviving CRM is actually the foundation that I would really focus on." — Ablla Feliciano
Everything downstream — territory models, field mapping, contract migration, renewal opportunities — depends on getting that customer map right. And doing it right means doing it outside the systems first, before any data migration begins. As Feliciano noted, this is rarely clean: companies use different identifiers, different account hierarchies, different definitions of what constitutes a customer. The shared DUNS number scenario is the exception, not the rule.
This connects directly to one of the most persistent challenges in RevOps: defining what an account actually is before you try to manage them at scale. Feliciano's framing is a useful anchor: start with the customer, then work outward to contracts, products, renewals, and territories. The hierarchy question — parent accounts, child accounts, how they relate — comes second, not first.
Radu Negru brings a different dimension to this conversation. At Inchcape, operating in the maritime industry, data quality isn't just an internal reporting problem — it has regulatory, financial, and reputational consequences.
"If we're missing a subsidiary within a customer-facing report, that can cause all sorts of issues, and obviously it can cause our customers to lose trust in our data. But more importantly, if we're paying the wrong vendor because we have stale bank account information, that leads to all sorts of reputational and even legal issues." — Radu Negru
Negru's prescription echoes Feliciano's starting point but extends it: know your customers, know your vendors, know your operating entities. Master data management isn't a background task — it's the foundation on which every customer-facing interaction and every internal decision rests.
What distinguishes Negru's approach is the emphasis on feedback loops. Data teams know the data; the business knows the on-the-ground situation. Bridging those two perspectives — building mechanisms so that field teams can flag when a report's output doesn't match reality — is what keeps the data layer honest over time. Without those feedback mechanisms, even clean data drifts out of sync with what's actually happening in the field.
His team has also moved away from the "big annual cleaning exercise" model, which tends to throw everything off track right before planning season. Instead, the goal is micro-cleansing cycles: small, regular, targeted hygiene work that doesn't disrupt the business and keeps data quality consistently high rather than dramatically variable.
Jon-Sun Lu is working at the other end of the data challenge. GitHub handles one to two million net new signups per month as developers and students try out the product and GitHub Copilot. At that volume, the question of source of truth becomes genuinely complex: user-input data, enriched data, backend behavioral data, and signals from multiple acquisition channels all arrive simultaneously and often conflict.
"One of the big things that I'm trying to handle in the data layer is just really how do you actually manage the source of truth when you have so many net new people signing up in different avenues, different forms, coming through via API, marketing forms, in product, outside of product, webinars, events. You get to this point where you just have so many different acquisition channels, it's hard to delineate what's that source of truth." — Jon-Sun Lu
His practical response is cross-functional alignment before architectural decisions. Before you can establish a source of truth, every operational team — marketing ops, sales ops, CS ops — needs to agree on what data they care about and where it should live. That means a data dictionary, a single pane of glass, and a shared language across teams. As Lu put it, don't try to solve the problem alone. Knock on the peer's desk and ask what they need before you architect your solution.
This is a harder ask than it sounds. Data management for busy RevOps teams requires not just technical discipline but organizational alignment — getting people with different priorities and different definitions of "good data" to agree on shared standards before the data flows start.
The panel's sharpest consensus emerged around a counterintuitive idea: the teams getting the most out of AI today are often the ones who deliberately slowed down first.
Feliciano described Fivetran's experience directly. When she joined roughly two years ago, the company was over-automated — accounts being created for every MQL, duplicates compounding across the system, chaos at scale.
"We made a very deliberate decision to slow down in order to speed up. We used to create an account for every single MQL. It was crazy. And we had just duplicates upon duplicates — just a really huge account base, and most of it was not relevant or necessary to actually exist in Salesforce. So we made a very deliberate decision to change our model so that we only create an account when we identify an actual selling opportunity." — Ablla Feliciano
The numbers ground to a halt. But that intentional pause gave the team control over what was entering Salesforce, and that control became the foundation for reintroducing automation with AI agents that could actually be trusted. "Slow is steady and steady is fast," as her former manager put it — and the principle holds for AI implementations in particular. Automating chaos at AI speed just produces chaos faster.
This is exactly the challenge that Traction Complete is built to help revenue teams navigate: establishing the data infrastructure and account hierarchy management that makes intelligent automation possible rather than dangerous.
Lu's contribution to the AI-readiness conversation was a practical framework for building organizational momentum without overcommitting: the paper cut principle.
A paper cut, in Lu's definition, is a manual process you do every day or every week that takes 10 to 15 minutes, feels repetitive, and quietly costs you time. It's innocuous on its own — but it adds up, and it's exactly the kind of task that AI is well-suited to eliminate.
"Don't try to go for the moon. Try to get and solve a paper cut because it's something that's very meaningful to you personally, and if you can automate that it gives you the confidence — 'Hey, I saved 10 minutes a day by doing this thing.' And as you build that confidence, you then dip your toe in the water and you start doing more." — Jon-Sun Lu
At GitHub, his team built Copilot agents for list cleaning — standardizing inputs, formatting data at scale — and automated the data aggregation and querying behind monthly business reviews, saving hours each month that could be redirected to strategic work. Neither of these is a moonshot AI project. Both are paper cuts that, once automated, compounded into meaningful capacity.
This approach also builds something more important than time savings: organizational confidence. A team that has automated five paper cuts and seen each one work correctly is far better positioned to move toward more complex AI implementations than a team that tried to automate a mission-critical workflow on the first attempt and failed. For more on how RevOps teams are thinking through the build-versus-buy tension as AI tools proliferate, Episode 68 on navigating the AI tool craze is worth the listen.
One of the session's most practically useful threads was on governance in an environment where anyone can now build an application. Lu's build-versus-buy framework centers on a single disqualifying question: what's the support operating model?
"Even if you build a POC, maybe it's a front-end GUI on a cool platform or an analytics thing — are you actually gonna maintain this? Are you gonna become a product manager with your own customer support and build feature enhancements or bug fixes? And as soon as I ask that follow-up question, everyone's like, 'Oh, no. This is not my job.'" — Jon-Sun Lu
The threshold isn't whether something can be built. The threshold is whether the person or team who built it is willing to own it like a product: roadmap, support model, feature requests, bug fixes. If the answer is no, the vibe-coded POC stays a POC. If the answer is yes, the same evaluation rigor that would apply to a third-party vendor purchase should apply internally.
Feliciano echoed this directly: "We should apply the same level of rigor in how we evaluate any tool, whether it's developed internally or we're gonna spend money externally with a new vendor." An internal tool doesn't get a pass because it's free. The question of who owns it, how it gets maintained, and what the roadmap looks like is the same regardless of where the code came from.
For teams navigating the broader challenge of fixing tech bloat without making enemies, this framing is a useful addition to the toolkit — it gives RevOps a principled way to pump the brakes on internal sprawl without seeming anti-innovation.
If there was one point of absolute consensus across the panel, it was this: before you trust AI to make changes in your CRM, a human needs to be in the approval chain. Not as a temporary measure until you figure things out — as a durable best practice for anything touching compensation, account ownership, or territory assignment.
Feliciano described her team's current implementation directly: an agent proposes changes, then sends a Slack message listing what it wants to update before executing anything. RevOps reviews, approves, and then the changes go through. The reason for the conservative stance isn't lack of confidence in the technology — it's experience with the downstream consequences of errors.
"If I am touching an opportunity object, for example, and I do something to my opportunity, there is a high chance that now I've messed with someone's compensation, and those conversations are never fun. Or I do something to an account, and I change the territory on it, and now I've created a fight between two sales reps." — Ablla Feliciano
Negru reinforced this from a data governance perspective, adding a dimension that often gets overlooked: AI isn't just a consumer of data. It's a producer of data. A single poorly constrained prompt can generate thousands of records in seconds. The errors compound at AI speed, not human speed — which means the cost of removing the human-in-the-loop guardrail too early is proportionally larger.
His additional recommendation is prompt literacy as an organizational discipline, not an individual skill. When a company introduces a new AI tool, the onboarding should include practical guidance on how to prompt effectively — including simple constraints like instructing models to return null rather than hallucinate a placeholder when they're uncertain. This is the equivalent of training a new hire on how the company actually goes to market, and it deserves the same intentionality. Episode 94 on the boring work behind great AI goes deeper on exactly this kind of foundational discipline.
The panel's closing exchange on AI-assisted data cleaning was grounded in candor: none of the three companies have fully productionalized AI agents for data hygiene yet. What they do have are staged implementations, human-in-the-loop workflows, and a clear view of where AI is adding value in the pipeline.
At Inchcape, Negru's team uses AI for summarizing, normalizing, and comparing conflicting records — making recommendations about which record to keep or merge, with humans making the final call. At Fivetran, agents handle targeted enrichment problems, like assigning territory to accounts that entered the system without a country field. At GitHub, automated pipelines scan incoming account data to surface the best candidate for the canonical account record, which a RevOps team member then approves before the assignment executes.
Valdes described Traction Complete's internal use cases as a useful illustration of the spectrum: on one end, identifying junk leads by checking whether names correspond to real people, celebrities, or fictional characters — a task that would be painful to code programmatically but is straightforward for AI. On the other end, an enrichment workflow where AI agents surface suggested enrichments for human review, with the human iterating on prompts and approving outputs before anything touches the CRM.
The common thread: AI readiness in the revenue stack isn't about tool selection. It's about having data clean enough, governance tight enough, and trust built carefully enough that automation can actually deliver on its potential. Traction Complete's data agent capabilities are built specifically around this workflow — supporting de-duplication, standardization, validation, classification, normalization, and enrichment in a way that keeps RevOps in control of what actually lands in the CRM.
The recurring theme across every section of this conversation is trust — not trust in the technology, but trust in the data that the technology runs on. AI doesn't fix a broken data layer. It amplifies whatever's already there. The teams that are getting real value from agentic automation in 2025 are the ones that did the unglamorous work first: cleaning the foundation, aligning the teams, building the feedback loops, and earning confidence in the data one paper cut at a time.
Learn more about how Traction Complete helps revenue operations teams manage account hierarchies, data quality, and territory assignment — the foundational infrastructure that makes AI-driven automation worth building on.
Check out our blog, join our community and subscribe to our YouTube Channel for more insights.
