Talking AI with a CTO: Don't Sound Like a Vendor Pitch

Talking AI with a CTO: technical depth is your ticket in, but the business language is what decides whether you stay at the table. The author observed the same pattern across numerous executive briefings: those who lose the room start with capabilities, while those who win start with a question.

One Opening Question That Unlocks Every Real Conversation

The opening question the author offers is blunt: "What is the most expensive thing you do repeatedly that doesn't create any competitive advantage?"

This question works because it threatens no one and doesn't presume you already know the answer. It forces the other person to actually think — and once an executive starts thinking alongside you, they are already psychologically engaged in the conversation. Common answers include: month-end close and reconciliation eating 40 person-hours, vendor invoice processing requiring manual PDF entry, and 70% of internal IT tickets being answered by just five responses.

Each one is a real problem with a real cost. Real cost means ROI can be calculated, and that is exactly the conversation you want to have.

The author also provides a complete script covering three typical responses. When the CTO names a pain point directly, follow up by asking about headcount and fully loaded cost per cycle, turning it into your ROI anchor. When they say "everything is a priority right now," don't back down — narrow the scope: "If nothing changes in two years, which process will still hurt as much as it does today?" When they enter skeptic mode and worry about AI accuracy and data exposure, don't defend AI — agree and redirect: "You're right to worry, most deployments skip the guardrails. What I'm proposing is an automation with explicit rollback conditions, AI is just an implementation detail, and the outcome is fewer manual errors and faster cycles."

Technical fluency is the ticket into the conversation; business fluency is why you get invited back.

What the CTO Is Actually Evaluating

Once you've named a real problem, the CTO is really only doing three things while you talk.

Risk. A CTO's professional responsibility is to keep systems running and keep the company out of the news. Before caring about what it can do, they need to know who's accountable when things go wrong.

Cost. You're competing with everything else on the roadmap. One concrete number — "eliminate X hours of Y per year at a fully loaded cost of Z" — is worth more than a three-page capability architecture diagram.

Competitive advantage. "Your competitors are already doing this" shifts the question from "should we invest" to "can we afford not to" — two completely different decision trees, and the latter almost always leads to a yes.

The author lays out the order of the three frameworks: business outcomes first, technical mechanics only if asked; risk before upside, failure modes before the upside story; pilot scope before general capabilities — not "what can AI do," but the specific thing, the specific scope, and how you'll know it worked. Follow this order and falling into the attention-mechanism rabbit hole becomes structurally impossible.

What "Losing the Room" Looks Like

The author identifies two signals. The first: the other person says "that's interesting" and then starts talking about AI strategy. Strategy mode means you're selling a concept rather than a solution, and you'll get a follow-up meeting invitation that never happens. The second is worse: they start asking about other vendors. This means you've triggered the procurement reflex rather than the problem-solving reflex, and you're now in a competitive bid evaluation you never wanted to be part of.

Interestingly, a CTO who is skeptical of AI is actually easier to handle. Skeptics ask harder questions and force you to be precise. With a skeptic, don't defend AI — agree with their judgment that AI is overhyped, then describe the specific automation you want to build. "We can eliminate 80% of the manual matching steps in vendor invoice processing" is a claim about automation, not about AI. AI is the implementation detail. Once it works, this skeptic becomes your strongest internal ally.

The "procurement reflex" refers to the standardized reaction that forms once a company's procurement process is triggered: the need is routed into tendering, price comparison, vendor onboarding, compliance review, and so on, with decision-making authority shifting from the business owner to the procurement department, typically on a timeline measured in months. Once a CTO says "compare this with a few other vendors," the nature of the conversation shifts from problem-solving to vendor selection, and technical advantages get compressed into a single line on a quote. The opposite is the "problem-solving reflex": the other person focuses on whether your solution can close the loop on their pain point, how risk is covered, and how quickly results will show. Typical triggers for the procurement reflex include: showing general capabilities too early, giving vague scope, an unclear pricing structure, or letting the conversation stay at the conceptual level. The way to avoid it isn't to dodge procurement, but to anchor the discussion on a specific, measurable use case with a budget below a single-approval threshold.

The Pilot Scope Formula

When the conversation is going well and they ask "what would you start with," you need this formula: 6 weeks, one use case, predefined success metrics, under $50K, rollback plan.

• Duration: 6 weeks max. Short enough to approve without a multi-quarter commitment.
• Scope: One use case, one team. Not "AI for finance," but "vendor invoice matching for the AP team in region X."
• Success metrics: Named before the pilot starts, measurable, agreed by both sides. "80% reduction in manual matching errors" rather than "improve accuracy."
• Budget cap: No more than $50K all-in. This is the single-approver threshold at most enterprises; exceed it and procurement gets involved, and procurement means a six-month delay.
• Rollback plan: Written down before kickoff. "If the error rate exceeds X in week three, we revert to the current process." This eliminates the CTO's biggest objection before they even raise it.
• Decision point: A go/no-go decision in week three, not week six. A midpoint gate shows you're not trying to trap them with sunk costs.

The author notes the SAP version is especially persuasive, because SAP environments have concrete, expensive, well-documented problems. Vendor invoice processing from PDF to SAP is one of the best AI pilot candidates in enterprise software: it's manual, it causes payment delays, and the three-way match error rate is a known cost center. AI document extraction can eliminate 80% of matching errors and cut processing time from days to hours — a number that's specific, auditable, and can close the pilot. A second SAP entry point is natural-language querying over SAP report data, letting executives ask "what's the gross margin by region this quarter" without waiting in a BI request queue. SAP AI Core makes this technically straightforward, and the business case speaks for itself — the constraint in most SAP environments is decision time, not technical complexity.

"Three-way match" is a core control in the accounts payable process: the purchase order, the goods receipt/service confirmation, and the vendor invoice must agree on quantity, unit price, and amount before the invoice can be approved for payment. Any mismatch creates an exception that requires manual review, and this is precisely the most costly and error-prone part of invoice processing. Common exceptions include quantity discrepancies, price deviations, missing receipt records, and duplicate invoices. Because the three-way match rules are clear and the criteria are quantifiable, it is naturally suited as a landing scenario for AI document extraction and automated verification: the model extracts fields from PDF invoices, automatically compares them against the purchase orders and receipt records in SAP, and routes only genuinely questionable exceptions to a human. Both the error rate and the processing cycle are data that already exist in the system, so the benefits can be measured precisely — which is why the author calls it one of the best pilot candidates.

"SAP AI Core" is the AI runtime and lifecycle management service on SAP BTP (Business Technology Platform), used to deploy, scale, and monitor models and connect securely with SAP application data. Its significance lies in putting AI capabilities inside the enterprise's existing permission, audit, and data governance systems, rather than standing up a separate external pipeline. For a CTO, this means data stays within the boundary, access is role-controlled, and calls are traceable — directly addressing data exposure concerns. In the natural-language query over SAP reports scenario, AI Core handles hosting and orchestration of the model service, while the underlying data remains governed by SAP's semantic layer and authorization mechanisms, making it technically feasible and compliance-explainable. Understanding this helps you reframe "AI" in the conversation as a controlled platform capability rather than an uncontrollable black box.

Self-Check Before You Leave the Meeting

The author closes with three self-check items: can you state the specific business outcome in a single number before describing any technology; do you have the risk framework ready — what could go wrong, who's accountable, how you'll catch it early; have you loaded the pilot formula — use case, 6-week scope, predefined success metrics, rollback conditions, budget.

There's also a "callback metric": after the conversation, ask yourself — did I leave them with something concrete to think about, or something vague to consider? "I'd like to show you a 90-second demo using your data to show what invoice automation looks like — can you give me 20 minutes next week?" is concrete. "We should discuss how AI can benefit your architecture" is vague. One is a next step; the other is a polite dismissal.

The author emphasizes the importance of the demo: nothing kills executive skepticism like watching your own data produce the right answer in a system that didn't exist last week. Build the demo before the second meeting, not after project approval. The demo itself is how you earn the approval.