Data You Can Trust: How Pairing Rethinks HubSpot Integrations | Erin Wiggers

In this episode of the RevOps Champions Podcast, host Brendon Dennewill sits down with Erin Wiggers, Forward-Deployed AI Lead at Denamico and veteran of more than 50 HubSpot implementations. Together they tackle one of the most persistent pain points in RevOps: integrations between HubSpot and critical systems like ERPs and accounting platforms that break silently, lose data, and erode trust in the CRM.

Erin shares how AI-assisted coding unlocked Pairing, a configuration-driven, AI-native integration solution built on lessons from years of custom builds. She explains how failed records are held for review instead of lost, how mismatched dropdowns and date formats get resolved in flight, and how teams can troubleshoot their sync through custom CRM cards or by asking their AI tools directly. Brendon connects the dots to revenue leakage, the hidden cost that never shows up on a P&L. RevOps leaders, HubSpot admins, CFOs, and executives who rely on connected systems will walk away with a new standard for what integrations should deliver.

Read the full transcript.

What You'll Learn

• Why lost trust in data kills CRM adoption
• How configuration-driven integrations replace bespoke custom code
• When to use an iPaaS tool versus a parity-focused sync
• How to stop losing data when a sync fails
• How AI and MCP tools simplify integration maintenance and debugging
• The first step to know if your systems can integrate
• How broken integrations quietly leak revenue

Resources Mentioned

• Pairing by Denamico
  

Listen

About the Guest

Episode Transcript 

Introduction

Brendon Dennewill: Hello and welcome back. Today I’m delighted to welcome someone I’m honored to work with here at Denamico: Erin Wiggers, our forward-deployed AI lead. Erin is the person people turn to when HubSpot gets complicated, and I’m very excited to have her on today to talk about something she came up with recently. It’s a typical example of the overnight success that took 10 years of hard work and experience.

Erin has done over 50 HubSpot implementations, which is why she has the insight and the expertise to come up with the solutions we build for our clients. Erin, thanks so much for being here, and welcome to the RevOps Champions Podcast.

Erin Wiggers: Yeah, thank you so much for having me. I’m excited for this conversation.

Brendon Dennewill: Yes, almost as excited as I am.

Why Denamico Built Pairing

Brendon Dennewill: Erin, today we’re going to talk about a solution you’ve built over the last few months that solves something that was hard to fix until fairly recently. We call this solution Pairing. It solves one of the biggest challenges we’ve seen in implementing and integrating systems with HubSpot over the last eight or nine years: the integrations don’t always work the way we want them to. So why did we build Pairing?

Erin Wiggers: Yeah, I think over the course of building a lot of these custom integrations, you start to hear the same bits of feedback: “I noticed something was off, but I couldn’t really figure out what, and now I’ve got to go email a developer and figure out what’s going wrong.” There’s no visibility into how things are going with the integration. It always seems like such a black box. It either works or it doesn’t, and that seemed like something very solvable with the tools we have.

That’s really what I wanted to bring to this product: visibility for the client, and autonomy for them to feel like they can actually own and maintain this integration, because it’s such a huge piece of the business. It’s so important for these systems to be able to talk to each other, and to have no idea what they’re saying is kind of a non-starter.

Brendon Dennewill: So Pairing is a way to integrate two systems that are critical to a business. More specifically, we’ve been doing this for years now. When we implement HubSpot for an organization, they typically have to integrate it with another system, whether it’s their ERP, their accounting system, or whatever that other critical system is. The data has to flow freely between the two systems so that whoever it is in the C-suite, whether it’s the CRO, the CFO, the COO, or anyone else, has all the data they need to make the decisions that keep the business growing effectively and efficiently.

Who Pairing Is For (and Who It Isn’t For)

Brendon Dennewill: But let’s take a step back. Who would you say this is for, and who is it not for?

Erin Wiggers: Yeah, so I think this is for teams that want to connect to HubSpot. It’s bi-directional, but one of those directions does need to be HubSpot. And it’s for anything that doesn’t require a ton of custom logic as to what is going to sync. So, if you have a pretty good idea that all of the contacts in this system need to be in that other system, or all of the companies need to be synced over and associated to the contacts that are part of them.

Things that require a lot of if-then logic are still going to be better fits for your typical iPaaS, like your Zapiers and your Makes and things like that. But for a company that just wants parity between the two systems, where data in one is equivalent to the data in the other, this is the best possible solution, for a lot of reasons that go beyond even HubSpot’s typical native integrations, just by giving you more visibility into what’s actually happening with the sync.

What AI Changed About Building Integrations

Brendon Dennewill: Yeah, because let’s go back two or three years, before we had the ability, thanks to AI, to build this type of solution. Companies and partners like ourselves have been integrating HubSpot with other apps and software for years now, and these integrations have always been a pain point. But for some reason, people weren’t fixing the problem, and I think it’s because we didn’t think there was a solution. So what has changed in the last couple of years that you can now have a better way to integrate two systems than you had before?

Erin Wiggers: I think the way AI-assisted coding accelerates an idea is really what unlocked this whole Pairing product for us. Typically, especially when you’re an agency, you’ve been contracted to build this custom integration. They’re usually so painful, even if you’re good at them, even if you’ve done them a million times, they’re so painful to get over the finish line that by the time you’re there, you’re not thinking, “How do I do this better next time?” You’re thinking, “Please don’t ever make me do this again.”

Brendon Dennewill: Yes.

Erin Wiggers: So having AI speed up that time from “Could it work like this?” to “Yes, it most certainly can work like this” has been the biggest unlock. Prior to this, as a developer, the best option I had for a long time was to keep a library of code snippets: if it needs to do XYZ, I can use this API, and it has to have this type of authentication.

And the more I thought about it, the more I realized most integrations are just a handful of things that could be configuration-based instead of custom code. You need the authentication, you need the properties that are going to sync over, and you need any kind of formatting between the two. It should not be this hard, and it should not have to be this bespoke, where your options are the native integration or some completely custom thing that maybe lives on AWS, where only your developers have access, and if it breaks you’ll never know until you notice the data is off.

Why Trusted Data Drives HubSpot Adoption

Erin Wiggers: And I think increasingly, the risk to teams using HubSpot, especially as we’re trying to accelerate things with AI, is not trusting your data. Anything you can do to chip away at that risk matters. If someone goes into HubSpot looking for something and it’s not there, or it’s there but it doesn’t look like what they expected, that will kill adoption so quickly, and it just becomes this uphill battle everyone is trying to fight. We know HubSpot is a better solution, but if the data is not there, it’s not the solution.

So, I think having the ability to see across a bunch of different use cases is why I’ve always loved the agency environment: lots of different types of clients facing very similar types of problems. Figuring out where the overlap was and then building something we could configure rather than customize every single time was huge for this.

Brendon Dennewill: Yeah. You touched on the data quality piece there. At first you wonder, what does data quality really mean? As you alluded to, we’ve seen this over and over again, and I’m sure everyone listening has seen it too: if you no longer trust the data in whatever system you’re using, you’re going to stop using the system.

Erin Wiggers: One hundred percent.

Brendon Dennewill: And then the next question is, why do we have the system if we’re not actually using it? Or if we’re having to do all these workarounds and all this extra work to validate the accuracy of the data, is it still worth having this system? To me, that’s the exciting unlock here. You can now build it in such a way that you can actually trust the data, because when you log into your system, it’ll tell you if a sync didn’t happen, exactly why, and how to fix it, without having to contact a developer and wait until they’re available while the business continues to move.

Erin Wiggers: Right. Minimizing the downtime of the data being off or wrong or not there, minimizing that window, is critical to building trust in the system. And to your point, being able to go to a record and, right there in the same view where it’s showing your data, have it tell you, “Hey, this didn’t sync over exactly right. Here’s why, and here’s a button to push to go fix it,” is a level of autonomy for the client that we’re just not used to having with custom integrations.

As we’ve been rolling this out for clients, one of the most common sentiments has been, “Wait, it’s not more complicated than that? I thought this was going to be much harder than it actually is.” And it’s like, yeah, we’ve gotten to the point where it truly does not have to be that complicated. You can have some ownership over how you want to fix things and how you want to resolve conflicts in the data, and that’s crucial for teams.

Brendon Dennewill: And to your point, it’s brand new, right? It’s not something that was possible before.

Erin Wiggers: Right.

How Pairing Keeps Data Clean Every Day

Brendon Dennewill: We talked a little bit about the importance of clean data. Everybody gets that, and ultimately anybody who uses the system is responsible for keeping data clean. You also talked earlier about other iPaaS solutions. We used Tray for a long time, and you mentioned Zapier and Make. Those solve for what I now call the old way of doing an integration, but they’re not solving for keeping the data between two systems clean while the system is working. So tell us a little more about how Pairing helps the user keep the data clean on a daily basis.

Erin Wiggers: Yeah, so there are a couple of examples that stand out in my mind of how things can go off the rails from a data cleanliness perspective. One is a situation where you have a dropdown in one system or the other, people are adding stuff to that dropdown all the time, and now the two dropdowns don’t agree and no data is going to sync through.

A lot of people in the past have solved for that by saying, “Well, let’s just make it a string property so any data at all can go through.” That solves the sync problem, but it creates other problems downstream. Now there’s no consistency to those values, they don’t necessarily mean the same thing, and you don’t have the reporting capabilities you’d normally have with a fixed list.

With Pairing, not only can it look at your data and identify string properties that should probably be dropdowns based on the actual data you’re putting into them, but when those dropdowns get out of sync, instead of breaking entirely, it holds those records for you and tells you exactly why. For example, “ABC didn’t fit into this dropdown because ABC doesn’t exist.” Then it gives you some actual options to fix that: Do you want to add ABC to the dropdown? Do you want to map ABC to something that already exists? It prevents you from having to come up with workarounds and mental models in place of having clean data.

Fixing Date Formatting and Other Sync Workarounds

Erin Wiggers: I think that’s where a lot of people are in their data cleanliness journey. We’ve had to make some decisions based on the limitations of the tools we’re using to sync, just to have any data at all. We had a client recently where the sync worked, but the date properties had to be strings in HubSpot because they came in a different format from the other system. In HubSpot, you can’t do anything functional with a string property that you want to behave like a date.

So we had some workarounds, ways to parse the date with a calculated property or create workflows downstream to put it into a usable format. Pairing cuts out that middleman. You look at what the date was supposed to be in one system, tell it what formatting to expect and what HubSpot expects, and then you get real dates and times. So you have the functionality HubSpot offers for date properties, which makes workflows easier, more effective and more timely.

Brendon Dennewill: Yeah.

Erin Wiggers: Those are two big examples that stand out in my mind. A lot of people have made sacrifices on that front just to get data into the system. Now this takes it to the next level: not only are we going to get it into HubSpot, but it’s going to be usable in HubSpot, maybe even more so than it was in the previous system.

Brendon Dennewill: Again, these sound like such small things if you haven’t had to deal with them before. But if you have, you realize how debilitating it can be when you can no longer rely on a system because the integration stopped working.

Erin Wiggers: For sure.

What Happens When a Sync Breaks: Legacy Integrations vs. Pairing

Brendon Dennewill: The other thing you touched on earlier: with a legacy integration, when something broke, you typically had the name or number of a developer you could call to fix it. How does that work differently in Pairing?

Erin Wiggers: Yeah, this is another thing about legacy integrations that kills me, and I can’t believe we let it go for so long. With a lot of legacy custom integrations, if something breaks, best case scenario, you’ll get an alert. Worst case, it just silently fails until someone notices. But either way, that data is gone. You’re not going to get it back.

With Pairing, if data doesn’t make it to its destination, it’s held in our system so a human can review why it didn’t make it and be given some options for how to remedy that. That’s just not something that was ever really available. Even with the native integrations and things we configure for our clients, you still need a developer to come in and do some of those things.

With this system, you’re not going to lose data, which I think is so critical. You’re not having to figure out when it broke and which records changed in that window. You’re not losing anything, and you’re empowering your team to own the changes and understand what’s happening behind the scenes. If a property doesn’t match what’s expected, or a record doesn’t have all the data it needs to be created, there are a lot of mechanisms to bring it to a person’s attention so it can be handled in flight rather than after the fact.

Brendon Dennewill: Yeah. It’s very agile and dynamic, which of course at Denamico we love.

Erin Wiggers: Absolutely.

How a Pairing Integration Is Built: Configuration-Driven and AI-Native

Brendon Dennewill: Okay, for the geekier folks listening who are intrigued by how Pairing is built for a particular business integrating two critical systems: what does the build look like, and how is it different from how a legacy integration was built?

Erin Wiggers: Yeah, I think the biggest difference is that it’s configuration-driven rather than code-driven. All of the field mappings, the conflict resolution rules, and how the data is associated to each other are built into the system, so you can configure it instead of starting from scratch every time. And what’s great about it being configuration-driven is that you can create MCP tools to configure it pretty easily.

When we’re building these integrations, or when we hand one off to a client and they want to make a change down the road, their AI tools have the same tools to make the changes that need to happen in that configuration. It speeds everything up when you remove the barrier of having to learn all the buttons to push in an app. You can just go into your favorite chat, whether that’s Claude or even Breeze, and say, “Something didn’t work. Why? What went wrong? Where is this record?” Those tools can see into the integration and give you answers you can actually take action on.

So it’s config-driven, and it’s AI-native in that you can use AI to help with the configuration, maintenance, debugging and troubleshooting. All of that is built in to be user-friendly, which I don’t think has ever been said of a custom integration.

Brendon Dennewill: Yeah, especially that combination of being user-friendly, incredibly efficient to build and maintain, and so much more effective than a legacy integration might have been. To your earlier point, with legacy integrations, if something had gone off the rails three months ago, you still might not know about it today.

Erin Wiggers: Right.

Brendon Dennewill: It’ll only come up when someone runs a report, whether it’s in the ERP or the CRM, starts comparing, and realizes there’s a discrepancy in the data. And to your point, you cannot recover the data that’s been lost over the last three months. I mean, you can, but it hasn’t served you.

Erin Wiggers: Exactly. It’s wild to think that the only option for some custom integrations is, if it breaks, hope you notice. Hope someone is looking for that data sooner rather than later so it can be brought to someone’s attention.

Alerts, HubSpot Tasks and Custom CRM Cards

Erin Wiggers: That was another big solve in Pairing: who gets alerted, and under which circumstances? Not only can it email whoever needs to know, it can also create tasks in HubSpot for the admins, so they see, “Oh, this didn’t sync. Here’s why. Let me go fix that,” or escalate it to whoever needs to see it. That way everyone has more visibility into, and ownership of, the data the business needs.

Brendon Dennewill: Yes. I was just thinking, some companies have an internal RevOps team, and others don’t and might rely on us for some of that. But even for companies with RevOps teams whose job is to make sure these syncs are working, it’s sometimes hard. Even for them, this seems like an attractive solution.

Erin Wiggers: For sure. One of my favorite features we added is the custom CRM cards in HubSpot, because that’s where the people using the data are going to be in their flow of work. One issue I’ve always had with building custom integrations is that you need to create custom records or custom ways to see all of the properties that should have synced and all of the associations that should have been created.

It was doable in HubSpot because HubSpot is highly configurable, but it was time-consuming, and I was still relying on myself not to leave off any properties, or to add one if we added it down the road. These CRM cards have been so helpful in setting things up for clients, to be able to show, “Here are all the properties. This is exactly what we were expecting, because nothing got held out, and it created all of the associations.” There’s no need for a ton of ancillary setup just to understand whether it’s working. You can just go in and see.

The Best Use Cases: Any System With an API

Brendon Dennewill: Right. Let’s get into use cases a little bit. Having done this a few times now using Pairing, where do you see the most obvious use cases for companies that have HubSpot plus one other system? Salesforce is obviously a very obvious one. But what other systems, tools or apps do you see as really important integrations for HubSpot users?

Erin Wiggers: Yeah, I think the key for me is that it works with anything that has an API, and that’s something you can easily Google about any system you’re working in. As a developer, when I get asked if a custom integration is possible, the first thing I do is check whether it has an API. More companies are prioritizing API access, and a lot of that has to do with AI and MCP tools needing that same infrastructure.

So even if something doesn’t have a connector in the marketplace or in your iPaaS system, as long as it has an API, it can play ball with our system. I think that unlocks a lot of people who may have thought this just wasn’t possible for them.

The other piece is teams that are very active in their systems. If people are changing things, that’s not necessarily a bad thing. Adding options to your dropdown shouldn’t tank your business; that should be helpful to what you’re trying to achieve. For teams that are so active in the tool that these kinds of integrations have been prohibitive, because they needed a set-it-and-forget-it configuration, this is a great tool to unlock that and enable the agility you need in both systems.

First Step: How to Know If Your Integration Is a Fit

Brendon Dennewill: So for anyone interested in solving this painful problem of integrating two systems, one of them being HubSpot, what’s the first step someone should take to know if their particular scenario is a fit?

Erin Wiggers: Yeah, I think check for an API. If you want to start somewhere, start with the HubSpot native connectors, but don’t be discouraged. If there’s an API, or an SFTP we can use, Pairing is set up to connect to just about any other system, even on-prem systems. Our goal was to make whatever plugs into HubSpot as flexible as possible, so the tools you need for everything else, like the property mapping and the formatting and all of that downstream stuff, pretty much stay the same.

So really, it’s just figuring out if there’s that API capability. From there, call us. Let us help you get set up in the system so you can be one of our clients saying, “I thought this was going to be more difficult,” because that’s the best part of my day.

Asking Plain-Language Questions About Your Integration

Brendon Dennewill: That’s awesome. Erin, I can’t think of anything else. Is there anything you still want to make sure you share about Pairing that we haven’t talked about yet?

Erin Wiggers: No, I think it’s a lot of the utility of how it handles the data and how it enables the team. I’m really proud of how all of that works. Things you’d normally have to talk to a developer about, or talk to your account strategist, who then talks to the developer in a game of telephone, you can now handle by having a conversation in whatever chat you’re already using.

You can troubleshoot your integration, understand what has synced over, find out when it last synced, or ask how many times one record has been updated over the last six months. Being able to ask granular questions of your data and get plain-language responses you can act on is the next level. Once you get past “all my data is here and it’s usable,” you can really level up and start to understand your data in ways you couldn’t before, and I think that’s going to make a lot of teams really happy.

As a developer, I always feel bad when I don’t have the time and bandwidth to answer questions that should be a quick answer. So giving clients this tool to go around me and get the answers they need is something I’m also really proud of.

How Poor Integrations Cause Revenue Leaks

Brendon Dennewill: Yeah, that’s awesome. I haven’t shared this with you yet, but I’ve been doing some work to figure out the most common issues we see with clients when they start working with us, or the reasons they came to us. Looking back at the last five years of data, the number one reason we’ve boiled it down to is leaking revenue.

As I was thinking about that, I wondered how much leaking revenue is due to a poor integration. Take the things we’ve talked about: if something went wrong with the sync between two systems three months ago, what does that cost the business in that three-month period? And then we touched on the lack of trust in the data. What is that costing your business?

This doesn’t show up in a P&L. It’s inefficiency, loss of revenue and loss of effectiveness that isn’t measured anywhere. It just silently drains your revenue, which is why I’m so excited about this product. It’s going to help fix one of the biggest holes in the bucket we’ve seen so far.

Erin Wiggers: Absolutely. You can’t plug the hole in the bucket if you can’t see the hole in the bucket. So step one is covered, and we can get your teams in a position to start shoring up those revenue systems so you’re not leaking revenue. You’re not missing out on cross-sell emails because the product a customer bought didn’t sync over. There are so many use cases where just one thing going wrong is money left on the table, and this is a great way to combat that.

Brendon Dennewill: Yeah. And part of the irony is this: whether you’re the CRO, the COO, the CFO or any other person responsible for revenue, or for reporting revenue and profitability in a business, one of the reasons you agreed as a leadership team to invest in these systems, and then integrate them, was to get visibility and predictability into the business.

Erin Wiggers: Yeah.

Brendon Dennewill: So if you’re not getting that value, why keep using the system in the first place? I’m very excited to make this available to so many more businesses, because I believe we can plug a lot of the holes in their buckets.

Erin Wiggers: Absolutely. I’m excited.

Closing

Brendon Dennewill: Erin, thanks so much for joining me today. I’m very excited to see the value Pairing is going to create in the market. Thanks again.

Erin Wiggers: Yeah, absolutely. Thank you so much.

Brendon Dennewill: See you later.

Subscribe