The Problem No Keyword Search Can Solve
Someone types: "need a cheap 2BHK deep clean before Diwali, prefer Saturday, eco-friendly products."
There is no keyword in there that maps cleanly to a category. "Cheap" is relative. "2BHK" is a size constraint. "Before Diwali" is a deadline, not a date. "Eco-friendly" is a product preference. "Saturday" is a scheduling constraint. And none of the actual local home-cleaning businesses in your city have written those exact words in their listings.
A keyword search engine will either return nothing useful, or will return a flood of irrelevant results ranked by ad spend. The person asking has a clear, specific need. The supply exists. The gap is in translation — from a messy, natural human expression to the right real-world supplier.
This is not a niche failure. It is the default experience of trying to find local services in India today. The request is human. The catalogue is sparse. The match has to be smart.
Why Local Indian Data Makes This Hard
Most local service providers in India — cleaning services, repair shops, tutors, caterers — do not have structured online listings. Where listings do exist, they are often out of date, missing key attributes (area served, minimum order, product type), or described in a mix of languages. A cleaning business in Pune might describe itself in Marathi, use English for its WhatsApp number, and list its services in a format designed for a 2018 form.
Sparse, inconsistent, multilingual, and location-ambiguous data. That is the baseline. Any matching system that requires clean structured input at the supply side is going to fail.
Step One: Stop Treating the Request as a Query
The first shift is to stop treating what a customer types as a search query and start treating it as an intent.
An intent has structure even when the text does not. It has:
- What — the core need (home cleaning, not just "clean")
- Where — explicit city or implicit from context
- When — a deadline or preferred timing
- Constraints — budget signal, product preferences, size or scope
An intent parser extracts this structure from free-form text. It does not need the person to use the right category name. It needs to understand that "before Diwali, prefer Saturday" means a specific week, that "2BHK" is a service scope, and that "eco-friendly" is a filter on how the job should be done — not just a tag. This step alone rules out a large number of false positives that keyword search would have served.
Step Two: Represent Everything in a Shared Meaning Space
Once you have a structured intent, the matching problem becomes: find suppliers whose capabilities are meaningfully close to this intent, even if the words used are completely different.
This is where semantic matching comes in. The idea is to convert both the intent and each business/product description into a numerical representation — a vector — that captures meaning rather than surface form. Two things that mean the same thing end up close in this space even if the words are different. "Eco-friendly cleaning" and "natural product housekeeping" end up near each other. "Before Diwali" and "late October weekend availability" end up near each other.
The matching engine queries this representation space and retrieves the suppliers whose meaning is closest to the customer's intent. No exact keyword overlap required.
Building and maintaining this space for local Indian data requires ongoing work. You need to handle code-mixed input (Hindi-English hybrids are common). You need to periodically re-index supply as businesses update what they offer. And you need to weight location heavily — a semantically perfect match fifty kilometres away is less useful than a decent match in the same neighbourhood.
Step Three: A Lightweight Agent Layer That Collects Real Quotes
Semantic retrieval gives you a ranked list of relevant businesses. But a ranked list is not a resolved need. The customer asked for quotes — live, from real suppliers.
The next layer is an agent that acts on the retrieval results. For each matched business, it reaches out — via the communication channel that business actually uses — and asks for availability and pricing for this specific request. Not a static catalogue price. A response to this particular job.
This sounds simple. In practice:
- Businesses respond at different speeds and through different channels.
- Some will respond with a price. Some will want to call. Some will need clarification on scope.
- The agent has to handle partial responses — assembling whatever has come back within a reasonable window and surfacing it to the customer, rather than waiting for a complete set of replies that may never arrive.
The output is a single organised view: here are the businesses that responded, here is what they said, here is how to proceed with any of them.
The Honest Hard Parts
Ranking without ad spend. The temptation in any marketplace is to sell ranking. We deliberately do not. Ranking is done on intent match quality, estimated reliability, and response rate. A business that consistently responds to requests and shows up accurately in search should rank above one that has paid more.
Freshness. A business that served a certain area last year may have moved or changed scope. The index has to be refreshed, not just built once.
Cold start on the supply side. Getting new local businesses into the system — and getting their offerings described richly enough to match non-obvious requests — is ongoing human work, not a one-time data import.
Precision vs. recall. For a hyperlocal service, a false positive (matching a business that cannot actually do the job) is worse than a miss. We bias toward precision: surface fewer, more confident matches, and let the agent layer confirm before presenting to the customer.
Why This Pattern Matters Beyond Home Services
The same matching problem appears across local commerce:
- "Need a vegetarian caterer for 40 people, no onion/garlic, budget around 250 per head, Bangalore north"
- "Looking for a tailor who does blouses for silk sarees, quick turnaround, near Malleswaram"
- "AC repair, 1.5 ton split, need someone who stocks specific spare parts"
In each case: a specific, constrained, natural-language need; a local supply that exists but is not findable by keyword. The same pattern applies — parse intent, match on meaning, activate the supply via an agent layer, surface live responses.
What We Built
Bino is the consumer-facing surface of this system — a WhatsApp-based tool where you describe what you need in plain language and get back real options from local businesses, with quotes, in your chat. The matching, retrieval, and agent orchestration happen in the background. No forms, no category browsing, no dead catalogue pages.
It is early, the Indian local data problem is genuinely hard, and there is significant work still ahead. But the core insight — that matching a human need to local supply requires meaning-level understanding, not keyword overlap — is what makes the difference between a system that works and one that returns noise.
Top comments (0)