"Will It Work With Our Stack?" How to Handle Integration and Architecture Objections

Technical sales objections about integration and architecture are rarely about features. They are about risk and effort: what this will cost the buyer's team to set up, run and defend. Answer the documented part yourself, ask one question to find the real constraint, show a small and proven path, and bring your sales engineer in with a precise handover.

The buyer's head of RevOps unmutes about twenty minutes in. "We already run everything through Salesforce, and we have a lot of custom objects. Honestly, I'm not sure how this would fit."

You know there's a Salesforce integration. You've seen it in the demo. You don't know how it handles custom objects, and you have a feeling that's the whole question.

You have the same three bad choices as always. Say "that shouldn't be a problem." Move on to the next slide. Or say "let me get back to you" and hope it doesn't come up again.

I dreaded that moment for years in sales. Not because the question was unfair, but because I could hear what sat behind it: the person asking would have to make it work after I'd gone.

Why are integration objections different from other technical sales objections?

Most objections question value. "It's too expensive." "Not this quarter." Our field guide to handling sales objections covers those. Security and pricing questions tell you who just joined the deal, which we looked at in when IT and finance join the call.

Integration and architecture objections are a different family. "Will it work with our stack?" is really three questions at once:

• Will it break something we already rely on?
• How much of my team's time will this take?
• Who gets blamed if the rollout goes badly?

None of those is answered by a feature list. The buyer already believes the product is useful. What they're weighing now is the cost of getting there.

These buyers also know their own systems far better than you do, and they do a lot of homework alone. Gartner found that 75% of B2B buyers prefer a rep-free experience. By the time someone asks about their stack on a call, they've often read your integration page. They're asking about the part it didn't cover.

What is the buyer really asking?

The literal question is rarely the whole question. Here are the six I hear most, what usually sits behind them, and who should own the answer.

Often you can address the real worry even when you can't answer the literal question yet. "You're worried your ops team will end up maintaining a custom sync" is something you can respond to today, even if the custom object answer needs your SE.

What can the rep answer from documentation?

More than most reps think. A large part of every "will it work with our stack?" conversation has a documented, stable answer:

• Which integrations exist and whether they're native, built by a partner or done through an API.
• What the standard data flow is: what goes in, what comes out, how often it syncs.
• Published limits on users, records, calls or volume.
• The install footprint: what gets installed, what permissions it needs, who can turn it off.
• What a standard setup looks like in the first few weeks.

If it's written down, say it with confidence and offer to send the page. Every documented answer you give yourself saves a week of waiting for an SE slot.

The line to watch is where "documented" ends and "your setup" begins. The standard Salesforce connector is documented. How it treats the forty custom objects this buyer built over six years is not. Say exactly where that line is: "Our connector syncs standard objects and custom fields out of the box. Custom objects depend on how yours are built, and I don't want to guess on that."

How do you find the real constraint behind the objection?

Ask one question before you answer. Integration objections are often stated in their broadest form. The constraint underneath is usually narrow and specific.

• "We already have X." Ask: "What does X do well for you today, and where does it stop?" You'll often find the gap you're there to fill.
• "How much work is the migration?" Ask: "What would need to work on day one for this to be worth it?" Most buyers don't need everything moved at once.
• "Will it scale?" Ask: "What volume are you thinking of in the first six months, and at full rollout?" Big numbers often turn out to be a future state.
• "We have custom objects." Ask: "Which of them would this need to touch?" Usually it's two or three, not forty.
• "IT won't allow it." Ask: "What does IT check before they approve a new tool, and who runs that review?" Now you have a process and a person, not a wall.

Then repeat back what you heard. "So the real question is whether the sync can write to your Renewal object without your team building anything?" A precise question gets answered. A vague one stalls the deal.

How do you show the path instead of promising it?

"That shouldn't be a problem" is the most expensive sentence in technical sales. It gets written into a project plan, and months later someone on the buyer's side reads it back to you.

Showing the path works better than promising the result.

A small pilot scope. Shrink the risk until it's easy to say yes to. "Let's start with one team and the two objects you named. If the sync works there, we extend it. If it doesn't, you've lost two weeks, not a quarter." It also gives your SE a real environment to test against.

A past customer on the same stack. Nothing calms an architect like hearing that someone with their setup already did this. "We have a customer running Salesforce with heavy custom objects and the same warehouse you use. I can share how they set it up, or ask if they'd talk to your team." Only say it if it's true. If you don't have that customer, say so and lean on the pilot.

Now the question has moved from "can you promise this works?" to "here's how we'll find out, safely." The buyer can take that to their boss.

When should you bring in the sales engineer, and what should the handover say?

Bring in the SE when the answer depends on the buyer's own environment: custom objects, unusual volumes, non-standard data flows, or a review with their architects. Don't bring them in for the documented part. Their time is the scarcest thing on your team, and if you'd like a deeper look at how AEs and SEs split the work, see the AI copilot for sales engineers.

The handover is where most deals lose a week. "Can you jump on a call with Acme about integrations?" sends your SE in cold, to ask the buyer everything you already asked. A good handover is short and precise:

• Stack: Salesforce with custom objects, Snowflake, Okta for SSO.
• Real constraint: sync must write to their Renewal and Contract Line objects without their ops team building anything.
• What I already said: standard objects and custom fields are supported out of the box. I did not commit on custom objects.
• Who's asking: their head of RevOps, who will own the rollout. Their architect will join the next call.
• Deadline: they review vendors on Thursday. They need a written answer by Wednesday.

Then tell the buyer exactly what happens next. "Our solutions engineer will confirm the custom object behaviour in writing by Wednesday, and join your architect on the next call." A named person and a date make "I don't know yet" sound like a plan.

What should you never guess about someone else's stack?

Four things get written into project plans, so they should never be guessed:

• Integration effort. Hours, weeks or headcount for anything beyond the standard setup.
• Performance at their scale when it's above what's published.
• Behaviour with custom setups you haven't seen.
• Roadmap dates for a connector that doesn't exist yet.

Say "That part depends on your setup, so I'll have our engineer confirm it." Never "I'm pretty sure we've done that before," or "let me get back to you" with no owner and no date.

Where Sunnyside fits

Most of the documented answers above already exist in your company, in integration docs, case studies, Slack threads and past calls. Nobody searches them while a buyer is waiting.

Sunnyside runs on your computer during the call and never joins as a bot. When a buyer asks about an integration or a data flow, it shows a short answer from your product docs, case studies and past calls, with the source on every card. When the answer depends on the buyer's setup and isn't written down, it stays quiet, so you're not tempted to read out a guess. Five minutes before the end, it shows what's still unanswered and what you promised, which is most of your SE handover already written.

As Sergio Llopis, VP of Sales and Marketing at Coderland, put it: "My sales reps are more prepared and confident when handling technical questions."

Before the call, prep checks who's joining, so an architect on the invite doesn't surprise you. After it, notes carry the open questions with owners and dates. If new reps are the ones stalling on stack questions, our guide to reducing sales engineer ramp time goes further.

Next in the technical sales series: Already Have Conversation Intelligence? What It Can't Do During the Call.

Frequently asked questions

What are technical sales objections?

Technical sales objections are doubts about whether a product can work safely inside the buyer's environment. The most common ones are about integrations, migration effort, scale and performance, custom setups, data flows and IT approval. They usually question risk and effort for the buyer's team, not the value of the product.

How do you handle the objection "we already have a tool for that"?

Ask what the existing tool does well and where it stops. Then show where your product starts, ideally with a customer who runs both. Don't attack the existing tool. The buyer chose it, and the real worry is usually paying twice or asking their team to maintain two systems.

What should a rep say when a buyer asks how much work an integration will be?

Share what is documented, such as the standard connector and the usual first steps, and be plain about the part that depends on their setup. Then offer a small first phase with a clear scope and bring in the sales engineer to size the rest. Never guess at effort or timelines for a custom setup.

When should an account executive bring a sales engineer into a technical objection?

When the answer depends on the buyer's specific environment: custom objects, unusual data volumes, non-standard data flows, or a review with the buyer's architects. Bring the sales engineer in with a written handover that names the stack, the real constraint, what you already said and when the buyer expects an answer.

How do you answer "our IT team won't allow another tool"?

Treat it as a process question, not a refusal. Ask what IT checks before approving software and who runs that review. Then share the documented install footprint, admin controls and data handling, and offer to meet IT directly with your sales engineer. Most IT teams are protecting against sprawl and support burden, not against you.