Quick Answer: Most reps use AI to format business cases: better slides, cleaner tone, professional presentation. Almost none use it to build them, to name the variables, write the equations, source the benchmarks, and decide what share of the outcome their product can honestly claim. Formatting arranges a claim. Engineering produces one. The difference decides whether the case survives the economic buyer's review.
By Amar Dhaliwal, CEO & Co-Founder, valueIQ | August 11th, 2026
A regional sales leader described what his team does with AI. They generate decks. They make the business case look finished. The output is polished. The equations underneath are still guessed.
Nobody is using AI to work out what the numbers should be. I hear a version of this in almost every account, and it is the quiet reason good deals stall at finance.
Formatting is presentation. Engineering is the equation underneath. One makes a document look credible. The other makes it survive contact with the person who controls the budget.
What are reps actually asking AI to do?
A rep pastes a rough value claim into ChatGPT. Something like: "Our platform saves customers 20 hours per week and reduces errors by 30%."
The prompt: "Turn this into an executive summary for finance."
The output: three paragraphs, professional tone, structured headings, a cleaner slide. The case looks more finished than what the rep had five minutes earlier.
Nothing about the economics changed. The 20 hours were guessed on a Friday afternoon. The 30% error reduction came from a customer success story the rep half-remembered. The numbers are now in a better font. That is the only improvement.
The rep sends it. The deal stalls at finance. The question comes back: "Where did these numbers come from?"
The rep has no answer.
What is the difference between formatting and engineering?
Formatting arranges a claim. Engineering produces one.
Formatting means: take this sentence and make it sound better. Add structure. Improve the tone. Clean up the slide. The input is a claim. The output is the same claim, presented more professionally.
Engineering means: name the variables that drive the outcome. Write the equation that connects them. Source the benchmark data. Decide how much of the improvement is honestly attributable to your product versus the customer's own effort. Adjust for execution risk. Calculate the payback period.
The sales leader's exact phrase: "What matters is the skeleton of thinking underneath."
A formatted case is a polished surface with no skeleton. An engineered case is a structure that holds up when tested.
Why does a well-formatted case still stall at the executive review?
Finance does not read the formatting. They test the assumption.
The economic buyer sees: "This product will save your team 500 hours per year, worth $75,000 in recaptured productivity."
Then the questions start. How did you calculate 500 hours? What hourly rate did you assume? What if our team's rate is different? How much of that time savings is attributable to your product versus process changes we would make anyway?
The formatted case has no answer. The equation was never written. The benchmark was never sourced. The attribution was never modeled.
A general-purpose AI will produce a number with complete confidence and no grounding. Ask it for a return figure and it will give you one. The number collapses on first contact with scrutiny.
A number that collapses is worse than no number. It costs the rep the credibility they need for everything that comes after.
What does engineering the equation look like in practice?
Engineering starts with the value drivers. Which ones apply to this specific account? Which ones do not?
A procurement software vendor might claim five value drivers: faster approvals, reduced maverick spend, better supplier pricing, compliance risk mitigation, and internal audit cost reduction.
For a 200-person company with decentralized purchasing, maverick spend reduction is real. Internal audit cost reduction does not apply. They do not have an internal audit function.
The engineered case drops the driver that does not fit. The formatted case includes all five because it looks more impressive.
Next: benchmarks. Where did the improvement figure come from? Industry research? A case study? A guess?
An engineered case cites the source. It names the study, the sample, and the range: a documented procurement cycle-time reduction from a named industry CPO survey, drawn from hundreds of enterprise implementations, not a round number with no origin.
A formatted case says: "Reduces procurement cycle time by 50%," and leaves the buyer to wonder where 50% came from.
Next: attribution. How much of the outcome is caused by the product? How much would have happened anyway?
If a company is moving from manual spreadsheets to any procurement system, most of the efficiency gain comes from digitization, not from this specific vendor's differentiation. An engineered case models that. A vendor might claim 40% cycle-time reduction, but only 15 percentage points are honestly attributable to their product's specific capabilities versus a generic competitor.
A formatted case does not make that distinction. It claims the full 40% and hopes finance does not ask.
Finally: execution risk. What is the probability the customer actually achieves the modeled outcome?
Change management is hard. Adoption is uncertain. Process redesign takes time. An engineered case carries an execution risk adjustment, typically 20% to 40% depending on the customer's readiness and the vendor's implementation track record.
A formatted case assumes 100% probability of success. Finance assumes 50%. The gap is where deals stall.
That is the work. valueIQ does it, from deal context to cited equations to risk-adjusted payback, in minutes.
But the distinction exists whether you use valueIQ or not. Formatting a claim is not the same as building one.
Formatting vs. Engineering: A Comparison
Dimension | Formatting | Engineering |
|---|---|---|
Starting point | Rough value claim from the rep | Deal context and customer variables |
What AI does | Rewrites the claim with better tone and structure | Selects applicable drivers, sources benchmarks, writes equations |
Output quality | Looks professional | Survives the economic buyer's scrutiny |
What breaks it | "Where did these numbers come from?" | Nothing. The assumptions are documented and defensible |
Attribution | Claims the full outcome | Models what share is honestly attributable to this product |
Risk adjustment | Assumes 100% probability of success | Adjusts for execution risk based on customer readiness |
Benchmark source | Not cited | Cited: industry research, peer data, case studies |
Time to produce | 2 minutes | 4 minutes (with the right tooling) |
What it costs the deal | Credibility when the number collapses | Nothing. It holds up |
FAQ
Can I just use ChatGPT to build a business case?
You can use ChatGPT to format one. You cannot use it to engineer one. A general-purpose model has no access to industry benchmarks, no value methodology, and no ability to distinguish between a plausible-sounding ROI claim and a defensible one. Ask it for a number and it will give you one. The number will sound confident. It will collapse the moment finance asks where it came from.
What is the difference between a value model and a business case?
A value model is the equation. A business case is the output. The model defines which drivers apply, how variables connect to outcomes, and where the benchmark data comes from. The business case is what you hand to the economic buyer: the specific calculation, the risk-adjusted figures, the payback period. You cannot build a defensible business case without a value model underneath it.
Why do finance teams reject vendor ROI numbers?
Because most vendor ROI numbers are formatted claims, not engineered ones. A vendor-authored ROI figure with no cited source, no attribution model, and no risk adjustment reads as marketing. Finance discounts it on sight. What changes that: cited equations, market-sourced benchmarks, and transparent assumptions the buyer can inspect and challenge.
How long should building a defensible business case take?
With the right tooling: four minutes from deal context to executive-ready output. Without it: 3 to 5 hours if the rep builds it themselves, 2 to 3 days if a Value Engineer or Deal Desk lead builds it, $50K to $150K and several weeks if a consulting firm builds it. The time difference is the cost of not having value infrastructure.
The skeleton of thinking underneath. That is what matters. A formatted case is a polished surface. An engineered case is a structure that holds when tested.
Try it free: valueiq.ai
