The voice note is the report

On any Indian construction site, a significant share of what gets reported is spoken, not typed.

The reason is not preference. A person outdoors, holding a phone, with dust on their hands and sun on the screen, can hold a button and talk in five seconds. Typing the same content takes a minute and a half and requires reading what they have written, which in that light is genuinely hard.

So voice notes arrive constantly. And in almost every organisation they are stored as an audio file with a label, sitting in a thread, opened by nobody.

The comment that had known for a year#

The most uncomfortable part of our own version of this story is that we had written the reason down and then done nothing with it.

A comment in our code said, plainly, that a site engineer sends a voice note because his hands are dusty and the screen is in the sun. It had been there for a long time. The voice notes went on being a labelled blob nobody read.

That gap — between understanding a thing and having built for it — is a specific and common failure. It is not ignorance. It is that the understanding lived in a comment, which agrees with itself for ever and stops nothing. The same observation, made about a styling rule, is in capitals are a contrast, not a volume: a rule written as prose survives exactly as long as the memory of the argument that produced it.

Transcription is the easy half#

Turning recorded speech into text is a solved problem to a workable standard, including for Hindi and for the mixture of Hindi and English that people actually speak.

Doing it is not the interesting part. What happens to the words afterwards is.

The wrong answer — and it is the answer most implementations reach — is to put the transcript in the thread and stop. Now there is text nobody reads instead of audio nobody plays. The reporting problem is untouched.

Same words, same doors#

The rule we settled on is that a transcribed voice note takes the normal door.

A spoken incident report classifies and registers exactly as a typed one would. A spoken answer to the evening list of outstanding work is treated as that answer. A spoken question gets an answer grounded in the records, the same answer a typed question would get. A spoken report from a contractor becomes the same kind of card a written one becomes.

Not a similar path. The same two dispatch functions a typed message goes through, called with the transcribed text.

This is a construction constraint rather than a preference. A parallel path for spoken input would be a second implementation of every classification rule, every permission check and every routing decision in the system. Two implementations of one rule agree at first and then drift, and the drift is silent because each is internally consistent. That failure mode is described in a fact that had no owner.

What to do with audio that cannot be read#

Some recordings are unusable. Wind, machinery, a pocket recording, thirty seconds of a conversation with no subject.

The correct outcome is not to retry for ever and not to fail silently. It is to mark the item as tried and empty and leave the queue. That state is different from not yet processed and different from failed, try again, and collapsing the three produces either an endless retry loop or a queue that looks clean while quietly discarding things.

This is the same distinction that matters for offline attendance punches, where a phone must know the difference between try again later and stop retrying this one. It is in attendance on a site with no signal.

Where the transcription should run#

We run ours on our own hardware, with the same model the rest of the estate uses, and voice is treated as first in the queue because a person is waiting for the result.

Two reasons for keeping it local, and only one of them is about cost.

The first is privacy. A voice note from a site contains names, rates, complaints about people, and occasionally something personal that was sent to the wrong thread. Sending all of that to an external service is a decision somebody should make deliberately rather than by default.

The second is that it removes a dependency on a third party for a function people come to rely on daily. A transcription service that is unavailable makes the whole reporting channel feel broken, and site staff who try something twice and get nothing do not try a third time.

The privacy boundary comes first#

One rule we had to learn by getting it wrong on the image side, and it applies identically here.

Processing must happen after the check that decides what may be processed, not before. Our text extraction on photographs once ran ahead of the gate that knew which rooms were private, so a personal picture was read and, if its content resembled a delivery document, filed as a goods receipt.

The fix was not to discard the output. It was to exclude private material at the query, so the bytes are never fetched at all. A control that runs after processing is a cleanup, not a control.

For voice this matters more, because speech in a private thread is more likely to be personal than a photograph in one, and a transcript is far easier to read by accident than an audio file is to listen to.

What it changes on site#

Nothing, which is the point.

The person on site does what they were already doing. The report they were already making becomes a record. Nobody is asked to learn a form, to log in, or to change a habit that exists because of dust and sunlight. What that record has to carry, and what should stay out of it, is what a site engineer should record.

That is the general principle behind all of this work and it is worth stating plainly: when the field has settled on a behaviour, the software's job is to read that behaviour, not to replace it. The wider argument is in WhatsApp is the interface, whether you designed for it or not.

The short version#

Voice notes are how sites report, for reasons of dust and sunlight rather than preference.

Transcribing them is the easy half. Making the words take exactly the same path a typed message takes is the half that matters, because a parallel path is a second copy of every rule you have.

Mark unreadable audio as tried and empty rather than retrying for ever, run the transcription where the privacy decision is yours to make, and check that the privacy gate runs before the processing rather than after it.