Household and facility surveys for districts: GPS proof of visit, roles by block, a full audit trail.
Household surveys, scheme saturation surveys and facility mapping (schools, anganwadis, PHCs, water) — run with an enumerator-and-supervisor app and a DM/CEO dashboard. Every village and ward carries its LGD code, every visit is GPS-checked, every change is audited, and the data stays in India.
LGD-mapped geography, administrative roles and audit-grade controls — built in.
Most government survey software is either a foreign form builder with no idea of Indian geography, or Excel passed around on WhatsApp with no proof behind it. Here is what we set up from day one.
State → district → block → gram panchayat → village, and ULB → ward — 36 states and UTs, with LGD codes. Every record carries the official code, Hindi and English names, source and version, so reports line up with other government systems. Enumerators never type a village name; the code comes from the assignment, so ‘Saidpur’ and ‘Sayeedpur’ never become two rows.
Each role sees only its own area and team. Role, area and seat rights are checked on every API request — hiding a button isn’t security. The DM or CEO gets a Viewer or Admin role with no seat. If an enumerator leaves, the same seat moves to a newly named person, and the server checks seat and device on every activation.
Who changed what, when and why — the full history. Daily database backups plus weekly snapshots, with a restore test in the acceptance criteria. Servers in India, tenant isolation, practices aligned with the DPDP Act 2023. Opening a sensitive record asks for a reason, and that reason stays in the log.
Keep scrolling and you move down one level at a time. Each level settles two things: who sees what there, and which code is attached to the record.
The geography model covers all of India — 36 states and union territories with LGD codes. Uttar Pradesh is loaded first; any other state loads from LGD's per-state files in 1–2 days.
The district officer sees the whole district: block-wise targets, visits, approvals and records in review. The district admin activates enumerator seats and assigns each block officer their area. District boundaries come from open polygons.
A block officer sees only their own block — checked on every API request, not just hidden on screen. Training, supervisor teams and the daily review usually run at this level, and this is where alerts land.
The usual unit for rural work — GPDP, scheme saturation and facility surveys are counted here. A GP holds one or more revenue villages; the village-to-GP mapping comes from LGD, and any gap shows up in the missing-mapping report on day one.
The enumerator's unit of assignment. Village boundaries are approximate — a centroid and a radius — so the badge says ‘approximately in area’, never a false ‘verified’. Two villages with the same name stay apart by code.
A settlement missing from the official list gets a local operational ID so its homes aren't skipped — but it is never declared an official village. A home is identified by household ID, house label, landmark and GPS.
Nagar nigam, nagar palika parishad and nagar panchayat — all three with LGD codes. The ward is the urban unit of assignment; the mohalla is an operational layer. A district's rural and urban surveys can run in one project.
Household survey, facility survey, scheme saturation, roles and security. Switch tabs to see what a district officer sees and what an enumerator sees.
District → block → GP → village, training, field, QA, report
Scroll on the left and the screen on the right changes. This is the same order we run every pilot in — start with one block or one municipality, then the district.
From the war room to the doorstep — honest data at every level
Block-wise progress and quality with honest timestamps
Target homes, visits, completed, approved — by block and by panchayat. Quality: pending review, exceptions, unclear location. Local problems by type, duration and severity. If the network drops, the dashboard says plainly ‘last updated 18 minutes ago’ — old data never poses as live.
Rural, urban and electoral hierarchies, LGD-coded — approximate boundaries labelled honestly
Three related structures side by side: administrative (district → tehsil → revenue village), local body (block → gram panchayat → village; nagar nigam / palika / nagar panchayat → ward → mohalla), and optional electoral (Lok Sabha → Vidhan Sabha → polling station). Every record carries the official code, Hindi and English names, source and version.
Ward wise household survey software for ULBs: nagar nigam, palika, nagar panchayat
In urban surveys, house labels and landmarks matter more than in villages — forty homes in one lane, each with an incomplete house number. In Bharat Survey the household ID, house label and GPS together make the identity, matched against the approximate ward boundary. Nagar nigam, nagar palika and nagar panchayat — all three ULB types carry LGD codes.
Enumerator app at the doorstep: consent-first, offline, honest sync
The enumerator reaches the home, runs the arrival check, reads the introduction and consent, fills the family roster, records scheme-wise status, takes the photos that are needed and submits — all offline. Each section is saved to the phone’s encrypted database; data comes back after the app closes or restarts; sync starts once a signal returns.
Enumerator app, supervisor, block and district officers, viewers — role and area checked on every request
Who can see what is decided by a check on the server, not by hiding things on screen. Below: each role’s job, and whether it uses a seat.
‘Today's work’: assigned village or ward, household list, forms, sync status. One seat = one named person = one authorised device, OTP login. No location is collected outside a shift.
Leads 5–15 enumerators. Reviews from a risk-scored queue, returns corrections with a reason, runs back-check visits. Sees only their own team and villages.
Only their own block: GP-wise progress, alerts, quality summary. Sample: Block Bhanwarkol is at 46% — send tomorrow's team there.
The whole district, block-by-block comparison, and four reports — progress, quality, local issues, help requests. Works in a phone browser too.
Senior department officers or a partner institution. They can look but not change anything, contact details stay hidden, and every access is logged.
Geography import, form build, training and first-day support. Support staff get module-limited permissions; any sensitive access is logged with a reason.
Household, scheme saturation, facility, ward-wise and panchayat surveys, monitoring visits
Six cards, stacked. The frame stays the same in every survey — assignment, offline form, location status, QA, LGD-coded report. Figures on screen are samples.
Family profile, livelihood, housing and amenities, scheme access — village- or ward-wise, with a member roster. The household ID is permanent, so a repeat survey lands on the same record. Sample: HH-31877 has 6 members on the roster and its Ayushman card status is ‘application pending’.
Which home received which scheme — eligible versus covered, with block- and GP-wise gap reports. Camp lists come straight from the gap. Sample: in Block Saidpur the tap-connection gap is 1,278 homes, with a GP-wise list in Excel.
Schools, anganwadis, PHCs and CHCs, handpumps, roads, community toilets — checklists, ratings, photos, a permanent ID and a GPS pin. Sample: SCH-0418 was submitted far from the school, so it was flagged ‘out of area’ and left out of the inspection count.
Gram Panchayat Development Plan (GPDP) or ward-wise needs assessment for a municipality — a priority list before the gram sabha or ward sabha. Water, roads, drains and power problems are logged with type, duration and severity, then ranked panchayat by panchayat.
Help requests raised during a survey go to a separate ticket module: received → assigned → in action → closed, with contact details in a separate vault. Survey answers and a citizen's mobile number never sit in the same table — only the person resolving the ticket sees the contact.
A GPS-backed record and checklist for officers' field visits, so a report can state that the inspection actually happened. Short form: arrival check, 6–8 questions, photos, remarks. Planned visits and actual visits in one list.
LGD code, ULB, ward, GP, enumerator, back-check
Tenant isolation, RBAC, encryption, audit, backups, data in India
| Control | What happens | In v1 |
|---|---|---|
| Role + area permissions (RBAC) | Identity, role, area and seat rights checked on every API request | |
| Audit log | Who changed what, when and why; full record-edit history; sensitive access logged with a reason | |
| Encryption | HTTPS in transit; sensitive fields at rest; encrypted local database on the phone (SQLCipher) | |
| Backup / restore | Daily database backup + weekly snapshot; restore test in acceptance criteria | |
| Data in India | Servers in India; consent text, purpose limits, retention and deletion aligned with the DPDP Act 2023 | |
| Tenant isolation | Each department’s or district’s data separated at database level (Row-Level Security) | |
| Scoped staff permissions | QA-only, geo-data-only, support-only — support staff don’t see every record | |
| On-premise / state data-centre hosting | Deployment on the department’s own servers | Ask — v1 runs on cloud (India) only |
| SSO / state identity login | Integration with departmental SSO |
Paper and Excel vs a generic form tool vs an LGD-mapped enumerator platform
All three will get a survey done. The difference shows when someone asks: which village is this record from, who filled it, and did they actually go there?
| Question | Paper + Excel + WhatsApp | Generic form tool | Bharat Survey |
|---|---|---|---|
| Village / ward identity | Handwritten name — spelled many ways | Build your own dropdown, every project | LGD code, automatic from the assignment |
| Proof of visit | A GPS point; matching to area is on you | Five location statuses; ‘out of area’ kept out of counts | |
| A full day without network | Yes — but data entry happens later | Depends on the tool | |
| Block officer sees only their block | By splitting Excel files | Often project-level permissions only | Role + area, on every API request |
| History of corrections and back-checks | Limited | Linked to the parent record, with reasons | |
| Who changed what — audit log | Depends on the tool | ||
| Enumerator app in Hindi | — | Hindi labels; menus and errors often English | |
| Data in India, restore-tested backups | Files spread across laptops | Hosting often abroad |
LGD code, household survey format, enumerator training checklist, facility survey types
These four questions come up in every first meeting. The answers don’t depend on our product — they hold whichever system you pick.
The Local Government Directory (LGD) is the Government of India’s official register, maintained by the Ministry of Panchayati Raj at lgdirectory.gov.in. It holds a permanent numeric code for every state, district, sub-district or block, gram panchayat, village, urban local body and ward, along with village-to-GP mappings and lists of parliamentary and assembly constituencies. The data is available per state as XLS/CSV without a login. It has no lat/long, so polygons or centroids for maps have to come from other open sources.
In a survey the LGD code solves three problems. (1) Same-named villages — three ‘Rampur’s in one district, each kept apart by its code. (2) Spelling — ‘सैदपुर’, ‘Saidpur’ and ‘Sayeedpur’ are the same place, and the code doesn’t change. (3) Matching — a shared key for joining scheme portals, state dashboards and census-based data. The rule: every survey record carries the village or ward LGD code as a column, not just a name. Bharat Survey does this automatically and gives you a missing-mapping report on day one.
A good format has six blocks. Identity: household ID (from the system), village or ward LGD code (from the assignment, never typed), house label (‘near the pond, blue door’), landmark, GPS (from the arrival check). Introduction and consent: who, why, where the data goes, voluntary; time and version recorded automatically. Head of household + roster: each member’s age, sex, education, occupation and marital status, as a repeat group so four members or eleven both work. Housing and amenities: house type, toilet and whether it’s used, drinking-water source, power, cooking fuel. Scheme access: status per scheme — received / application pending / eligible but not received / ineligible. Visit outcome: complete / partial / locked / refused / revisit, plus photos where appropriate (of the facility, never of faces).
(1) Keep open text to a minimum — nobody types at a doorstep; give options and keep ‘Other’. (2) Put a constraint on every number, with the error message in Hindi — ‘age between 0 and 110’. (3) Keep ‘don’t know’ and ‘not applicable’ as separate options — both stay out of the denominator, but their counts go into the report. Sensitive questions such as caste or religion only when the department has a clear need and approval — and even then, optional.
Forty-five minutes is enough if training follows the order of the app rather than a feature list. First 10 minutes: login, device binding, ‘today’s work’, and understanding that forms download in the morning where there is network. Next 20 minutes: one complete home — start shift, arrival check (learning to wait for GPS), reading the consent, roster, photos, submit, checking sync status. Next 10 minutes: three special cases — locked house, refusal, and a validation error. Last 5 minutes: what a correction request looks like, and ending the shift.
Role-play is not optional: every enumerator fills at least two mock homes and records one ‘locked’. Supervisors train separately on the review queue, reading risk scores, returning corrections with reasons, and back-check visits. Offer phone support on the first field day — most questions arrive in the first two hours and are about ‘GPS not found’ or ‘when will it sync’.
Education: primary and upper-primary schools — building, number of classrooms, separate toilets for boys and girls, drinking water, power, boundary wall, mid-day meal kitchen, enrolment and attendance; 3–5 photos. Health and nutrition: anganwadi centres — building condition, weighing scale, nutrition stock, registered children; PHCs, CHCs and sub-centres — 24×7 status, staff, medicine stock, delivery facilities. Water and sanitation: handpumps, tap connections, tanks, community toilets — working or not, observed water quality, use. Infrastructure: roads, drains, street lights, panchayat bhawan, garbage points.
Shared rules across every type: a permanent ID and GPS pin for the facility (from the list or the first visit); checklist questions that can be answered by looking; a photo for every ‘no’; and re-inspection on the same ID so change is visible. A submission made far from the facility is marked ‘out of area’ — being able to put that status in an inspection report is the real value of a facility survey app.
Sample district report outline, block-level rollout checklist, ghar ghar survey app mistakes to avoid
These outlines are samples — your department’s format and government orders will change them. The point is to know what needs deciding before the first meeting.
Part A — work progress: target homes, visits, completed and approved in block → GP → village order, with the LGD code on every row. Villages not yet started go on a separate list. Part B — data quality: pending review, rejected, counts by location status (in area / at boundary / outside / weak signal / suspected fake GPS), back-checks done and how many matched, average interview duration per enumerator. Part C — findings: scheme-wise saturation and gaps, housing and amenity indicators, local issues — n beside every percentage, ‘don’t know’ shown separately. Part D — help requests: received, assigned, in action, closed. Annexures: form version, consent text, missing-mapping list, and limitations — which hamlets sit on operational IDs.
Bharat Survey produces Parts A, B and D as ready reports, and the data for Part C in Excel/CSV/PDF with LGD code columns. Where a department wants more than a platform, we can also take on survey design, field data collection and evaluation reporting as a service, scoped in the quotation. Policy recommendations and their interpretation remain the department’s.
Many departments already run an NIC survey app or an eSurvey portal government staff maintain for a specific scheme, and those often stay in place. Bharat Survey fits alongside them: LGD-coded exports let records be matched without re-keying. It’s also worth being clear about names — the Sahyog app Survey of India publishes belongs to Survey of India, a separate government organisation, and has no connection to Bharat Survey.
In the morning, enumerators open the app at block headquarters and download today’s village, household list and forms. During the day the block officer watches the live map and alerts — whose shift is running, who has been inactive too long, where an ‘out of area’ submission came from. In the evening the supervisor clears the risk-scored queue: approve, hold or reject, with a reason. At week’s end there’s a block-wise quality summary — how many records each enumerator had returned, which question keeps getting filled wrong. That summary becomes the agenda for the next training.
1. Starting with the whole district. Pilot one block or one municipality first — catching form errors in 200 homes is cheaper than in 2 lakh. 2. Letting enumerators type village names. You’ll get ten spellings; villages should come from the assignment, with LGD codes. 3. Counting targets on submissions. Count approved records; otherwise ‘out of area’ entries will make a target look met. 4. No rule for locked houses. Decide how many revisits and at what times, or migrant families quietly drop out of the survey. 5. Forty enumerators per supervisor. Keep the ratio at 5–15; only then does the review queue empty every day.
In government procurement, ‘yes, everything is possible’ is the most expensive sentence. In these situations we will say no in the first meeting, or state the limit clearly.
What is in the delivery, and the path from a one-block pilot to district scale
In government procurement the most expensive thing is a promise that breaks at delivery. So: no client logos (we don’t have any to show yet), no ‘crores of records’ claims, and a plain list below.
Book a government demoLogins, access, corrections, exports, backups — all in one log. When someone asks who changed a record and why, the answer comes from the record, not from memory.
LGD codes, the enumerator app, facility surveys, security and procurement — the questions that come up in every district meeting.
Both, depending on what the department needs. Many districts already have enumerators — ASHAs, anganwadi workers, panchayat staff — and only need the platform: the offline enumerator app, supervisor QA and the district dashboard. Where staff are short, Bharat Survey can also field trained data collection teams for a project and hand over the same LGD-coded data. Scope, team size and price are set in a written quotation.
We don’t claim any empanelment we don’t hold, and we would rather say so up front. Departments engage us the way their rules allow: a direct quotation, a limited pilot, or a tender where we submit technical specifications, data-security documents and a permissions matrix. If your tender requires a specific empanelment, ask us early so nobody wastes a bid cycle.
Every block, gram panchayat, village, urban local body and ward in the district is preloaded with LGD codes. The department finalises the questionnaire (or supplies an XLSForm), seats are created for enumerators and supervisors, and each enumerator is assigned villages or wards. The DM or CEO watches block-wise progress live. District setup usually takes 1–2 working days; training takes 45 minutes.
The Local Government Directory (lgdirectory.gov.in) is the Government of India’s official register with a permanent code for every state, district, sub-district or block, gram panchayat, village, urban local body and ward. Codes keep two same-named villages apart, survive spelling changes, and let survey data join other government systems such as scheme portals, census-based data and state dashboards. Bharat Survey attaches the code to every record and adds a code column to reports.
‘Today’s work’: the assigned village or ward, the household or facility list, forms, target and progress; start and end shift; arrival check; sync status (how many records sit on the phone, how many reached the server); and records returned for correction, with the reason. It is Hindi-first, with large buttons, one question per screen, and runs as a native app on Android phones with 2–3 GB RAM. No location is collected outside a shift.
A block officer sees only their block: GP- and village-wise targets, visits, approvals and records pending review; the live map of active shifts (only during shifts); alerts for out-of-area surveys, inactive enumerators, pending sync and offline permits about to expire; and a weekly quality summary. Other blocks' data is never shown — that check runs on every API request. Block officers don’t need a seat unless they fill surveys themselves.
It is built for district- and state-level departmental surveys: household surveys, scheme saturation, facility mapping, GPDP and ward needs assessments, and monitoring visits. National statistical surveys such as the census or NSS run on their own protocols and systems, and we don’t position the product as a replacement. Uttar Pradesh is loaded first; the geography model covers all 36 states and UTs, and any state can be loaded in 1–2 days.
A workable minimum: (1) identity — household ID, village or ward LGD code, house label, landmark, GPS; (2) introduction and consent; (3) head of household and a family roster with each member’s age, sex, education and occupation as a repeat group; (4) housing and amenities — house type, toilet, water, power, cooking fuel; (5) scheme access, scheme by scheme; (6) visit outcome and photos where appropriate. The handbook section above goes through each block in detail.
On servers in India. Permissions depend on role and area — a block officer sees only their block, a supervisor only their team, an enumerator only assigned villages. Every access and change goes into the audit log, and opening a sensitive record requires a written reason. Each department’s or district’s data is isolated at database level (tenant isolation), and support staff work with module-limited permissions.
Yes. Every facility has a permanent ID and GPS pin; forms use checklists (yes/no, rating scales, counts) with photo evidence; reports come out facility-wise and block-wise; and re-inspections land on the same ID so changes show up over time. A submission made far from the facility is flagged ‘out of area’ and kept out of the inspection count.
A 45-minute Hindi session: OTP login and device binding; today’s work and form download; starting a shift and the location notice; the arrival check; introduction, consent and the right to refuse; filling the form, roster and photos; reading validation errors; reading sync status; handling correction requests; ending the shift. Supervisors get a separate session on the review queue, returning corrections and back-checks. Hindi training material and live support on the first field day are included.
In the morning the enumerator opens the app where there is network — block headquarters or the panchayat bhawan — and today’s village, household list and forms download to the phone. The full survey runs offline: arrival check, consent, roster, scheme status, photos, all saved in an encrypted database on the phone. The Offline Work Permit lasts 24 hours. Once a signal returns, records sync with unique IDs so nothing is duplicated, and the screen always shows how many are on the phone and how many reached the server.
These are two different cases. If a mapping is incomplete — say a village’s link to its GP is missing from the LGD file — it appears in the missing-mapping report on day one and is fixed with the district admin. If a tola or majra isn’t on the official list at all, it gets a local operational ID so its homes aren’t skipped, but it is never declared an official village and stays marked separately in reports.
Yes. The app runs on ordinary Android phones with 2–3 GB RAM, so a department doesn’t have to buy devices. One seat covers one named enumerator on one authorised device; the device is bound at OTP login and the server checks seat limits on every activation. When an enumerator or phone changes, the district admin reassigns the seat and the change is written to the audit log. No location is taken from a personal phone outside a shift.
Technically any question can go into a form, but our rule is that sensitive questions appear only with a clear departmental need and written approval — and even then the answer stays optional. Forms with such questions are reviewed before they are published. Sensitive fields are encrypted at rest, access is limited by role, and every access is logged with a reason. The consent text must state the purpose clearly, in line with the DPDP Act 2023.
The urban local body and its wards are preloaded with LGD codes. Enumerators and targets are assigned ward by ward, with mohallas added as an operational layer. A home is identified by household ID, house label, landmark and GPS, because house numbers in urban lanes are often incomplete. Where a ward boundary is approximate, the badge says ‘approximately in area’. Councillors or the executive officer can get a seat-free Viewer role. Setup usually takes 1–2 working days, training 45 minutes.
We load your district’s blocks, panchayats and wards with LGD codes and walk you through the enumerator app, the QA queue and the DM dashboard in 20 minutes.
Open reference pages built from ECI, Census 2011, LGD and MCA records, with the source credited on every page.
