A person is a trajectory, not a single remark
An ordinary lead list is built on "person X said Y once". But one remark says almost nothing about readiness. Here is what changes when the unit becomes a person over time, and why an estimate should never be shown without its evidence.
How do you tell someone who is ready to buy from someone who just asked out of curiosity?
From one remark, you mostly cannot. The unit has to be the person over time rather than the text: what they asked, in what order, and how recently. A question about price after a question about scope does not mean the same thing as the reverse. The readiness estimate stays an estimate, so it is only worth showing alongside its evidence — verbatim quotes and links that show where it came from.
A typical lead-finding system hands you a flat list: person, place, quote, link. Every row is a separate event. You open the list in the morning and see twenty remarks from twenty different people.
The trouble is that one remark cannot separate the person who will write to you tomorrow from the person who was merely curious. Both said roughly the same thing.
The unit is the person, not the remark
The shift is simple to describe and awkward to build: stop storing findings as a list of texts and start storing them as events attached to a person.
That needs a stable way of naming a person. They may have a profile on one network, another profile elsewhere and a forum comment under a third name. Until there is a single key, there is no trajectory — you are back to a pile of remarks.
After that it is straightforward. Each observation is a row: who, what they did, where, when, their words verbatim, and a link. Rows are never edited or deleted, only added. A person’s history is all of their rows in order.
And this is where something appears that the flat list never had. You see movement rather than a remark: asked about price, two days later asked what the work includes, a day after that asked when it could start.
Order and recency change the meaning
The same three questions in a different order read differently.
If someone first asked when you were free, then what was included, and only then about price, they are probably comparing suppliers and still early. The other way round — starting with price and arriving at timing — suggests they have already decided the work needs doing and are now choosing when.
Recency works the same way. Three questions in a week and three questions across half a year are different people, even though the set of questions matches. In the second case they have most likely solved the problem another way long ago.
Neither is visible while the unit stays a single remark.
An estimate should not be shown without its evidence
A number is easy to compute from a trajectory. The temptation is to show the operator only that: here are the people sorted by readiness, work down the list.
I think that is a mistake, and here is why.
The number comes from a model, and models are wrong sometimes. When a person sees only the number, there is nothing for them to check: they either trust it completely or not at all. Both are bad. In the first case they write to people they should have left alone. In the second they stop using the system.
So the estimate always sits next to what it was built from: the observations themselves, the verbatim quotes and the links to the original pages. In a few seconds the operator sees what the conclusion rests on and can disagree with it. The observations are the evidence. The estimate is a guess about what they mean.
The difference between “this person is ready” and “this person asked this, then this, then this, the last one yesterday” is that the second can be checked and the first has to be taken on faith.
That has a practical consequence for wording: the interface should carry no language that promises the future. The system shows what has already happened and marks its own guess as a guess.
What I chose not to build
There are ready-made stacks for this: a separate vector store, a separate database for relationships between entities, a separate crawling service. All of it installs and runs.
I looked and passed. Not because the stack is bad, but because I already had every part I needed: somewhere to keep observations, a way to compare texts by meaning, and something that fetches pages. Adding a dozen new services would have solved a problem I did not yet have.
The more important half: I wrote down the conditions under which that decision gets revisited. When there are so many observations that ordinary queries stop finishing in reasonable time. When there are enough clients that they start getting in each other’s way. Until one of those happens, the old arrangement stays.
A written-down condition is the difference between “we decided not to over-build” and “we decided not to over-build once and then forgot to think about it again.”
What to take from this
Three things that do not depend on tools.
If you are collecting observations about people, settle on a stable key for a person before you start collecting. Merging later costs more than agreeing now.
Store observations as appended events with a time and a source link, not as a record you keep overwriting. A record shows the current state and loses the path that led there — and the path is where the meaning is.
And never show an estimate without what it was made from. A number without evidence is a request to trust you. Evidence beside the number is grounds for a decision.
How the same system keeps a model from inventing a quote is a separate article; the case study covers how it looks from the outside. If you need something similar for your own work, get in touch.