Name it what the site already calls it

Software written in an office uses office vocabulary. The people using it on a site use site vocabulary. Where the two meet, the software's version wins, because the software is the thing that refuses.

That is a small problem for a form label and a large one for anything that has to recognise what somebody wrote.

Four words that matched two captions#

Our system recognised a photograph from site as a delivery record only if its caption contained one of four words: challan, bilty, GRN, delivery.

Those are the correct words. They are what the document is called. They appear in the purchase manual, in the training material and on the form.

Measured against four hundred real captions the site team had actually sent, those four words matched two.

What people really write is the material, a quantity and a unit — a concrete grade with a volume and a weight. Or the vehicle: a supplier's mixer has arrived. Or a plain numbered list: a trader's name, then two lines each with a quantity and a unit.

Nobody was refusing to use the official word. They were describing what had happened, in the way a person describes something to a colleague, which is the only way anybody writes when they are not filling in a form.

Reading those three shapes instead — the material named directly, the vehicle that brought it, or any quantity with a unit — took the match rate from two to thirty-four out of the same four hundred captions. Nothing about the site changed.

Why the official word is never the used word#

Three reasons, and none of them is carelessness.

The official word is a category; the used word is the specific thing. Nobody says "a delivery has arrived". They say what arrived.

The used word is shorter. Effort matters enormously when your hands are dirty.

The used word is often not in the interface language. A person typing on a site in India may write in Hindi, in Devanagari or in Roman letters, or mix both in one sentence. A vocabulary list that contains only English words has excluded a large fraction of the input before it starts, and what a supplier's promise of Hindi support usually turns out to mean is examined in software your staff can actually read.

Where vocabulary decides behaviour#

It is worth separating the places where this matters from the places where it does not.

Labels on a form. Matters a little. People adapt.

Search. Matters a lot. Somebody searching for a material by the name the site uses, in a system that stores the purchasing name, finds nothing and concludes the record does not exist.

Recognition of free text. Matters completely. This is the case above, and it is the difference between a feature working and a feature that has never once fired.

Error messages and refusals. Matters completely, and in a different way — a message in a vocabulary the reader does not have is not a message. That is part of the app should tell you why.

How to find the real vocabulary#

Not by asking. If you ask people what words they use, they will tell you the official ones, because a question about vocabulary sounds like a test.

Read what they have already written. Every organisation has a large corpus of real language sitting in its message history, its site diaries, its comment fields and its photograph captions. Take a few hundred, read them, and count.

Two rules make this useful rather than merely interesting.

Measure against real examples, not against intuition. Our four words felt comprehensive. Counting them against four hundred captions is what produced the number two, and no amount of discussion would have.

Keep counting afterwards. Vocabulary drifts, new materials arrive, staff change. A recognition rule that was measured once, three years ago, is a rule whose accuracy is now unknown.

Broadening without becoming wrong#

The obvious risk in accepting more vocabulary is accepting the wrong things.

Our matcher still refuses what is plainly not a receipt: a cylinder going out for refilling, a truck that damaged a divider, a weight dispute. Each of those contains a material, a quantity and a vehicle, and each would be caught by a naive broadening.

Two things make the broadening safe.

Explicit exclusions, drawn from the same corpus. The non-cases are in the message history too, and they are the more valuable half of the reading exercise, because they are what tells you where the boundary is.

Everything is a suggestion. A match is proposed and confirmed with one tap, never filed automatically. That converts the cost of over-matching from a wrong record into two seconds of somebody's attention — which is what makes it possible to be generous with recognition at all. The argument is in the machine proposes, a person decides.

Respect is part of the vocabulary#

One more dimension, easy to miss if you only think about matching.

In Hindi, the difference between the respectful form and the bare imperative is not stylistic. A system that tells people what to do in the familiar imperative reads as rude, consistently, to everybody who receives it — and it is being read by people who are already the least powerful users in the organisation.

Our rule is the respectful form everywhere, without exception. It costs nothing and its absence is felt every single time.

What this is really about#

The general principle is one we keep arriving at from different directions: when the field has settled on a behaviour, the software's job is to read that behaviour rather than to replace it.

People photograph slips because a photograph is faster than a form. People send voice notes because their hands are dusty and the screen is in the sun. People write the material rather than the word "challan" because that is how a person describes a thing to another person.

None of that is going to change, and a system that requires it to change will be worked around by competent people who have real work to do. The wider version of the argument is in WhatsApp is the interface, whether you designed for it or not.

The short version#

The vocabulary in your software is the vocabulary of the people who wrote it.

Find the real one by reading a few hundred real messages and counting, not by asking. Include the languages and scripts people actually type in. Collect the non-cases as carefully as the cases.

And keep every match a suggestion, which is what makes it safe to be generous.