Write the Failures Down

People ask why I store a submission that failed the check. Because the failure is often the exact moment a good client was trying to hand you the work.

A client sits with an intake form. They've got a real matter. A plaintiff, a date of loss, the other party, maybe a VIN, a police report that isn't in the email yet. A date off by one. A name spelled the way someone said it on the phone. The form won't take it, and they leave.

On our side there's no case. Nothing to call them back about (somewhat the point of the rules).

The form did not fail to explain itself, mind you. While they were still on the page, what they typed was probably sitting right there, marked in red. That's their input. The company kept nothing of that. A Jira service portal doesn't make a request until the create passes validation - a required field, a file that hasn't arrived, some value a setting in the back won't allow. Until then there's no ticket, no queue, nobody who can pick it up. There's a browser tab. They close it and the attempt is gone, because it never got stored anywhere.

That's a bad deal when the client is worth having. They already did the slow and frustrating part, pulling facts out of reports, maybe writing down their ID number, in the worst case adding payment details. Then they hit a validation rule, and that was it. Sometimes that's a speedbump, sometimes it's a lost contract.

Some of those rules are real. A date in the future should be caught. An empty name should be caught. Catch them. Just do not let the catch be the last thing the client sees. I want the data and the attempt, so whatever can be done gets done, and the rest becomes a question from a person.

So I write the submission down first. Passes and fails both. It gets an id. Someone inside opens it and sees the plaintiff, the date, and a hole where the police report should be. They fix a field, start the part of the job that doesn't need the missing file, and write back with one question instead of a red error. The check still runs - against a record, not against someone deciding whether to give up.

The ticket system still gets the case, it just hears about it second. A background job reads what we stored and creates the ticket once the payload is something Jira will accept. If Jira's down, or this week's fields don't mean what last month's meant, the attempt is still in the database.

Sprinkle in a bit of AI and it scales so beautifully. Nonsense, unparseable by even the language model? Stash it, mark it as garbage. Minor mistakes, obvious from context? Fix that (with notes), move forward, "read their mind" as it were. Too gray to decide? Pull in the human.

We look at it in the morning. Nobody asks the client to type the submission again because the other system had a bad afternoon.

The police report that shows up Thursday attaches to that same record. They can ask for status and get an actual answer, because the case exists before anyone's declared it perfect.

A broken submission is not a finished case, and some of these you won't be able to service. Keep them anyway, with the reason they failed sitting next to the data. Otherwise the queue looks squeaky clean. It's clean because the clients left (so did your revenue).

Write the failure down. It is the copy of the work they were willing to give you.

If you know who owns the form, send them over.