Lesson 13 of 38 · AI 101 - 12 min

AI 101: Buy Tools Without Wasting Money

Run a disciplined AI procurement process - problem-first, data-boundary-aware, exit-path-ready - so every subscription and pilot is tied to a repeated job and a measurable outcome, not a demo high.

Renamed from the choosing AI tools guide

← Previous Next lesson

AI procurement should not start with a demo. It should start with the problem, the data boundary, the adoption burden, the exit path, and the measurable outcome. The right buying process prevents shiny-tool drift - the slow accumulation of subscriptions that each looked compelling in isolation and collectively drain a budget no one is watching. In 2026 this is not a hypothetical: independent benchmarks show that most enterprise GenAI pilots deliver no measurable profit impact, and that organisations waste tens of millions a year on software licences they bought but never adopted. A demo sells you the best 20 minutes of a tool's life; a procurement process protects you from the other 360 days. This lesson gives you that process, the pricing literacy to predict true cost, and the habit of writing the exit before you write the cheque.

Video

Buy AI tools without wasting money

A branded walkthrough: evaluate solutions over demos, pick by repeatable business problem, weigh pricing models and total cost, and set pilot boundaries and an exit strategy.

What to understand

A tool must solve a repeated, named job, not just look impressive in a demo. If you cannot describe the workflow it replaces in one sentence, you are buying a capability, not a solution - and capabilities you do not have a use for become the unused licences that dominate wasted SaaS spend.
The pricing model matters as much as the price. Per-seat looks predictable but punishes you for inactive users; usage-based and hybrid (base fee plus consumption) can spike without warning once an AI agent - not a human - is doing the work. Read which model you are signing before you read the headline number.
Privacy, export, admin controls, and audit needs must be checked before the pilot begins, not after real work is trapped inside the account. Ask where data is processed, who can see it, whether your inputs train the vendor's models, and how you get everything out if you leave.
A pilot is a time-boxed experiment with a yes/no decision date, a budget cap, and one measurable outcome - not an open-ended subscription with optimistic intentions. Without a review date, a pilot silently becomes a system of record and then a renewal you are afraid to cancel.
Training and adoption burden is a real, recurring cost. A tool the team cannot or will not learn becomes a paid-for shelf-ware line item. Budget the hours to onboard, the owner who supports it, and the existing tool it must actually replace.
Cancellation and data-export risk decide how reversible the bet is. Pilots that cannot be cleanly exited turn into accidental lock-in; the cheapest mistake is the one you can fully undo.
Shadow AI - tools bought on personal or team cards outside any review - is where most uncontrolled cost and risk hide. A buying process that one person follows beats a policy no one reads.

Deeper dive

Why the demo is a trap (and what the 2026 evidence says)

A vendor demo is a controlled performance: clean data, a rehearsed scenario, and a feature set tuned to dazzle. It tells you what the tool can do at its best, not what it will do inside your messy, real workflow on a Tuesday. The 2026 numbers make the gap concrete. MIT's Project NANDA found that roughly 95% of organisations that deployed generative AI saw zero measurable impact on profit and loss - the tools worked, but the value never showed up in the business, almost always because no one defined the outcome before building. Gartner similarly forecasts that the majority of AI projects lacking AI-ready data and a clear goal will be abandoned. The lesson is not 'AI does not work' - it is that buying on capability instead of on a defined outcome is the single most reliable way to waste money. Your procurement process exists to force the question the demo is designed to make you forget: what specific, measurable thing will be different, and how will we know?

Read the pricing model, not just the price

AI tool pricing is shifting fast, and the model determines your real exposure. Pure per-seat pricing - a flat fee per user - is predictable but quietly wasteful: benchmarks show roughly a third to nearly half of paid SaaS seats go unused, so you pay for access nobody touches. Usage-based pricing (per token, per message, per resolution) aligns cost to value but can spike unpredictably, especially once an autonomous agent is generating the usage instead of a human clicking buttons - which is exactly why 78% of IT leaders reported an unexpected consumption- or AI-pricing charge in the prior 12 months (Zylo's 2026 SaaS Management Index). Most vendors are now landing on hybrid pricing: a base subscription plus usage overage. Before you sign, ask three questions: (1) What is the unit I am charged on, and can I forecast it from my real workload? (2) Is there a hard cap or alert before overage, or does it bill silently? (3) If an agent loops or misfires, what is the worst-case bill in a day? A tool with a brilliant feature and an uncappable usage meter is a budget hazard, not a bargain.

Write the exit before you write the cheque

The most expensive AI subscriptions are the ones you keep paying for because leaving feels harder than staying. You prevent that by defining reversibility up front. Before approving a pilot, document three exit facts: how you export your data and work product in a usable format, what the cancellation terms and notice period are, and what you would fall back to if you stopped tomorrow. This matters because pilots have gravity - useful work accumulates inside the account, and a 'two-week trial' becomes a system of record by month three. The 2026 data shows why this discipline pays: organisations waste an estimated tens of millions a year on licences they never fully adopted, and shadow-AI tools sit on company cards for over a year before anyone questions them. A written exit path turns a subscription from a one-way door into a reversible experiment - and reversible bets are the only kind a beginner should be making with a budget.

AI tool pricing models - what each one really costs you

The model you sign determines your real exposure far more than the headline number. Match the model to how the work is actually generated (human clicks vs. an autonomous agent) before comparing prices.

Pricing model	How you're billed	Best when	Hidden risk	Question to ask the vendor
Per-seat	Flat fee per named user, per month.	Stable, human-driven use with steady adoption across a known team.	You pay for inactive seats - roughly a third to nearly half of SaaS licences go unused.	Can we reassign or remove seats monthly without penalty?
Usage-based	Per token, message, action, or resolution consumed.	Spiky or uncertain use, or when only a few people use it heavily.	Cost can spike without warning once an agent - not a person - drives usage.	Is there a hard cap and a pre-overage alert, or does it bill silently?
Hybrid (base + usage)	Subscription floor plus consumption overage above an included allowance.	Most real teams: predictable baseline, room to scale - now the common AI model.	Overage rates and the size of the included allowance are easy to miss.	What's included in the base, and what's the overage rate beyond it?
Outcome-based	Per delivered result (e.g. per resolved ticket).	When the unit of value is countable and the vendor can be held to it.	Defining and disputing what counts as a billable 'outcome'.	Exactly what counts as a billable outcome, and who adjudicates disputes?

Sources (as of June 2026): Bessemer - AI pricing & monetization playbook (2026) · Monetizely - 2026 guide to SaaS, AI & agentic pricing · Torii - controlling AI SaaS costs (2026)

Visualisation

AI buying decision funnel

Move from problem fit to pilot approval only when each gate is clear.

Problem fitWhat repeated job does this tool solve, and what does doing nothing cost today?
PrivacyWhat data will it see, where is it processed, and does it train on your inputs?
IntegrationDoes it connect to the actual workflow without risky manual workarounds?
AdoptionWho will use it, learn it, support it, and review its output?
OutcomeWhat single measurable result decides whether the pilot continues or stops?

Step by step

Write the problem statement

Describe the repeated job in one or two sentences: what it is, how often it happens, who is affected, and what doing nothing costs today (time, errors, delay, missed revenue). If you cannot name the workflow plainly, pause the purchase - you are about to buy a capability, not a solution. You are done when a colleague could read your two sentences and name the workflow, its frequency, and the cost of doing nothing - without asking you anything.

HintA weak problem statement is the single biggest predictor of wasted spend. The demo is designed to make you skip this step.

Check data, controls, and the pricing model

List the data the tool will see and where it is processed; confirm admin controls, export options, audit logs, and whether your inputs train the vendor's models. Then identify the pricing model (per-seat, usage-based, hybrid, or outcome-based) and the worst-case daily cost - especially if an agent, not a person, will drive usage. You have finished this step when you can name the pricing model in one word and have written a single worst-case daily cost figure next to it.

HintTest with redacted or synthetic examples first. Data controls and cost caps are far easier to verify before the account is full of real work.

Estimate adoption cost

Name the users, the training time, the support owner, the review process, and the existing tool or process this is meant to replace. If it adds a new place to check rather than removing one, it may create work instead of saving it. Expected result: one named owner, an hours-to-onboard estimate, and the tool or process this replaces - written down, not assumed.

HintOnboarding hours and an accountable owner are real recurring costs. A tool no one is responsible for becomes paid-for shelf-ware.

Make the pilot decision (with cap and exit)

Write a yes/no pilot decision that includes a start date, a review date, a budget cap, one measurable success metric, a cancellation condition, and the exit path (how you export work and what you fall back to). No review date means it is not a pilot - it is an open-ended subscription.

HintDefine reversibility before you charge the card. The cheapest mistake is the one you can fully undo.

Hands-on task

Complete an AI buying checklist and make a yes/no pilot decision for one candidate tool. Include the problem statement, data boundary, pricing model and worst-case cost, adoption owner, budget cap, success metric, cancellation condition, and exit path.

What you produce

An AI buying checklist and a yes/no pilot decision for one candidate tool, with budget cap and exit path.

Production prompt examples

Production prompt - AI tool procurement brief (paste into ChatGPT or Claude)

ROLE: You are a pragmatic procurement and FinOps advisor who is sceptical of vendor hype and focused on real, measurable business value.

CONTEXT: I am evaluating an AI tool before committing budget. I want a disciplined buying decision, not a sales summary. Here are the facts:
- Repeated job it would do: <describe the workflow, how often, who is affected>
- What doing nothing costs today: <time / errors / delay / revenue>
- Data it would touch: <list data types and any sensitivity>
- Pricing model and headline price: <per-seat / usage / hybrid / outcome; the number>
- Team that would use it and their current tool: <names/roles, what it replaces>
- My budget cap for a pilot: <amount> and my desired review date: <date>

TASK: Produce a go / no-go pilot recommendation.

DO THIS:
1. Restate the problem in one sentence. If it is too vague to evaluate, say so and ask the one question you most need answered.
2. Score the tool 1-5 on: problem fit, data/privacy safety, integration, adoption realism, and reversibility (exit path). Show the scores in a small table with one-line justifications.
3. Estimate the realistic monthly cost AND a worst-case cost (especially if an autonomous agent could drive usage). Flag any uncapped usage risk.
4. List the top 3 risks and, for each, one concrete way to de-risk it in the pilot.
5. Recommend GO, NO-GO, or DELAY, with a one-line reason, plus a written exit path (how to export work and what to fall back to).

CONSTRAINTS:
- Be concise and specific. No marketing language.
- If a fact is missing, state the assumption you made rather than inventing data.
- Do not recommend GO unless the problem is clear, the cost is bounded, and the exit is reversible.

The ROLE ('sceptical FinOps advisor') counters the model's tendency to be agreeable about whatever tool you name - it primes critical evaluation.
Forcing a one-sentence problem restatement reproduces Step 1's discipline: if the model can't restate it, the purchase isn't ready.
Asking for realistic AND worst-case cost surfaces usage-based/agent spike risk - the exact trap behind 2026's unexpected-consumption-charge reports.
The reversibility/exit-path score makes 'can I undo this?' a first-class buying criterion, not an afterthought.
The GO/NO-GO/DELAY constraint forces a decision instead of a wishy-washy summary, and the 'state assumptions' rule stops the model fabricating vendor facts.

Common mistakes to avoid

Letting a vendor demo define the business problem instead of starting from a named, repeated job.
Reading the headline price but not the pricing model - then getting surprised by usage-based or agent-driven overage.
Skipping export and cancellation risk until after useful work is trapped inside the account.
Running an open-ended 'pilot' with no review date, budget cap, or success metric - so it quietly becomes a renewal.
Approving tools with no owner, training plan, or review process, then paying for shelf-ware no one adopts.
Buying a platform when a prompt, checklist, or small workflow would solve the job - and ignoring shadow-AI subscriptions already on team cards.

Source conflicts to review

Pilot failure framing varies: MIT NANDA reports ~95% of GenAI deployments show no measurable P&L impact, while RAND puts enterprise AI 'failure to deliver value' near 80% - different definitions, same direction (most unmanaged AI spend underdelivers).
Unused-licence estimates differ by source and method (~36% per Zylo's 2026 Index vs. ~46–51% when 'underutilised' is included). Use the conservative figure and the consistent conclusion: a large, costly share of paid licences goes unused.

Key terms

Pilot decision: A time-boxed yes/no decision about whether a tool earns wider rollout, with a date, cap, and metric.
Exit path: How the team exports work, cancels safely, and returns to another process if needed.
Adoption cost: The training time, support ownership, and review effort required for people to use the tool properly.
Usage-based pricing: Billing tied to consumption (tokens, messages, actions, resolutions) rather than a flat per-user fee.
Hybrid pricing: A base subscription plus usage overage above an included allowance - now the common AI tool model.
Shadow AI: AI tools bought and used outside any formal review, typically on personal or team cards, where most uncontrolled cost and risk hide.
P&L impact: Profit-and-loss impact - a measurable change in revenue or cost. The 2026 benchmark finding is that most GenAI pilots show none, which is why every pilot here needs one written success metric.
FinOps: The discipline of managing software and cloud spend against measurable business value - the sceptical-buyer mindset the production prompt asks the model to adopt.

Resources

Checkpoint

Would you approve, reject, or delay the pilot for your chosen tool - and does your decision name the pricing model, the worst-case cost, the success metric, and the exit path?

Your answer and notesMark this lesson complete