T2 sales-led
Published entry path
Shown only where the public pricing source supports it.
R2 Bengaluru visitor-gate playbook
Replace paper visitor logs without turning the gate into surveillance
PRAMAAN gives societies a purpose-first visitor QR path with resident or guard approval, expiry, retention labels, and a documented manual fallback beside the existing visitor manager.
R2 BengaluruT2 sales-ledPurpose-first QRTime-limited passManual fallbackNo visitor surveillance claim
Sample preview — no real PII
Time-limited visitor pass
Visitor
M*** A. · Courier
Masked samplePurpose
Parcel delivery · Flat 12B
Shown before consentExpiry
90 minutes
Time-limitedConsent ref
CONS-VIS-26-7xx
LoggedDummy pass. Visitor refusal should route to a manual society process; PRAMAAN should not be coercive.
R2 Bengaluru
Rollout stage
Pilot, waitlist, and target capabilities stay labelled.
Consent
Processing posture
Visitor purpose, expiry, and retention stay visible before processing.
Audience stakes
Visitor gates need fewer exposed paper logs, not mass screening, permanent passes, or coercive collection.
The redesign makes every page explain the buyer's operational world before asking for a conversion.
Paper registers leak too much
Names, phone numbers, flat numbers, and visit times can sit in a binder long after the visit.
Visitor apps need privacy rails
A QR pass should state purpose and expiry before it becomes a reusable gate token.
Refusal needs a human route
The society still needs a documented manual process when a visitor declines or cannot complete a QR path.
Specialized module
Visitor pass and manual fallback
R2 Bengaluru visitor-gate playbook for QR passes with purpose notice, expiry, resident approval, retention labels, and manual fallback.
Bengaluru RWAs piloting visitor QR
Security supervisors and gate teams
Residents approving guests or couriers
Facility managers replacing exposed paper logs
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.
Visitor
Why am I being asked and how long is this kept?
PRAMAAN view: Purpose notice, expiry, support, DSR, and manual fallback context.
Resident
Can I approve the right guest without seeing raw IDs?
PRAMAAN view: Visit purpose, masked visitor reference, pass state, and expiry.
Guard or facility team
What status should I act on at the gate?
PRAMAAN view: Allowed, pending, expired, denied, or manual-review status for the stated visit.
RWA committee
Can we reduce paper-log risk?
PRAMAAN view: Retention-aware log and aggregate operating view without unnecessary raw PII.
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.
- Purpose1
Visitor sees why data is requested
The QR flow starts with destination, requester, visit purpose, and support route before processing.
- Consent2
Visitor continues or uses fallback
Consent, decline, assisted, and manual fallback states are part of the operating model.
- Approve3
Resident or gate role reviews status
The gate sees visit-scoped status and expiry without raw identity documents by default.
- Expire4
Pass and log stay time-bound
The pass expires after the configured visit window and follows society retention terms.
Capabilities
Built around the segment's daily operating model.
Capabilities are useful only when the live/planned/target boundary is visible.
Purpose-first visitor QR
QR copy states the visit purpose, destination, and support route before the visitor continues.
Resident approval status
Residents or guards see a scoped status for the visit rather than a reusable identity profile.
Expiry and retention labels
Pass validity and society retention terms remain visible so old passes are not treated as current.
Manual fallback
Declined, assisted, or failed QR flows route to the society manual process.
Visitor-manager coexistence
PRAMAAN is positioned beside existing visitor managers; named integrations require an agreement.
No raw-ID sprawl
Gate workflows should prefer status and masked references over Aadhaar, PAN, passport, or licence files.
Consent and DPDP
Consent-first visitor-gate flow
Visitors see the purpose and expiry before processing. No consent means no PRAMAAN check, and the society should use its documented manual process.
Purpose and destination shown before processing
Visitor can consent, decline, or use assisted/manual fallback
Gate and resident views avoid raw IDs by default
Retention, DSR, support, and grievance routes remain visible
Sample preview
Time-limited visitor pass
Every preview uses dummy, masked data and is labelled so it cannot be confused with a real report.
Sample preview — no real PII
Time-limited visitor pass
Visitor
M*** A. · Courier
Masked samplePurpose
Parcel delivery · Flat 12B
Shown before consentExpiry
90 minutes
Time-limitedConsent ref
CONS-VIS-26-7xx
LoggedDummy pass. Visitor refusal should route to a manual society process; PRAMAAN should not be coercive.
Use cases
Specific workflows a buyer can recognize.
Courier or delivery visit
Create a purpose-limited pass for a flat or office destination with expiry visible at the gate.
Less paper-log exposure and cleaner visit status.
Resident-invited guest
Let the resident approve the visit while the guest sees purpose, support, and manual fallback context.
Convenience without secret checking.
Service visit handoff
Route recurring workers or service professionals to the worker/service lanes instead of treating every visit as the same visitor record.
The right trust path stays clear.
Responsible use
Visitor privacy guardrails
Visitor data is sensitive and should be retained only for the stated purpose and configured period. The page avoids surveillance, insurance, speed, and cross-society alert promises.
Manual fallback for refusal
No raw IDs at the gate by default
No insurance discount claim
No cross-society barred-list claim
No MyGate/NoBrokerHood integration claim unless contracted
Visitor-gate rollout pricing
T2 sales-led
Visitor QR is scoped through society onboarding so volume, retention, support, guard training, and any coexistence work are confirmed before rollout.
- No public free-visitor claim
- No per-scan price claim without source approval
- No insurance or speed outcome guarantee
Visitor-gate playbook
R2 Bengaluru
Visitor QR messaging starts with the Bengaluru society route. Speed, insurance, integration, and cross-society alert claims are not published without approval.
Integration and operations
Visitor-gate operating model
Keep visitor QR, worker badge, and society visitor-manager coexistence clearly separated.
Visitor QR pass
Supported
Manual fallback
Supported
Worker badge handoff
Supported
Named visitor-manager integration
By agreement
Cross-society alerting
By agreement
Proof and pilot clarity
Visitor-gate rollout clarity
Visitor QR is R2 Bengaluru-first. Society names, visitor counts, gate-speed metrics, insurance outcomes, and named integrations are not published without approval.
FAQ
Visitors verification FAQ
Short, specific answers with consent, visibility, pricing, rollout, and limitation boundaries.
Related journeys
Move to the nearest workflow without losing context.
Replace exposed paper logs with a consent-first gate path
Pilot visitor QR with purpose, expiry, retention, resident approval, and manual fallback in the same operating model.