Why Your Commerce Chatbot Needs to Understand Hinglish

Six words, four problems

A retailer sends this at 9:40 PM:

5 peti parle g bhejo kal tak

A bot built for clean English sees noise. Here is what is actually in there.

Code-mixing. The sentence runs Hindi grammar with English nouns, written in Latin script. It is not English and it is not Hindi — it is the register most Indian trade runs on, and language detection routines usually label it "English" with low confidence and move on.

Transliteration with no fixed spelling. "bhejo" may arrive as bhejo, bhejho, bhejdo, bhej do. There is no standard romanisation of Hindi, so spelling varies by person and by keyboard. String matching fails; you need fuzzy matching or a model that has seen the variants.

Trade units. peti is a case. How many pieces are in a peti depends entirely on the SKU — a peti of biscuits and a peti of shampoo sachets are different counts. The bot cannot resolve quantity without a product master, and this is where wrong orders get shipped. The Wholesale Unit Converter does this arithmetic for a human; a bot needs the same mapping in data.

Brand shorthand. "parle g" is Parle-G. Retailers write maggie, magi, surf ex, colgt. Exact matching against a catalogue misses most of it.

Any one of these breaks a naive parser. Together they are why so many Indian commerce bots quietly get abandoned after a month — retailers try them twice, get "Sorry, I did not understand", and go back to calling.

What the bot has to extract

Strip the linguistics away and an order message contains at most five things:

Most messages carry three or four of these. The design goal is not to understand language in general — it is to fill this table, and to ask a good question when a cell is empty.

That reframing matters, because it makes the problem finite. You are not building a conversational assistant. You are building a form that accepts messy input.

Intents worth handling, in priority order

Build these in the order they occur, not the order they are interesting:

1. 1.Place an order — the majority of messages, and the only one that directly bills
2. 2.Check price or availability — usually the step before an order
3. 3.Check balance or ledger — high volume, fully automatable, no judgement needed
4. 4.Track a delivery — high volume, needs a data source more than intelligence
5. 5.Complain — low volume, and should route to a human immediately

The fifth is worth stating plainly: a bot that tries to handle a complaint about a damaged consignment makes things worse. Detect the intent, hand it to a person, and say so.

Voice notes are not optional

A significant share of retailer messages in Indian trade arrive as voice notes, especially from older shopkeepers and from anyone driving or standing in a busy shop. If the system only reads text, it silently ignores a chunk of demand.

Speech recognition for Indian languages has improved sharply, but it degrades on exactly the conditions that matter here: shop noise, regional accents, and code-mixed speech. Two practical mitigations:

• •Confirm what was transcribed before acting on it. A voice note that becomes an order should always echo back as text for a one-word confirmation.
• •Keep a human fallback for the notes that transcribe badly, rather than guessing.

Confirmation design decides whether it survives

The single biggest determinant of whether retailers keep using an ordering bot is not parsing accuracy. It is what happens when the parse is imperfect.

Compare:

Sorry, I did not understand your message.

against:

Parle-G 100g — 5 peti = 120 pcs. Deliver tomorrow. Reply YES to confirm, or send the correct quantity.

The second recovers the order even when the parse was only 80% right, because the retailer corrects one field instead of retyping everything. It also produces training signal: every correction tells you which token your parser missed.

Show the resolved quantity in pieces, not just the unit the retailer used. "5 peti" confirmed back as "5 peti" hides the exact ambiguity most likely to cause a wrong delivery.

Where to start if you are building this

Collect two hundred real messages from your own retailers before writing any parsing logic. Not hypothetical messages — actual ones, from your actual WhatsApp. Tag them by intent and pull out every unit, abbreviation and brand spelling you find.

That corpus will tell you things no general model knows: that your Bihar retailers say dabba where your Punjab retailers say peti, that half of them abbreviate your best-selling SKU in a way your catalogue does not contain, and which three intents cover 80% of your traffic.

Build for those three. Route the rest to a human, and expand only when the data says to.

For the wider question of what AI does and does not change in B2B selling, see AI for B2B sales in India. For the messaging plumbing underneath all of this, start with the WhatsApp Business API setup guide.

Voice notes deserve their own design

Text and voice fail differently, and treating them the same is why voice support usually disappoints.

A mistyped word is usually still recognisable. A misheard word is often confidently wrong — the transcript reads as a valid sentence that says something the retailer never said. That makes silent failure far more likely.

Three practical rules:

• •Always echo a voice order back as text before acting on it. Never act on a transcript directly.
• •Keep the confirmation short. A retailer who sent a voice note because typing was inconvenient will not read six lines back.
• •Route poor transcriptions to a human rather than guessing. A confidence threshold you tune over a few weeks is enough.

Shop noise, regional accents and code-mixed speech all degrade recognition, and those are the normal conditions in Indian trade rather than edge cases.

The product master does the heavy lifting

Most of what looks like a language problem is actually a catalogue problem.

When a retailer writes "parle g", the model's job is to output a normalised token. Turning that token into a specific SKU with a specific pack size is a lookup — and if your catalogue is not built for fuzzy lookup, the best parser in the world still fails.

Three things a distribution catalogue needs before any bot will work:

• •Aliases per SKU. Every spelling your retailers actually use, harvested from real messages. Not what marketing calls the product.
• •Unit conversions per SKU. How many pieces in a peti, a dozen, a case. This is the field most likely to be missing, and it is the one that causes wrong deliveries rather than failed parses.
• •A default pack size. When a retailer says "5 Parle-G" without specifying grammage, you need a defensible assumption and a confirmation step.

Skipping this and blaming the model is the most common failure I see in these projects.

Measuring whether it works

You need two numbers, and they measure different failures.

Parse rate — the share of messages the system extracts a complete order from without asking a clarifying question. This measures how well the parser handles your retailers' actual language.

Correction rate — the share of confirmed orders the retailer changes before accepting. This measures whether the parse was right, not just complete. A high parse rate with a high correction rate is worse than a lower parse rate with clean confirmations, because it means the system is confidently wrong.

Track both from day one. If you only track the first, you will optimise toward a bot that confidently ships the wrong cartons.

Building this without a data science team

You do not need to train a model from scratch. The realistic sequence for a distributor:

1. 1.Collect 200 real messages from your own WhatsApp. Not hypotheticals — actual retailer messages, with their spellings and units.
2. 2.Tag them by intent and pull out every unit, abbreviation and brand spelling. This becomes your alias list and your test set.
3. 3.Handle the top three intents only. They will cover most of your traffic. Route everything else to a person.
4. 4.Confirm every parse before acting, showing the resolved quantity in pieces.
5. 5.Log every correction. Each one tells you exactly which token failed, and that log is worth more than any general-purpose training data.

The corpus in step one is the asset. It encodes that your Bihar retailers say one thing and your Punjab retailers say another, which no general model knows about your business.

Start narrower than feels right

The temptation is to launch handling everything. The systems that survive launch handling one thing well.

Pick your single highest-volume intent — for most distributors that is placing an order — and handle only that, with a human fallback for everything else. Retailers forgive a bot that says "let me get someone" far faster than one that confidently misunderstands.

Expand only when the correction rate on the intent you already handle is low enough that you would defend it to a retailer.

FAQ

Common objections when teams scope this work.