The fields nothing writes to

A lender I worked with produces a term sheet for every borrower who fills out their intake form. Property value, rental income, taxes, insurance, HOA dues, all of it goes into the form. A human runs the math, the quote goes out the door, and the borrower gets a real number they can make a decision on.

Then the inputs disappear.

Across thousands of submissions, the fields that produce the quote existed, fully populated, on exactly one contact record. One. A museum piece. The rest of the time the numbers lived in the form for about as long as it took someone to type them into a spreadsheet, and then they were gone.

Nobody did anything wrong here, which is the part I find interesting. The form asked the right questions. The team did the math correctly. Quotes went out on time. Every individual step worked, and the business still had no memory of the single most important thing it does all day.

The field that had to exist

I almost missed it, honestly.

We were working through how to automate their quoting, and the reasonable next step on the table was to create a new property in the CRM to hold the qualification inputs. New field, map the form to it, done by lunch.

Something about that bugged me. The form already asked for property value. It had been asking for years. If the question existed on the form, the answer had to land somewhere, so a property had to exist already, and I said so, a little more stubbornly than the situation called for.

It did exist. Four of them, actually, sitting in the schema with sensible names, each one filled in on a single record out of thousands of contacts. Someone had built the shelf years ago and nobody had ever pointed anything at it.

That stubborn moment is the whole essay, really. If I'd accepted the new field, we would have solved the immediate problem and buried the actual finding, which is that the business had been collecting its most valuable data every single day and pouring it straight down the drain.

Easy to instrument and important to know feel the same from the inside

When I looked at what the form integration did write, the picture got clearer. Requested loan amount, property type, loan type, lead source, all present across thousands of records and clean enough to report on.

Those are the fields that came mapped by default, or that someone remembered to map on the afternoon the integration got set up. They are useful. They are also, almost entirely, the fields that describe the lead and say nothing about whether the deal works.

This is the pattern I see more than any other in revenue systems. Companies instrument what's easy to instrument, and the easy stuff fills up the CRM until completeness starts to look like coverage. You open a record, you see twenty populated fields, and your brain registers "we have good data." The question it skips is whether those twenty fields include the four your business actually runs on.

From the inside, those two states feel identical. A dashboard built on the easy fields renders beautifully. It answers questions confidently. It just answers the ones nobody needed asked.

What the empty fields were costing

Once you know to look, the downstream effects show up everywhere.

Quoting was a manual spreadsheet pass, every time, because there was nothing to automate against. You can't build a pricing engine on data you don't keep. The team was fast at it, which made the cost invisible, since fast manual work looks a lot like a working system until you try to scale it, or someone takes a vacation.

The qualification ratio, the number that decides whether a loan makes sense at all, showed up on a few percent of deals. When it did appear, it had been typed in by hand late in underwriting, long after the borrower first gave the team every input needed to calculate it. The business knew the answer on day one and wrote it down on day thirty, sometimes.

And nobody in the building could tell me what ratio their leads typically came in at. That's the single most useful number this business could have. It tells you which marketing channels bring in deals that close, which borrowers to call first, which quotes are worth chasing, and where the pricing conversation is going to get hard. The data to answer it had walked through the front door thousands of times.

So four empty fields meant a quoting process that couldn't scale, and a leadership team making channel and pricing decisions without the number that would have told them which way to go. Spread that across a few years and it adds up to real money, plus a lot of confident conversations built on vibes.

Empty fields are questions people still ask out loud

Here's the reframe I'd offer anyone looking at their own stack.

A schema full of empty fields usually gets treated as clutter. Someone proposes a cleanup, the admin archives forty properties nobody uses, and the CRM feels lighter for about a week, the way a garage does right before it fills back up.

I'd read it the other way. A field that exists and sits empty on almost every record is very often a question somebody in your company is still asking, out loud, every day, on calls and in spreadsheets. The company decided at some point that the answer mattered enough to build a place for it. Then the process that collects the answer never got connected to the place that keeps it.

Every one of those gaps is a decision you can't audit later. You can't go back and ask why you priced a deal the way you did, and you can't build a benchmark, or train a model or a new hire, on history you never kept. The work happened, and the record of the work evaporated.

The empty field is the receipt. It tells you exactly where the leak is.

Stopping the leak

The way this landed with the client matters as much as the finding itself.

If I had walked in and said "you need to add qualification fields to your CRM," that's new scope. New scope invites a budget conversation, a priority conversation, and a reasonable executive asking whether this is really more important than the six other things on the list.

What I said instead was closer to: you are already collecting this. Your borrowers type it in every day. You built the fields for it years ago. Right now it's leaking out between the form and the record, and we're going to stop the leak.

Same technical work, completely different conversation. The existing, empty fields became the argument for the fix, because they proved the company had already decided this data mattered. Nobody needed convincing that the number was important, they needed to see that they'd been throwing it away.

I think that framing generalizes. When you find a gap like this, resist the urge to present it as an addition. Additions compete with everything else on the roadmap. A leak is something people want closed today.

The question worth asking about your own business

You don't need an audit to find out whether you have this problem. You need one question.

What number does your business quote, price, or promise on? The input that decides whether a deal is good, whether a customer is a fit, whether the job gets bid at this price or that one. Every company has one or two of these, and the people running the business usually know exactly what they are.

Now, could you pull the last thousand of them right now?

I mean the actual values, from the actual records, for the last thousand times your team made that call, without anyone assembling a sample for a board deck the night before.

If the answer is yes, great, you're ahead of most of the companies I talk to. If the answer involves a pause, a spreadsheet, and someone saying "well, it's kind of in there," go look at your schema. There's a decent chance the field already exists, sitting empty, waiting for somebody to point something at it.