Show AI inferences, don't store them: the case of client budgets

Anyone who handles enquiries coming in from property websites knows this: the budget is the piece of information most often missing. Plenty of contacts never state one. They write in, they ask questions, sometimes they chase us, but on how much they want to spend they say nothing. It's rarely mistrust. It simply isn't the first thing that comes to mind when you see a house you like.

And yet they leave a clue all the same. They ask about specific properties. And properties have prices. If someone has written to us about three homes, all in a similar range, it's reasonable to assume that's their range. It isn't a certainty; it's an inference. And it was precisely this distinction that forced a decision on us when we built the part of our CRM that deals with it.

What the AI does, and what it doesn't

The job itself is easy to describe: look at the properties a contact has asked about and work out a plausible price range. It's the kind of reasoning a good agent does in their head, on the phone, while scrolling through a client's history. Handing it to a tool means the reasoning is already done when you open the record, and it doesn't depend on the memory of whoever picks up.

The real question wasn't how to infer the range. It was where to put it once we had it.

The easiest answer would also have been the most obvious: there's a budget field, it's empty, the AI has an estimate, so fill it in. The field stops being empty, records look more complete, filters work across more contacts. Everything appears to improve.

We didn't do it.

Where we show it

The inferred range appears in three places, the ones where it genuinely helps the people doing the work:

• on the contact record, alongside the other details;
• in the summary that sets out who the person is and what they've asked for;
• in the call console, the screen you have in front of you while you're talking to the client.

In all three it is clearly labelled as inferred. Whoever reads it knows this isn't something the client said, but something the system worked out from their behaviour. It's useful information, sometimes very useful: it stops you suggesting homes that are wildly out of scale, helps you pitch the conversation properly, and lets you ask about budget with a rough idea already in mind. But it remains a hypothesis, and it presents itself as one.

Where we don't write it

The budget field is reserved for what the client has actually told us. If they haven't told us, the field stays empty. And rightly so: an empty field is information in its own right. It says "we don't know this yet".

The reason we care so much is that once a figure is written into a field, it loses its history. Nobody looking at it later asks where it came from. And a budget field isn't just read; it's used. It feeds into filters (show me contacts in this range), statistics (how much, on average, are the people who write to us looking to spend), and matching (who should we offer a newly listed home to).

If stated figures and inferred figures sit side by side in that field, every calculation that runs over it becomes a muddle. The statistics look solid, but partly describe the system's guesses rather than clients' intentions. Matching treats a hypothesis as a request. And the worst of it is that nobody can tell them apart any more. There's no way, after the fact, to clean up a field where two kinds of information have been mixed without a label.

There's a subtler effect too. If the system fills the field on its own, the people doing the work stop feeling the need to ask the question. The budget seems to be known already. So the stated figure, the real one, never arrives, because the place it should have gone is already taken by an estimate.

Promotion, when it's warranted, is a decision

We're not saying an inferred figure can never become a reference figure. There are cases where that makes sense: the inference is robust, the context backs it up, and it's worth treating as a working basis. But that step, from "shown as inferred" to "written into the real field", requires an explicit decision by the person in charge. It doesn't happen on its own, it doesn't happen automatically, and it doesn't happen because a tool has decided its estimate is good enough.

The friction is deliberate. It costs an extra step, and that step forces someone to look at the figure and take responsibility for it. If, some time from now, a statistic looks odd to us, we'll know that the numbers in the budget field were either stated by the client or promoted by a person who chose to do so. There won't be a third, invisible category.

What we take away

The budget case is a small one, but the rule we drew from it applies to a great deal more: show AI inferences, don't store them. AI is good at drawing sensible hypotheses from scattered signals, and those hypotheses deserve to be in front of the people doing the work, at the moment they're needed. But a database is only worth the trust you can place in each of its fields. And that trust is lost quickly, the first time you can no longer tell whether a number was said by a person or imagined by a machine.

Keeping the two apart costs little while you're building the tool. Untangling them afterwards is, more often than not, impossible.