An AI feasibility assessment should answer a buying decision: is this task worth building, with your data and the checks your team needs? A demonstration alone cannot answer that.
Choose one task
Start with a decision someone already makes. “Read a supplier document and suggest a category for a person to approve” is a testable brief. “Bring AI into our operations” leaves the input, output and owner undefined.
For the example below, imagine a team sorting supplier documents into categories.
Write down the current steps, who does them and what a wrong answer would cause. Include a simpler option in the comparison: a form change, a search filter or a fixed rule may be enough.
Make a useful sample
Use material you are authorised to test. Remove information the experiment does not need. For an early demonstration, synthetic examples can help establish the process; a decision about a real workflow needs a sample that reflects the work.
Include awkward cases: an incomplete document, a category that overlaps another, an unfamiliar format and an item that belongs in no category. Keep some cases separate from the examples used while adjusting the system.
Agree how to judge it
Decide what counts as a correct answer before looking at the results. Record errors by type. Putting a document in a neighbouring category may have a different consequence from exposing it to the wrong person.
For the sorting example, record the suggested category, the expected category and whether the system should have asked for a human decision. Compare the result with the current process and the simpler alternative on the same cases.
A high average score can hide a failure that makes the workflow unsuitable. Review the important errors individually and decide which actions must stay with a person.
Price the whole workflow
Count the work around the model: preparing documents, connecting systems, reviewing uncertain answers, correcting errors and maintaining the integration. Include the expected usage cost and how it changes with volume.
Measure the time to complete the task with review included. A fast suggestion is only one part of the handoff.
Make a decision
The experiment should support a choice: build a bounded feature, use the simpler alternative, collect better examples or stop. Record the sample, the limits of the test and what would need checking before a live trial.
Keep the first live trial small enough that the named owner can inspect what happens and pause it if necessary.
A worked cost example
Here is a hypothetical calculation, not a Drevhe result or quote. Suppose an assisted workflow costs £0.08 per case in model and infrastructure usage. Every case needs 90 seconds of review, and 10% need another five minutes of correction. At an assumed staff cost of £24 per hour, the review costs £0.60 per case and the average correction costs £0.20. The total is £0.88 per case before setup and ongoing maintenance.
If the current manual task takes two minutes at that same hourly cost, it costs £0.80. In this example, the assisted route costs more. It might still help with another agreed constraint, but a faster model response would not establish a saving. Replace every assumption with measurements from your own cases.
What the decision record should contain
- The task, its owner and the actions a person must approve.
- The baseline, simpler alternative and exact version tested.
- How cases were selected, which were held back and what the sample leaves untested.
- Errors by consequence, review time and total cost per completed case.
- The conditions for a limited trial, or the reason to stop.
Drevhe’s AI Feasibility Check starts with that decision. The build is scoped separately.