A convincing demo can show what a tool can do. It cannot, on its own, tell you whether the tool belongs in your team’s workflow.
Before you compare subscriptions, choose one real task and follow it from input to finished outcome. Ask the supplier to show the ordinary case, an exception and a mistake. Then decide what evidence would justify a limited pilot.
1Define the job and the decision
Write down the input, the intended result and who uses it. For example, a marketing team might ask a tool to prepare a first draft of account research for a person to check. Agree what makes that draft usable: relevant information, traceable sources and a clear indication of missing data.
Ask what the system can decide or do without approval. Can it only suggest a next step, or can it change a CRM record, contact a prospect or trigger another system? Those are different levels of authority. Name the person accountable for the workflow, the actions requiring approval and the point at which work must stop.
2Follow the cost to a completed task
A seat price is only one input. Estimate licence and usage fees, setup and integration, human review, correction, monitoring and maintenance. Divide the relevant costs over a realistic number of accepted completed tasks. State the period, volume and assumptions.
For a pilot, compare the estimate with the existing process using the same definition of “complete”. If a human still needs to verify every claim, count that time. If the sample is small or the cost uncertain, say so. A lower cost per generation does not necessarily mean a lower cost per useful outcome.
3Ask the supplier to demonstrate failure
Give the tool an incomplete request, an ambiguous instruction and an example where a source is wrong or missing. Watch what it does. Does it signal uncertainty? Can a reviewer see the source and the action taken? Can someone stop the process, correct a result and recover from an unwanted action?
Choose controls in proportion to the consequence. Drafting an internal summary and changing customer records carry different risks. Check access permissions, retention, sensitive data handling and security with the people responsible in your organisation before using real data.
4Run a small pilot with a decision at the end
Name the workflow owner and the people who will use and review the output. Record a baseline where practical. Agree a small sample, a review date and one or two measures: accepted output quality, time per accepted task, correction rate or another measure that fits the work.
Decide in advance what evidence would lead you to continue, change or stop. Review examples of failure as well as averages. A pilot can reveal that a simpler rule-based workflow or a human-supported assistant is the better fit.
Buyer checklist
- One task, input and accepted outcome are defined.
- The system’s permitted decisions and actions are explicit.
- A named person owns approval, review and escalation.
- Total cost includes integration, usage, review and correction.
- An exception, a wrong input and recovery have been demonstrated.
- Access, data handling and the consequence of a mistake have been reviewed.
- The pilot has a baseline where feasible, a review date and a continue/change/stop decision.
The buying question is whether it can do a specific job reliably enough, with controls your team can actually operate.
Practical ideas for your next decision
Subscribe free for practical ideas on B2B marketing, positioning and making AI useful in your organisation.
Subscribe free on Substack