Why we built voice entry instead of a faster form

The wrong race

Billing apps in India compete on speed. Three taps to a bill, then two, then one. It is real work and it makes for a good demo.

It is also the wrong race, and the evidence is that the books are still empty at the end of the month. The competition was never another app. It is the pen, the diary, the pocket, and most often not recording at all.

A form has a floor

A form cannot go faster than the number of decisions it asks you to make. Recording a credit sale means choosing a customer, choosing items, quantity, rate, deciding whether GST is included, and picking a date. You can make each of those one tap. You cannot make them zero, because each is a decision, and a decision needs attention.

Attention is the thing a shopkeeper does not have at four in the afternoon with three people waiting. So the entry is postponed, and postponed entries become a carrier bag of bills and a Sunday of guessing.

The order problem

The subtler problem with a form is that it insists on an order. It wants the customer before the item, the item before the rate, whether or not that is the order you know things in.

A sentence has no order. “Rahul ko 500 ka udhaar” carries the customer, the amount and the fact that it is credit, in whatever sequence the person thought of them. Leave something out and you get asked for that one thing, rather than a form with one field highlighted in red.

This is why it holds up mid-sale. It matches how somebody describes what just happened, instead of asking them to decompose it into fields first.

The obvious objection

Speech can mishear. A noisy shop, an unfamiliar brand name, a number that could be two numbers.

That is exactly why nothing is written until you confirm a card. The app shows who, what, how much, what tax, which date, and waits. A mishearing becomes a wrong name on a screen you correct, instead of a wrong entry found in March.

The card is also the executing tool's own arithmetic rather than a summary of it, so the total you approve is the total that gets booked. A preview computed separately from the thing it previews is a preview that can disagree with it.

When speaking is the wrong tool

Often, and pretending otherwise would be silly:

• A loud shop. Typing goes down the identical path, same card, same confirmation.
• A forty-line bill. Say it once and you will be correcting it for longer than typing would have taken. The invoice screen exists for this.
• Barcodes. If you already scan, scanning is faster and always will be.
• Somewhere you cannot speak. A quiet office, a shared counter, a customer listening to the rate you are giving somebody else.

Voice is not the product. It is one door into it, and it happens to be the one that is open at the moment a sale actually occurs.

How we would know if we are right

Not by how the demo looks. By whether entries happen on the day they happened, and whether the month-end pile is smaller than it was.

If a merchant still records everything on Sunday, the feature failed, however good the speech recognition was. That is the measure we would accept, and it is a harder one than taps per bill.

Frequently asked questions