One rejected application was missing a signature. Another was turned down on a rule that a near-identical case had passed the week before. Same process, but these two need completely different fixes.

We asked an enterprise client for their rejected applications, to find where AI could actually help them get more cases right the first time. The rejections split into two kinds.

Completeness problems

The first is a completeness problem. A field is missing, you can check for it, and an AI check can catch it before the file ever reaches a person.

These are the easy ones to work on. The rule is already written down somewhere, the check runs the same way every time, and you can tell straight away whether it worked. You do not need a model for most of them either. A plain check does the job, and a model only earns its place where the information is buried in a document and has to be found first.

The gain here is mostly in timing. The same problem gets caught at submission instead of a week later, so nobody has to go back to the applicant and start the clock again.

It is worth counting them before you build anything. If most rejections turn out to be one missing field, that is a form design problem as much as an AI problem.

Consistency problems

The second is a consistency problem. Nothing was missing. The same rule was read two different ways by two different people.

You do not fix that by cleaning data. You fix it with a clearer rulebook, and AI to keep the edge cases consistent.

These take longer, because the first job is deciding what the right answer actually is. Two reasonable people read the same rule differently, which usually means the rule does not cover the case in front of them. Someone with the authority to decide has to settle it, and then it has to be written down in a way the next person can apply.

Only after that does AI help. Once the rule is explicit, a model is good at applying it the same way every time, including on the awkward cases where a person would hesitate. Applying an unclear rule consistently just gives you the same disagreement at a larger scale.

Telling them apart

The quickest way to sort a pile of rejections is to ask, for each one, whether the file could have been fixed before anyone looked at it. If the answer is yes, it is a completeness problem. If the file was complete and the outcome still came down to who picked it up, it is a consistency problem.

The two also fail differently once you automate them. A missed completeness check sends the file back. A missed consistency rule produces a confident decision that happens to be the wrong one, and nobody notices until someone compares two cases side by side.

Why you need both the yes and the no

You only see the difference when you have both the yes and the no in front of you.

A pile of rejections on its own tells you what failed. It does not tell you whether a near-identical case passed. Put the approvals next to them and the consistency problems separate themselves out, because you can see the same facts landing on two different answers.

It is worth asking for both before you scope any work on a process like this. The split between the two kinds changes what you are building, and you cannot see that split from one side.

Originally posted on LinkedIn