You may have decided AI can’t do your kind of work. You saw it tried on the paperwork large customers send you, such as supplier questionnaires answered from your product or service specifications. Whether the firm tries again is your call.

Say your operations lead tried it on a large customer’s supplier questionnaire and got confident answers drawn from an out-of-date version of the specification. The verdict in the office came quickly, and it may be the wrong one.

Getting the reason wrong is expensive either way. You drop a job that had a useful piece inside it, or next time you hand a decision a person should make to a tool. By the end you’ll know how to name why a job failed and what to do next.

Why “AI can’t do this” is the wrong conclusion

The belief behind that conclusion is that a job either suits AI or it doesn’t. It doesn’t work like that. A job fails for a reason, and the reason decides the next step.

In the questionnaire example, the tool didn’t fail because questionnaire work is beyond it. It failed because the business had three versions of the same specification in three places, and nobody had said which one was right. A person new to the office could have made the same mistake from the same files.

Other jobs fail for other reasons. The deciding step depends on experience nobody has written down. Nobody can check the answer before it matters. Or the information shouldn’t go into the tool at all. Some of those are preparation problems you can fix. Others mark a decision that should stay with a person however good the records get.

Treating every failure the same does damage in both directions. You abandon jobs that were a week of tidying away from working, and you keep pushing at decisions that were never the tool’s to make. The rest of this article is the method for telling them apart.

Run four checks on the job as it stands

Start by describing the job as it happens now, from the moment work arrives to the point where someone uses the result. Ask the person who does it to show you an ordinary case and an awkward one. Listen for decisions they make from experience that they can’t explain from the papers in front of them.

Then ask four questions. Can you name the source a correct answer would come from? Can someone spot a wrong answer before it changes anything? Is the information allowed into the tool you intend to use? Can a named person take responsibility for what happens next?

An uncertain answer to any of the four means the whole job isn’t ready to hand over. It doesn’t mean every use of AI around it is off the table. Finding a first AI job customers never see is about repeatable, bounded work you can test quietly. These four checks tell you where a person must stay in control, and why.

Check whether the judgement can be written down

Some work looks routine until an exception arrives. An operations lead reading a customer complaint knows when a missed delivery needs a phone call today and when a standard letter will do. If nobody can describe how that call gets made, the tool has no dependable rule to follow. It will still produce an answer that sounds complete.

Ask the person to talk through several finished cases, including the ones they escalated. What made them pause? Which detail changed the route? If the reason can be written as a condition and checked against the source, you can probably define a smaller task around it.

If the answer is “you have to know the customer” or “it depends on everything else”, keep the decision with the person while you work out what that knowledge contains. You don’t need to force every exception into a rule. Sometimes the human conversation is the work. Writing down the unwritten rules helps you find out which decisions can be explained.

Check whether anyone can catch a wrong answer

A review step only protects the business if the reviewer has time, a trustworthy source and the authority to hold the output back. Ask what they’d compare the answer with. If they have to rebuild the whole case to judge one paragraph, AI has added a reading task rather than removed work.

Timing matters as much as the check. A draft reply a person reads before sending is very different from a recommendation that triggers an action straight away. If the action is hard to reverse, such as releasing an order or confirming a specification to a customer, the person comes before it, not after. Where you can’t create that pause, don’t give the tool the power to complete the action.

Take particular care when the result affects someone’s safety or an important outcome for a customer. AI can help your operations lead gather and order the relevant records. The person signing off must still examine the evidence and stand behind their own reasoning.

Check the information is fit and permitted

An answer is only as dependable as the material behind it. If a specification has three versions or is missing the detail people normally ask for, the tool can’t tell which source is the real one. Pause the AI part and settle the records first. That work improves the human process too, whether or not the tool comes back.

Permission is a separate question. A document an employee can open isn’t automatically one they may paste into a chatbot or send to a supplier. A large customer’s questionnaire may come with confidentiality terms of its own. Check the business’s information rules and the approved tool’s terms before any customer, staff or confidential material goes in. If you can’t say what the tool receives, who may see it and what happens to it afterwards, don’t use that material in a trial.

You can test the shape of a task with made-up material that holds nothing sensitive. That shows whether an instruction works. It doesn’t give you permission to use real records later.

Name the reason before you choose the fix

When a job fails the checks, write down which check it failed and why, before deciding anything. Missing or conflicting records are a preparation problem. So is a rule that exists only in one person’s head. You can fix both and come back to the job when the records and instructions are usable.

An absent reviewer is a capacity and ownership problem. Someone needs time and a clear standard to check the output, and until they have both, the work stays with people. A decision that carries personal accountability may stay with a person even after the records are perfect. Better documents don’t remove the need to weigh circumstances and stand behind the outcome.

Write the reason in plain words. “We can’t test this until the team agrees one master version of each specification” tells someone what to fix. “AI is unsuitable here” tells nobody anything. Equally, “Contract sign-off stays with the operations lead because she signs for it” is a sound boundary, not an unfinished project.

Find the smaller job inside the one that failed

Keep the current human route running while you look for a smaller, safer task inside it. Separate preparing the information from deciding what it means.

In the office that handles those questionnaires, that might mean a tool pulling the expiry dates from every supplier certificate into one list, which the operations lead reviews each month. It might mean drafting first answers to a customer questionnaire from the single approved specification, with a person checking every line before it goes. The tool arranges and drafts. The person reads the originals, asks questions and makes the call. The tool should never quietly move from arranging information to deciding what it means.

Match each response to the reason the job failed. If the problem is the records, give someone the task of settling the master version and owning it. If it depends on one person’s judgement, walk through past cases with them and write down the exceptions. If the review can’t happen in time, move the point where the output stops, or leave that part alone. Don’t go looking for a different product and hope the same obstacle disappears.

Set a condition for coming back to the full job. “Try again when there’s one approved specification file and a reviewer can check against it” gives the owner a clear next step. You can then agree what good looks like before AI goes live for the smaller job and test it properly.

Run the four checks on one job this week

On Monday, pick the job that failed, or the one you’ve been wary of trying. Book an hour with the person who does it, in this example your operations lead, and bring one ordinary case and one awkward one.

Walk through the four checks together and write down which failed and why, in a sentence each. Before you leave the room, choose one move: prepare the records, give the reviewer room, narrow the task or keep it human. You’ll have made a useful decision even if no AI tool gets used.