Integrations · Sales · Positioning
Integrations close deals, not your novel algorithm
Buyers don’t pay for clever internals. They pay to make your product disappear into their stack — identity, data, and workflow. Ship the connectors, package them well, and your conversion, contract size, and retention move.
7 min read
A prospect says “we love the demo” and then sends a spreadsheet of security and integration questions. If you can check boxes on identity, data flow, and workflow, the deal advances. If not, the pilot stalls and the calendar goes quiet. That isn’t because your core tech is weak. It’s because the buyer is paying to reduce integration risk more than they’re paying for your internal novelty.
What buyers actually buy
A buyer is on the hook for three things:
- Can people log in the company way, and can accounts be provisioned and deprovisioned automatically?
- Can data get in and out without spreadsheets and weekend scripts?
- Can the product notify, ticket, and report where work already happens?
If those three fit, procurement and security can say yes. If they don’t, your champion is asking colleagues for exceptions. Exceptions are slow and political. Most die.
Your algorithm matters for differentiation and margins. It rarely carries the purchase alone. The stack fit does.
Where deals die
There are repeatable choke points long before anyone evaluates model quality or ranking metrics:
- Identity. No SSO means a security red flag. No group-based roles means IT has to hand-edit access. No automated provisioning means offboarding risk.
- Data ingress. If the system-of-record can’t feed you via a supported connector, the pilot becomes CSV gymnastics. High friction, low adoption.
- Data egress. No way to land outputs back into the data warehouse or a queue? Your value is trapped, so teams won’t build around you.
- Workflow hooks. No way to create tickets, post to chat, or update a record? Your product becomes a sidecar tool, not a system people live in.
- Governance. No audit log, no admin APIs, no retention controls? Security review pauses everything.
You’ll recognize the pattern: none of this is novel. All of it is table stakes to someone trying to run a production system in a real company.
flowchart TD
A[Demo] --> B{Integrations met?}
B -- No --> C[Pilot stalls]
C --> D[Loss or delay]
B -- Yes --> E[Go live fast]
E --> F[Expansion path]The integrations that move real numbers
If you have to choose, prioritize integrations that clear approval and create daily usage. These pull revenue forward:
Identity and access
- Single sign-on (SAML or OIDC)
- Automated provisioning and deprovisioning (SCIM)
- Role-based access with groups
- Audit logs for admin actions
Data in
- Connectors to common data warehouses, blob stores, and message buses
- Pull from upstream APIs with delta sync and backfill
- Secure file drops for teams still living in CSV
Data out
- Sink to the buyer’s warehouse or lake
- Webhooks for event streams
- Batch exports that can be scheduled and verified
Workflow touchpoints
- Create or update records in the CRM or ticketing system
- Post notifications to chat
- Calendar or doc hooks if your product schedules or produces artifacts
Treat “marketplace logos” as sales collateral, not as the product. The product is a connector that sets up in minutes, survives API changes, retries cleanly, and has an admin page that explains what it’s doing.
Build order: what to ship first
You can’t build every connector at once. Triage ruthlessly:
- Anchor to the system-of-record. For the job you do, where does the truth live today? Build that ingest first.
- Land where decisions get taken. Where will someone act on your output? Build that egress early so value shows up where work already happens.
- Pick the identity path your segment already uses. Mid-market might be lighter-weight. Enterprise will expect SSO and SCIM before a pilot.
- Ask discovery questions that expose blockers explicitly:
- Which identity provider do you use?
- Where does this data live now? Where should it land after?
- Which team needs notifications and where do they want them?
- Who will own provisioning and audit?
Every “we can start with CSV” you accept should have a dated plan to replace it. Otherwise, you’ve committed to support a manual process that scales only with your support queue.
Packaging and pricing: earn on fit, not on pain
Integrations are levers. They move conversion, discounting, and expansion.
- Gate procurement-critical features at the tier designed for procurement. SSO, SCIM, audit logging, and admin APIs belong where legal and security live. That tier can carry longer terms and less discount pressure because it removes real risk.
- Keep adoption-critical workflow connectors reachable. If posting to chat or creating tickets is how daily users feel value, don’t hide that behind a wall that your buyer can’t climb without an internal campaign.
- Charge for truly new connectors — but write the contract so you can say yes. A paid “build and certify” line item with:
- Exact scope (auth method, sync directions, objects, fields)
- Milestones (dev access, sandbox, test plan, UAT)
- Support window and response expectations
- Clear language that the connector, once built, is generally available
- Price upgrades on operational guarantees, not just existence. “This sync has monitoring, on-call, and a recovery runbook” is a reason to pay more.
If a prospect asks for a niche connector that won’t generalize, either price it as professional services with no promise of ongoing maintenance, or decline and propose a supported alternative path (webhooks, file drops, reverse ETL). Saying “no” early is cheaper than carrying an anchor integration that never pays back.
Architecture that protects your margin
The wrong integration architecture prints support tickets and burns engineering time. The right one lets you say “yes” without dreading it.
- Create a connector framework. One code path for auth, secrets storage, scheduling, retries, and metrics. New connectors plug a mapping layer, not a fresh stack.
- Idempotency and backfill. Every write should be safe to retry. Every sync should be resumable from a checkpoint.
- Polling vs events. Prefer webhooks or event subscriptions when they exist. Fall back to polling with backoff and change detection. Document the lag honestly.
- Explicit mappings. Give admins a UI to map fields and object types. Hardcoding assumptions becomes a migration later.
- Health and observability. Per-connector dashboards, last successful run, error counts, and a status page you’re not afraid to show a customer.
- Secrets and tenancy. Per-tenant credentials with rotation, scoping, and least privilege. Don’t centralize access in a way that turns one breach into many.
- Versioning. Upstream APIs will change. Negotiate and store the version you integrate with, and test upgrades in a sandbox before rolling.
None of this is glamorous. All of it is cheaper than incident calls after a connector silently drops records for a week.
How to sell integrations without promising the moon
You only get in trouble when “works with X” is a sentence and not an artifact. Two habits keep you honest and help close:
- Publish a living compatibility matrix. For each integration: auth method, sync directions, supported objects, known limits, and setup time. Keep labels boring and precise.
- Make a certification checklist part of the pilot. Pick concrete, verifiable steps: authenticate; pull N records; create one, update one, delete one; verify webhook receipt; validate an end-to-end workflow that includes your product.
Treat the pilot as a production rehearsal. The fastest way to a signature is a day-one experience that looks like month three.
When to partner instead of build
There’s a middle path between “we’ll build it” and “sorry, no”. An integration platform or a specialized partner can:
- Cover long-tail connectors you won’t productize soon
- Absorb API churn and auth quirks
- Provide prebuilt transforms and templates
The tradeoff is control, unit cost, and latency. Use partners for breadth while you build depth for the connectors that drive most deals. Keep the boundary clean so you can migrate a partner-led connector in-house when it starts showing up in every opportunity.
Measuring the right thing
Integration work feels invisible. Make it legible:
- Track opportunities blocked by integration gaps, and sort by total pipeline affected
- Measure pilot time-to-first data and time-to-first workflow action
- Monitor connector-driven support volume and error budgets
- Review expansion events tied to new connectors going live
Those signals tell you what to build next far better than a feature vote board.
The quiet commercial truth
A buyer can believe your algorithm is better and still walk if you don’t fit their stack. The reverse also holds: a merely good core, wrapped in excellent integrations, wins because it lowers adoption risk, reduces internal coordination work, and shows value where people already live.
Ship the fit. The cleverness will still be there tomorrow. The deal won’t.