Question 01
How does AI affect B2B SaaS gross margin and valuation multiples?
Traditional B2B SaaS targets 75 to 82% gross margins. SaaS Capital and ICONIQ surveys show companies shipping AI features in 2026 reporting blended gross margins of 52 to 68%. The trade only works if TAM expands 2 to 3x or pricing power follows. Most portcos absorbed the inference cost into COGS without metering or repricing. The Q3 board deck is where the variance lands.
Why most CEOs get this wrong: they treat the AI feature as a roadmap line item, not a unit-economics restructure. Inference cost is a variable cost that scales with usage. If pricing didn't change and the feature became default, you're now running a different business model than the one the sponsor underwrote.
Right answer pattern: a per-account inference cost dashboard, a clear pricing decision (metered, tiered, or absorbed-with-rationale), and a quarterly cohort margin analysis comparing AI-feature users to non-users. If the CEO can't produce this, ask them to.
Question 02
What's the right way to measure AI support deflection without killing NRR?
Pure deflection is the wrong metric for a recurring-revenue business. The 2026 split is clean: track deflection on Tier 1 (passwords, status, billing) where 30 to 60% is achievable and the customer is happy with self-serve. Track proactive intervention on Tier 2/3, where the support touch drives expansion. Top-NRR portcos (118% Enterprise median) combine both. Optimizing for deflection alone has compressed NRR by 4 to 8 points within 18 months at portcos that ran the experiment.
Why most CSat teams get this wrong: the support org reports to a cost center owner who's measured on deflection. The NRR-owning team reports to a different leader. The AI rollout optimizes for the metric the implementer is measured on. Nobody owns the cross-functional outcome.
Right answer pattern: a joint OKR owned by support and CS leaders together: Tier 1 deflection as a cost-line target, Tier 2/3 expansion-driver lift as an NRR-line target. Reporting structure that surfaces both in the same monthly review. If the structure isn't in place, the metric is going to drift the wrong way.
Question 03
When should a B2B SaaS portco build AI in-house instead of buying?
Buy for horizontal layers: support agents (Decagon, Sierra), code assist (GitHub Copilot, Cursor), sales enablement (Gong, Outreach, Clay). The category leaders have a 12 to 24 month head start on the integrations. Build for the parts that touch your proprietary product data: in-product copilots, usage-based churn prediction, customer-specific recommendations. The build math works once the portco has a 5-plus person AI/ML team and the product surface to differentiate on. Most $20M to $80M ARR SaaS portcos buy horizontally and build into the product.
Why most CTOs get this wrong: the build instinct kicks in on the wrong side of the line. They build the chatbot (which Decagon or Sierra ships better) and they buy the in-product copilot (which is exactly where the product differentiation should live). The decision pattern flipped in the last 18 months and most build teams haven't caught up.
Right answer pattern: a written build-vs-buy framework that classifies each AI initiative as either horizontal-tooling (buy) or product-differentiation (build), with the 24-month cost on both sides. If the framework doesn't exist, the next AI roadmap meeting is going to argue the same point three more times.
Question 04
How do PE operating partners structure AI inference cost so it doesn't destroy unit economics?
AI features that pass token cost through to gross margin without metered pricing are the most common margin destroyer in 2026 SaaS portcos. The fix is a three-layer approach: cache aggressively (cuts cost 30 to 60% on repeated queries), route by model tier (use Claude Opus or GPT-5 only for queries that need them, distilled models for the rest), and price the AI feature as a metered add-on or a higher tier rather than absorbing the cost in the base SKU.
Why most CTOs miss this: the inference cost line shows up in the AWS or Azure bill, not in the gross-margin reporting line, until the CFO does the reconciliation a quarter late. By that point, several hundred customers are on a pricing tier that doesn't cover the unit cost of the AI feature.
Right answer pattern: a real-time per-account inference cost line in the BI dashboard, model-router infrastructure that defaults to the cheapest model that solves the query, and an aggressive cache layer at the prompt level. Vista's portfolio companies have standardized on this pattern. If your portco's CTO can't show you per-account inference cost on a Tuesday, the cost line is going to find you in the Q3 board meeting.
Question 05
What's the right governance structure for an AI operating partner across a SaaS portfolio?
Heidrick and Bain both flag the AI operating partner as a distinct role from the traditional tech OP. The structure that works at sponsors who've done it well (Vista, Thoma, Insight): one AI operating partner across 8 to 15 SaaS portcos, supported by a portfolio-wide vendor master agreement (so each portco doesn't re-negotiate Anthropic or OpenAI pricing from scratch), a shared model-spend dashboard, and a quarterly cross-portco standup on what's actually moved revenue.
Why most sponsors get this wrong: they treat AI as a topic the existing tech OP picks up part-time. The skills don't transfer cleanly. The tech OP knows infrastructure modernization, SaaS metrics, and DevOps maturity. The AI OP needs to know inference cost economics, model routing, RAG architecture, and the vendor landscape across 40+ active categories. The roles look adjacent and aren't.
Right answer pattern: a named AI operating partner with portfolio-wide authority, OR (for sponsors not ready to hire that role yet) a fractional Chief AI Advisor retainer that fills the same function at the portco level. The retainer model is exactly what the AI operating partner role looks like in the early years before the sponsor builds the central team.