The language barrier is the adoption barrier
A retailer in Gujarat orders in Gujarati. An interface that requires translating their intent into a foreign language and taxonomy imposes a cost on every single order.
FIELD NOTES / SUPPLY CHAIN & FMCG
The order arrives spoken.
In Gujarati.
A retailer speaks their order aloud — “give me twenty packets of 500ml Gold” — and VaaniFlow transcribes it, resolves the SKU, separates pack size from order quantity, applies live trade-promotion rules, and speaks a confirmation back in Gujarati.
SUPPLY CHAIN CASE STUDY
VaaniFlow
Gujarati voice capture.
Deterministic interpretation.
VaaniFlow / Voice order captureACTUAL PRODUCT INTERFACE
THE INTERPRETATION PROBLEMTwo numbers. Two different meanings.
In “twenty packets of 500 ml”, one number is pack size and one is order quantity. Getting them backwards is wrong by a factor of 25.
Follow the order ↗SpeakTranscribeInterpretPriceConfirm
DOMAIN
FMCG dairy distribution
WHAT WE BUILT
Voice-first order capture platform
OUR ROLE
Product architecture to backend engineering
01 / THE ORDER CAPTURE GAP
The front door of the supply chain
is its least digital step.
In dairy distribution, order volume is high, order value per line is low, and the ordering window is short and daily. That combination makes the cost of capturing an order disproportionately important.
Orders arrive by phone call, WhatsApp voice note and handwritten route book, then get re-keyed into an ordering system hours later by someone else. Every re-keying step is a chance for the wrong SKU, pack size or quantity to enter the system.
Typed self-service apps solve the structure problem and create a new one: they assume the buyer will navigate a SKU catalogue on a phone keyboard, usually in English. For a large share of the retail base that assumption does not hold, and adoption stalls.
A transcript is not a SKU
Product naming is loose, units are inconsistent, and descriptive attributes carry meaning — butter with salt and butter without salt are different products.
Promotions apply only when someone remembers
When capture happens through a person on a phone, promotion application depends on whether they recall the current scheme — and there is no record of when it was offered.
02 / INSIDE THE PRODUCT
Speak the order.
Hear it back.
Five views of the delivered platform.
Each shows another step from spoken request to structured record.
The buyer never changes how they work.
The platform listens in Gujarati and replies in spoken Gujarati — the buyer never has to read, type or parse English at any point in the interaction.
SPOKEN REQUEST TO STRUCTURED ORDER
Speak→Transcribe→Resolve SKU→Split quantity→Apply promotion→Speak back→Confirm
03 / INTERPRETATION, NOT GUESSWORK
Rules decide the numbers.
Not a probabilistic model.
This was treated as an interpretation problem wrapped in a language problem, not a speech feature bolted onto an ordering app. Deterministic rules — not a model's judgement — decide which number is pack size and which is order quantity.
The cost of a bad order is paid downstream, repeatedly: a wrong delivery, a return, a credit note, and a call to customer service, long after capture.
Look under the hood ↘01
Transcribe the spoken order
Gujarati speech becomes text, with the original utterance retained as the evidence behind the record.
Resolved deterministically
Known product names, units and quantity patterns are matched by rule, so the same phrase always produces the same order.
Surfaced, not assumed
Where interpretation is uncertain, the buyer hears it back and confirms rather than the system committing a guess.
02
Resolve product and quantity
Fuzzy matching resolves loose product naming to a SKU, and deterministic rules separate pack size from order quantity.
03
Confirm in the same channel
The platform speaks the interpreted order back in Gujarati, and the record stays unconfirmed until the buyer commits.
04 / THE TECHNOLOGY & THE REASON
Speech at the edges.
Rules at the centre.
The stack keeps language handling at the boundary and interpretation deterministic in the middle, so the part that decides what was ordered is testable rather than probabilistic.
PY
APPLICATION
FastAPI
Carries order capture, interpretation, promotion evaluation and the order lifecycle.
Why one service?
Interpretation and pricing decide the same order; splitting them would mean two places that could disagree about it.
SAI
SPEECH
Sarvam AI
Gujarati speech-to-text and text-to-speech, so the platform both listens and replies in the buyer's language.
Why speak back?
Confirmation has to arrive in the same channel and language the order did, or the buyer is still being asked to switch.
RF
MATCHING
RapidFuzz
Resolves loose, phonetically imprecise product naming against the catalogue to a specific SKU.
Why fuzzy matching?
A transcript is not a SKU — buyers say “Gold” or “gold milk”, not a catalogue code.
RECORDS
PostgreSQL + SQLAlchemy
Holds the catalogue, promotion rules and the structured, auditable order record created at capture.
Why structure at capture?
If the order never becomes structured data at that moment, nothing downstream can be built on it.
JWT
IDENTITY
JWT + bcrypt
Authenticates the retailer, salesperson or distributor desk placing the order.
Why attribute the order?
A low-friction channel needs commitment to be deliberate and attributable to someone.
RUL
INTERPRETATION
Deterministic rules
Separate pack size from order quantity, normalise units, and read descriptive attributes as product-defining.
Why not let the model decide?
Reading the two numbers backwards produces an order wrong by a factor of 25 — that decision has to be testable.
The architecture and product narrative reproduce the supplied project documentation. Interface values are product screen data.
Explore the documented platform stack
- Application
- FastAPI · Python · order capture and lifecycle
- Speech
- Sarvam AI · Gujarati speech-to-text and text-to-speech
- Interpretation
- RapidFuzz product matching · deterministic pack-size and quantity rules · unit normalisation
- Data
- PostgreSQL · SQLAlchemy · catalogue, promotions and order records
- Identity
- JWT · bcrypt
Technology names identify the documented implementation, not partnerships or endorsements.
A CONVERSATION ABOUT YOUR ORDER CAPTURE
Where does your order
stop being data?
Bring one point in your distribution network where orders arrive unstructured — phone, voice note, or route book. In 20 minutes, we will map what interpretation has to be deterministic, and what a buyer has to confirm.
20 minutes · Your catalogue, channels and constraints