"It Has to Integrate With [Their System] or It's a Non-Starter"

The sentence, and the two completely different things it means

You are twenty minutes into a good call. The prospect is nodding. You have made it past pricing without a flinch. And then:

"This all looks great, but it has to integrate with our ERP or it's a non-starter."

Most reps hear that sentence and immediately do one of two things. They panic and start promising, or they deflate and start wrapping up. Both are wrong, because that sentence has two completely different meanings and they sound identical coming out of a prospect's mouth.

Sometimes it is a genuine hard requirement. There is a system of record, data has to land in it, and a human being downstream is holding a broken process together with manual work. If you can't move that data, you genuinely cannot help them, and no amount of skill on the call changes that.

And sometimes "it has to integrate" is the polite version of "I do not want to change how my team works." It is a socially acceptable objection. Nobody gets criticized in an internal meeting for insisting on integration. It sounds rigorous. It sounds like due diligence. It is much harder to say out loud "I have eleven people who have used the same screen for six years and I do not want to run that change project."

Your entire job in the next four minutes is to figure out which one you are looking at. Not to overcome it. To identify it. Because the moves for each are opposite, and picking the wrong one is how deals die slowly over six weeks of email.

Four questions that tell you which one you have

Do not ask "why is that important?" It is a therapist question and experienced buyers hear it as a stall. Ask about the mechanics instead. People who have a real requirement can describe the mechanics instantly, in detail, without pausing. People who are using integration as cover cannot, because they have not thought about it at that level — they have only thought about it at the level of "we don't want another system."

What data actually has to move

"When you say it has to integrate with NetSuite — what specifically has to be in NetSuite that would otherwise be in our system?"

A real requirement produces an answer like: "Closed-won opportunities, with the line items, because that's what triggers the invoice." Specific nouns. A named object. A downstream consequence.

Cover produces an answer like: "Well, everything, really. We want one source of truth." One source of truth is not a requirement. It is a slogan. When I hear it I know I have not found the real objection yet, and I keep going gently, because the person is not lying to me — they usually have not examined it themselves.

In which direction

"Does that data need to flow into NetSuite from us, out of NetSuite into us, or both ways?"

This is the single most clarifying question in the whole sequence and almost nobody asks it. A huge number of "integrations" that get demanded on sales calls turn out to be one-directional reads — the team wants to see account data that lives somewhere else, and they want to see it because looking it up manually is annoying. That is a real problem worth solving, but it is a very different engineering problem from a bidirectional sync, and it is often solvable without an integration at all.

Bidirectional, real-time, with conflict resolution, is a hard requirement almost every time. Somebody has already thought hard about it. Ask who, and get that person on the next call.

How often

"How current does it need to be? Live as it changes, hourly, once a day, once a week?"

I have watched a lot of deals where the buyer said "real-time integration" and, when asked this question, said "honestly, if it's there the next morning, that's fine." Nightly is not the same product as real-time. Nightly can often be a scheduled file drop that takes an afternoon to set up. Real-time is an API build.

When the answer is "it has to be immediate," ask what happens in the minutes in between. If nobody can name a consequence, the urgency is aspirational.

Who breaks if it doesn't happen

"If this data didn't move automatically — who's the person who ends up doing it by hand?"

This is the question that decides it. A genuine hard requirement always has a named human at the end of it. "Dana in billing." "Our two ops coordinators." "Me, on Sunday nights." The moment a name comes out, you are in a real conversation, because now you can talk about how much of Dana's week you can give back, and that is a conversation that closes.

If nobody can name the person, you are looking at a change-management objection wearing an integration costume. And the response to that is not a technical answer. It is a conversation about what the first thirty days look like, who has to learn what, and what happens to the workflow people already know. Trying to solve a change-management fear with an API roadmap is like fixing a limp with a new pair of glasses.

Run those four questions in order and you will know which deal you are in before you have to commit to anything. It takes maybe three minutes. I have never regretted spending them.

The four honest answers when you don't have the integration

Let's say you ran the questions and it is real. They need data to move, it is bidirectional, it is daily, and Dana is doing it by hand. And you do not have the connector.

There are exactly four honest things you can say. I am going to rank them the way I have actually seen them perform, best to worst, and the ranking will surprise most reps because it is close to the reverse of what people instinctively reach for.

1. CSV plus a defined workflow

This one closes more often than anything else on the list and reps are embarrassed to offer it. Don't be. Most of the world runs on scheduled exports and somebody's Tuesday morning.

The reason it works is not the file. It is the workflow around it. "No file sync" is a weak answer. Here is a strong one:

"We don't have a native NetSuite connector today. What customers in your position do is export closed-won from us on a schedule — it's a saved view, one button — and drop it into the import NetSuite already accepts. Dana does it once a day and it takes her about as long as it takes the coffee to brew. Compared to what she's doing now, which is retyping line items from two screens, that's the trade. If in six months the volume makes that painful, we talk again about a real connector, and by then you'll know exactly which fields you actually need."

That is honest, specific, and it makes the manual step small and bounded instead of vague and infinite. The reason CSV fails when reps offer it is that they offer it apologetically and without a defined process, so the buyer's imagination fills in the worst possible version.

One rule: never offer this without naming who does it and how long it takes. An undefined manual step is an objection generator.

2. Middleware

Zapier, Workato, Tray, Mulesoft, whatever the account already owns. This closes well when — and only when — they already own the tool and have somebody who knows it.

The question that unlocks it: "Do you already have anything in the stack for moving data between systems? Anyone in-house who builds those?"

If they say yes and name a person, you are in good shape, because you are no longer asking them to accept a gap. You are asking them to use a capability they already paid for. If they say no, be extremely careful. Recommending they buy middleware to make your product work is asking them to buy two things to solve one problem, and it makes your deal the reason for someone else's budget request. That deal stalls.

Also: never say "it works with Zapier" without checking which triggers and actions actually exist. Getting caught on that in a technical call is unrecoverable, and technical buyers check.

3. Native connector on the roadmap

This is the one every rep reaches for first and it closes the least often of the three viable options. It also carries the highest risk, which I will get to in a minute.

It can work, in one specific shape: when the connector is genuinely in build, you can name what exists today versus what is coming, and you scope the deal so that nothing the customer is paying for depends on the thing that has not shipped. That last part is the whole trick. If they can get value from day one without the integration, the roadmap is a bonus. If the value is contingent on the roadmap, you have sold a promise, and promises get renegotiated at renewal by someone who was not on this call.

4. Walking away

This one belongs on the list because it is sometimes the correct answer and almost nobody uses it.

"Based on what you've described — bidirectional, real-time, and it's driving your billing — I don't think we're the right fit right now. I'd rather tell you that than spend your quarter proving it. If your requirement changes, or if you end up looking at the read-only version of this, call me."

I have gotten more inbound referrals from that sentence than from almost anything else I have said on a sales call. It costs you a deal you were not going to win and buys you a person who trusts you. And in my experience a meaningful number of those people come back, because requirements soften and vendors under-deliver.

The systems admin nobody invited

Here is the version of this objection that actually kills deals: it does not come from your champion. It comes in the middle of the demo, from a person who joined the call four minutes late and was not on the invite.

You will know them immediately. They are the only one asking about authentication. They want to know where the data is hosted. They ask what happens when the API rate-limits. They are not hostile — they are the person who will have to support this at two in the morning, and they have been burned before by a vendor whose salesperson said "yes, it integrates" and meant "we have a webhook."

The instinct is to route around them and keep selling to the person who invited you. That instinct is fatal. This person cannot approve your deal, but they can kill it in one Slack message after the call, and they will, because their credibility is on the line and yours is not.

What works is to hand them the floor on purpose. "You're the one who'd own this if it breaks — I'd rather answer your questions first and then get back to the workflow. What's the thing you most need to know?" Then answer precisely, and when you do not know, say the words "I don't know, I'll get you the exact answer from our engineer by tomorrow" and then actually do it. Precision is the currency with technical buyers. Enthusiasm is not.

This is the same dynamic as a demo where the interruptions start early and never stop, and it is why the manufacturing demo script for plant managers who interrupt treats interruption as information rather than an obstacle. The same is true in freight, where you are usually presenting to a room actively looking for where the thing breaks and the integration question is the first probe. In both cases the person testing you is not your enemy. They are the only one in the room telling you the truth about what implementation will actually involve.

One practical move: when you know an admin will be on the call, ask your champion beforehand who owns the systems and get them invited. An admin who was invited behaves completely differently from an admin who found out about your product from a calendar hold.

Why a roadmap date is the most expensive sentence in the deal

"That's on the roadmap for Q3."

I want you to feel the weight of that sentence, because it is the most expensive thing most reps say all quarter.

Here is what happens. The buyer writes it down. They repeat it internally to justify the purchase. It goes in someone's business case. Then Q3 arrives, engineering has reprioritized for reasons that are entirely legitimate and have nothing to do with this account, and now your customer's credibility is damaged inside their own company because of something you said in a demo. They defended you. You cost them.

The damage is never contained to that feature. It contaminates everything else you said. Every claim you made about performance, security, support — all of it gets re-examined through the lens of the promise you missed. And in industries where buyers have already been burned, that lens is permanently on. Anyone who has run a clinical demo knows this, which is why the healthcare demo script written for a CMIO who has already killed two vendors assumes you are being evaluated on how you handle what you cannot do. Telecom is the same story — a room that has already been oversold on AIOps is listening specifically for the roadmap promise, because that is the shape of the last lie they were told.

What to say instead: "I'm not going to give you a date, because I've seen what happens when vendors do that and it moves. Here's what exists today. Here's what's actively in build, which I can show you. And here's what's a request with no committed timeline. Buy on the first bucket. If the second one lands, good."

Buyers do not punish you for that. Serious ones exhale, because you just told them something a vendor rarely tells them, and everything else you say gets graded on a better curve for the rest of the cycle.

Selling on what exists is slower and it is smaller and it renews. Selling on what is coming closes faster and it churns, and you will spend the churn quarter explaining yourself instead of prospecting.

What I'd do next

If you take one thing from this: the integration objection is a diagnostic question, not a closing problem. Four questions, three minutes, and you know which deal you are in.

The hard part is that you have to run those questions live, under pressure, while a technical stranger stares at you, without sounding like you are stalling. That is a reps-under-load skill and nobody gets it from reading about it. It is why I built DrillCall — so you can practice the systems admin who joins late and asks about rate limits, and the champion who says "one source of truth," until the four questions come out of your mouth in the right order without you having to think about it. Run that drill a dozen times before your next technical call and you will notice the difference in the first thirty seconds.