T2 sales-led
Published entry path
Shown only where the public pricing source supports it.
R2 Bengaluru society onboarding
Replace paper gate logs without becoming surveillance
PRAMAAN helps RWAs and gated communities review worker, staff, and vendor status with purpose notice, worker consent, role-based views, retention labels, and manual fallback beside your existing visitor manager.
R2 BengaluruT2 sales-ledWorker consent at gateNo raw IDs in chatsManual fallbackWorks beside visitor managers
Sample preview — no real PII
Gate, staff, and vendor dashboard
Gate scans
124 today
Aggregate sampleStaff roster
84 active
6 renewal remindersVendor onboarding
19 pending
Consent queueManual fallback
3 open
Committee reviewDummy society data. PRAMAAN is a verification layer beside visitor operations, not a surveillance system or claimed MyGate/NoBrokerHood integration.
R2 Bengaluru
Rollout stage
Pilot, waitlist, and target capabilities stay labelled.
Consent
Processing posture
Society scope, volume, support, and retention terms are confirmed before rollout.
Audience stakes
Society verification should reduce paper-register and WhatsApp-ID privacy risk without turning the gate into a surveillance layer.
The redesign makes every page explain the buyer's operational world before asking for a conversion.
Paper and chat logs spread PII
Gate books, photocopies, and WhatsApp groups make identity data hard to control, correct, or delete.
Every resident sees a different worker story
Residents, committee members, security guards, vendors, and workers need different views and responsibilities.
Visitor apps do not solve worker portability
A visitor manager can handle guests while PRAMAAN adds consented worker badge and status views where deployed.
Specialized module
Society gate and staff workflow
R2 Bengaluru society playbook for staff, vendor, visitor-adjacent, and worker badge verification without paper-register sprawl.
Bengaluru RWAs
Gated communities with staff/vendor entry
Society committees replacing paper registers
Security desks that need manual fallback
Who this is for
Role-based trust, not one generic buyer.
Each stakeholder gets the decision surface they need while the person being verified keeps consent and rights visible.
Residents
Responsible home-staff confidence without viewing everyone in the society
PRAMAAN view: Own invited workers and permitted status only.
RWA / committee
Policy, retention, dispute handling, and rollout communication
PRAMAAN view: Aggregate dashboard, consent trail, retention labels, and export where enabled.
Security desk
Fast operational status at the gate
PRAMAAN view: QR status, expiry, manual fallback, and escalation path.
Workers and vendors
Consent, dignity, portability, correction, and deletion
PRAMAAN view: Badge, consent history, support, correction, DSR, and grievance routes.
Workflow
Request, consent, signal, review, and audit stay connected.
The person being verified sees the purpose before checks run; the operator receives a decision-support signal and escalation path.
- Policy1
Committee agrees the purpose
Define staff, vendor, visitor-adjacent, and worker-badge uses before any rollout notice goes live.
- Notice2
Workers see what the society needs
The worker receives the purpose, scope, support route, and consent context before a status is used.
- Scan3
Gate sees permitted status
The security desk scans a badge or assisted flow and sees role-scoped status, expiry, and escalation only.
- Review4
Committee audits without raw-ID sprawl
Retention, DSR, grievance, and exception handling remain visible to the right admin roles.
Capabilities
Built around the segment's daily operating model.
Capabilities are useful only when the live/planned/target boundary is visible.
Worker badge roster
Maintain a staff and vendor roster around badge status, expiry, consent reference, and manual review labels.
Gate QR status
Security guards see current permitted status and escalation cues, not raw identity documents by default.
Role-based resident views
Residents see their own invited workers or permitted status, while committee and guards operate through separate views.
Manual fallback
If a worker declines or cannot complete a phone flow, the society follows a documented manual process instead of secret checks.
Retention and rights
Retention, correction, deletion, grievance, and DSR routes stay part of the society operating model.
Visitor-manager coexistence
PRAMAAN is positioned beside MyGate, NoBrokerHood, or other visitor managers; no integration is claimed unless contracted.
Consent and DPDP
Consent-first society gate model
The society model is purpose notice, worker consent, permitted gate status, role-based views, retention limits, and visible DSR/grievance routes.
Purpose shown before society use
Worker can decline and use a manual fallback
Gate view avoids raw Aadhaar/PAN/passport/police details by default
Support, correction, deletion, DSR, and grievance routes stay visible
Sample preview
Gate, staff, and vendor dashboard
Every preview uses dummy, masked data and is labelled so it cannot be confused with a real report.
Sample preview — no real PII
Gate, staff, and vendor dashboard
Gate scans
124 today
Aggregate sampleStaff roster
84 active
6 renewal remindersVendor onboarding
19 pending
Consent queueManual fallback
3 open
Committee reviewDummy society data. PRAMAAN is a verification layer beside visitor operations, not a surveillance system or claimed MyGate/NoBrokerHood integration.
Use cases
Specific workflows a buyer can recognize.
Recurring domestic staff
Residents invite maids, cooks, drivers, nannies, caregivers, and tutors into a consented status workflow.
Resident confidence without society-wide worker exposure.
Vendor and maintenance entry
Plumbers, electricians, delivery-adjacent vendors, and maintenance teams can show status at the gate.
Less paper handling and clearer exception review.
Committee audit and disputes
Committee owners review aggregate status, expiry, consent references, and manual exceptions.
Cleaner governance without raw-ID chat trails.
Responsible use
Society privacy guardrails
Avoid unilateral data collection, raw document forwarding, invented society proof, and WhatsApp groups full of IDs.
No surveillance framing
No raw document forwarding
No invented society names, counts, or pilot outcomes
No MyGate/NoBrokerHood partnership or integration claim unless contracted
Manual fallback required when a worker declines or cannot complete phone flow
Society onboarding
T2 sales-led
Society pricing is scoped before rollout: household count, staff/vendor volume, support expectations, retention terms, and any integration work are confirmed with the RWA or committee.
- No public fixed monthly promise on the society page
- Batch worker sponsorship can be scoped
- Support and retention terms should be written before launch
Society onboarding
R2 Bengaluru
Society rollout is positioned as R2 Bengaluru-first. Names, counts, committees, integrations, and outcomes are published only after explicit society/RWA approval.
Integration and operations
Society operating model
PRAMAAN should coexist with visitor-management tools unless a specific integration is contracted and implemented.
Worker badge scan
Supported
Society admin dashboard
Supported
Visitor-manager coexistence
Supported
Named integration
By agreement
Self-serve pan-India rollout
Planned
Proof and pilot clarity
Society rollout clarity
The society lane is R2 Bengaluru-first. Public copy avoids invented society names, fake committee approvals, unsupported visitor-manager partnerships, and live rollout counts until explicit approval exists.
FAQ
Societies verification FAQ
Short, specific answers with consent, visibility, pricing, rollout, and limitation boundaries.
Related journeys
Move to the nearest workflow without losing context.
Modernise society verification without surveillance
Replace fragile paper and chat workflows with consent-first, role-scoped status views.