Question 01
"What does your integration with Eclipse, SX.e, or NetSuite SuiteCommerce actually look like, three layers deep?"
The ERP isn't optional in distribution. If the AI vendor can't read pricing, inventory, and customer history out of Epicor Eclipse or Infor SX.e in something close to real time, the project will die in the integration phase nine months in. Most vendor decks show a logo grid implying full integration. The honest answer is usually "we have a connector that supports flat-file exports nightly."
Why most vendors get this wrong: they have an integration with one cloud-modern ERP (NetSuite or Acumatica) and use that screenshot to imply parity with the legacy stack. They don't have a working integration with Eclipse or SX.e. They have a roadmap item.
Right answer pattern: a working list of named distributor customers running on the same ERP version as your portco, plus a specific named integration partner if the work is done by a third party. If the vendor can't name two customers within a phone call, the integration story isn't real yet.
Question 02
"Whose data trains the model, and what's the contractual line on shared learning across your customer base?"
Multi-tenant AI vendors get smarter the more customers they have. Most distribution portcos have customer pricing, vendor cost basis, and SKU-level margin data that's a real competitive asset. If that data flows into a shared training set, the portco is paying for the privilege of educating its future competitors.
Why most vendors get this wrong: they conflate "your data is private" with "your data doesn't train the model." Those are different statements. The first is about access. The second is about the model weights. Many SaaS contracts permit the second under "aggregated and anonymized" clauses.
Right answer pattern: a clean contractual line that says model weights derived from your customer's data stay with your customer's instance and don't propagate to the shared base model. If the vendor pushes back on this with "that's not how we work," the answer is the answer, and it's the wrong one for a portco the sponsor wants to sell.
Question 03
"What's the all-in TCO including the WMS integration, change management, and the hidden integration partner fees?"
The sticker price on a distribution AI deal is rarely the real price. The portco runs a WMS (often Manhattan or HighJump) that has to be integrated. The branches need change management. The vendor has a "preferred integration partner" who shows up in month two with a six-figure scope. None of this is in the deck.
Why most vendors get this wrong: the SaaS line item is the only one with their name on it. They have no commercial reason to surface the integration partner's scope until you've already signed the SaaS contract. By that point, your negotiating room is gone.
Right answer pattern: a single TCO worksheet covering the SaaS line, the integration partner line, the internal change-management line, and the realistic ramp curve to full deployment. Ask the vendor to put their name on a 24-month all-in number. If they won't, you don't have a TCO. You have a teaser.
Question 04
"When the vendor exits (acquired or wound down), who owns the model, the data, and the inference pipeline?"
The AI vendor landscape in distribution is going to consolidate hard in the next 36 months. Half the names on the slide today will be acquired or out of business by 2028. The portco needs to know exactly what it owns and what it loses on either outcome, before the platform shift happens, not after.
Why most vendors get this wrong: they don't want to think about the exit conversation. Their team is incentivized to close the new logo. The exit-rights clause in their standard MSA is whatever their legal team thought was defensible at incorporation, not what's defensible for a PE-backed customer at exit.
Right answer pattern: explicit data portability (full historical inputs and outputs in a standard format), explicit model portability if the model is fine-tuned on customer data (weights or distillation rights), and a 12-month wind-down clause if the vendor is acquired or insolvent. Negotiate this at signing. It's almost never offered.
Question 05
"Why are we buying this instead of building it on the data team we already pay for?"
A lot of distribution portcos already have a two-to-five-person data team running on Snowflake or BigQuery, a BI layer, and reasonable engineering bench. For three of the five use cases above (forecasting, churn early warning, quote optimization), the in-house build is the right answer if the team has 90 to 120 days of capacity. The SaaS vendor is selling speed-to-deploy, not capability the in-house team can't match.
Why most vendors get this wrong: they pitch "AI is hard, you need us" when the honest answer is "AI got 10x easier in the last 18 months, and your existing data team can do this." The vendor sale is a time-to-value sale, not a capability sale, and that changes the negotiation entirely.
Right answer pattern: a build-versus-buy worksheet that compares 24-month TCO of the SaaS path versus a named in-house build, including the opportunity cost of the data team's time. For the counter-sales agent and the field dispatcher, buy usually wins on time-to-value. For forecasting and pricing, build is increasingly the right answer at scale.