Most leadership teams get handed an AI proposal after someone has already decided the answer is yes. By that point the framing is set, the comparison is to doing nothing, and the questions that would actually surface risk tend to feel impolite. That is not a technology problem. That is a process problem, and it is fixable before you sign anything.
Over $547 billion of the $684 billion invested in AI in 2025 missed its intended targets, according to RAND Corporation. That’s not a technology problem. It’s a communication and alignment problem. The people approving the budget didn’t know what to ask, and the people pitching the project didn’t tell them.
Why So Many AI Explanations Fail
The person explaining AI value to you almost always has a financial stake in your yes. That doesn’t make them dishonest, but it does mean their explanation is optimized to close, not to inform.
The Vendor Incentive Problem
An agency pitching AI integration earns revenue when you approve the project. A consultant earns day rates as long as the project runs. Even an internal champion pushing for AI adoption has a career interest in getting a yes. None of these people are neutral. A good AI explanation should make it easier to say no if the fit is wrong, not harder to resist the pitch. If the explanation makes the decision feel inevitable, that’s a signal.
The Pilot-to-Production Gap
88% of AI pilots never reach production, according to McKinsey’s State of AI 2025. One in eight prototypes becomes an operational tool. That means the demo you’re watching, which works in a controlled environment with clean data, has an 87% historical failure rate before it ships. The demo is not the product. Ask specifically: what has to be true for this to work in our actual environment, with our actual data?
What a Legitimate AI Value Explanation Looks Like
There’s a short test. Can the person explaining the project answer these three questions in plain language?
- Which specific metric will improve, and by how much?
- When will we see that improvement?
- What does failure look like, and what happens then?
If any answer is vague, ask it again. Vagueness at the proposal stage compounds into scope creep, sunk costs, and finger-pointing at delivery.
Start With a Metric You Already Track
Any AI integration worth approving should tie to a number you already care about. Revenue, hours spent on a specific task per week, cost per customer support resolution, order processing time. If the person pitching you needs to introduce a new metric, “AI efficiency score,” “automation maturity index”, to show the value, that’s a red flag. New KPIs are not proof of value. They’re a way to define success after the fact.
A real example: a 12-person professional services firm was pitched an AI document processing tool. The vendor showed a demo that reduced contract review time by 70%. The firm’s actual bottleneck wasn’t contract review, it was client intake. The demo was impressive and irrelevant. They spent four months building the wrong thing.
The Outcome Should Be Specific and Falsifiable
“We’ll save time on X” is not an outcome. “We’ll reduce the time your accounts team spends on invoice reconciliation from 6 hours per week to 1.5 hours per week within 90 days” is an outcome. The second version can be measured. It can be right or wrong. If your vendor won’t write that kind of specificity into the proposal, ask why.
McKinsey’s 2025 analysis found that technology delivers roughly 20% of an initiative’s value. The other 80% comes from redesigning how work is done around the technology. That means the real question isn’t “does the AI work”, it’s “will your team actually change how they operate.”
Red Flags in How the Value Is Framed
Watch for these patterns:
- “Efficiency gains” without a dollar figure or hour figure attached. Efficiency that doesn’t translate to cost reduction or revenue increase is not a business outcome.
- Comparison to competitors as the primary justification. “Your competitors are all doing this” is not a business case.
- Three-year ROI projections with no 90-day proof point. If the value only shows up in year two, ask what checkpoints exist in month three.
- Complexity as a selling point. If explaining how it works requires a 45-minute technical briefing before you can understand what it does, the architecture is probably over-engineered for your actual problem.
A Framework for Evaluating the Business Case
You don’t need technical knowledge to evaluate an AI proposal. You need the right five questions.
Five Questions to Ask Before Approving Any AI Project
1. What specific process is this replacing or augmenting, and who owns it today? If there’s no clear answer about current ownership, there’s no clear answer about accountability post-launch.
2. What does the integration touch in terms of our existing systems, and what breaks if it goes wrong? AI integrations rarely exist in isolation. They connect to your CRM, your email, your database, your website. Get a specific list of every system involved and a written answer about what happens if the integration fails.
3. What’s the training and adoption requirement for our staff? Gallup’s late-2024 data found only 15% of US employees say their workplace has communicated a clear AI strategy. Tools that require significant behavior change fail at higher rates than tools that fit existing workflows. Ask what changes for your team on day one.
4. Who maintains this after launch, and what does that cost? AI tools require ongoing monitoring, retraining, and updates. “We’ll handle it” from a vendor is not an answer. Get a written service agreement with defined response times and monthly cost.
5. What does success look like in 90 days, and what triggers a rollback? A project without a defined failure condition never officially fails. Make sure the proposal defines both the 90-day success metric and the condition under which you stop and revert.
How to Sanity-Check Projected ROI Claims
Take the projected annual saving and divide it by 4. That’s what you should expect in 90 days. If the vendor can’t commit to 25% of the year-one number showing up in the first quarter, the projection is not grounded in reality, it’s pattern-matched from case studies that don’t apply to your situation.
Deloitte’s 2026 State of AI in the Enterprise report found 42% of companies abandoned at least one AI initiative in 2025. The average sunk cost on those abandoned projects was $7.2 million. Most of those projects had business cases. The cases just weren’t grounded.
What Good Documentation and Handoff Look Like
Before you sign anything, ask for a sample handoff document from a previous project. It should include: system architecture diagram, data flow documentation, API credentials and access list, maintenance runbook, and rollback procedure. If the vendor has never produced that documentation before, they won’t produce it for you either.
Common AI Use Cases, Honest Assessments
Not all AI use cases are equal. Here’s where the evidence is strong, and where it isn’t.
Where AI Consistently Delivers for SMBs
Document processing and data extraction: Pulling structured data from invoices, contracts, and forms. High-volume, rule-consistent tasks. Measurable time savings from day one, typically 2–5 hours per week per staff member on that task, when inputs are consistently formatted. If your documents vary significantly in structure, expect that number to drop.
Customer support triage: Routing and categorizing inbound requests before human review. Works when the category set is limited and well-defined. Fails when customers write in unexpected ways about unexpected problems, and they will. Budget for a human review step on everything the model flags as uncertain.
Scheduled content generation for known formats: Weekly internal summaries, product description drafts, social media captions from a structured brief. Works when there’s a clear input template and a human reviewing output. Without that review step, errors compound quietly until someone notices.
Internal search and knowledge retrieval: Making a company’s documented knowledge searchable and queryable. High adoption rate because it fits existing behavior (people already search). Only as good as the documentation that feeds it, if your internal knowledge base is incomplete or out of date, the tool surfaces that problem rather than solving it.
Where AI Consistently Underperforms
Anything requiring judgment calls on edge cases: AI handles the 80% well and fails on the 20% that matters most. If your edge cases are high-stakes, legal disputes, unhappy high-value clients, compliance decisions, the failure cost is disproportionate.
Processes with inconsistent or undocumented inputs: If your team doesn’t follow a consistent process today, AI won’t fix it. It will automate the inconsistency.
Sales conversations and relationship-driven tasks: The demos are compelling. Production results are not. Human judgment in relationship contexts has not been replicated reliably at SMB scale.
If any of this connects to an AI pitch you’re currently evaluating, see how we scope and build this at designodin.com/ai.
Frequently Asked Questions
How do I know if an AI integration proposal is realistic or not?
Ask the vendor to show you a live production deployment, not a demo, not a case study, a running system you can interact with. If they can’t show you one that closely resembles your use case, you’re in early-adopter territory. That’s not necessarily bad, but the risk and timeline assumptions in the proposal should reflect that.
What metrics should I track to measure whether an AI integration is working?
Use metrics you already track before the integration launches. Set a baseline for the specific process being automated, time per task, error rate, cost per unit, volume handled per person. Measure the same metric 30, 60, and 90 days post-launch. If you need new metrics to show value, the integration isn’t delivering value where you needed it.
How long should it take to see ROI from an AI integration?
For document processing and internal workflow automation, 60–90 days is a reasonable expectation for measurable time savings. For anything requiring behavior change across a team, 6 months is more realistic. If someone is projecting ROI that only materializes in year two or three, ask what you’ll see in month three that confirms you’re on track.
What should be in an AI integration contract to protect my business?
At minimum: defined success metrics with measurement dates, explicit data ownership (you own your data, full stop), access and credential handoff on completion, maintenance terms with response SLAs, and a termination clause that doesn’t leave you locked into an unusable system. If data handling isn’t explicitly addressed, assume the vendor retains usage rights.
Do I need technical staff to manage an AI integration after it’s built?
Depends on the complexity. A simple integration connecting two existing tools via an API may need only periodic monitoring, 30 minutes per week from someone non-technical following a checklist. A custom-built pipeline processing business-critical data needs someone who can read logs, recognize anomalies, and escalate appropriately. Ask the vendor for a specific description of the ongoing maintenance task, not a general reassurance.
If you want to talk through what this looks like for your operation, start a conversation.