A member names who they need in their 60-second slot. Three people nod. By Tuesday nobody remembers the company name, and there is no record that the ask was ever made.
A member needs help with a GST notice. The chapter files that under "Tax Advisor". Unless they already know the label, they scroll a list of 36 categories, give up, and ask outside the chapter.
A member posts precisely who they want to reach. Every member sees it. Anyone can offer the connection. A 7-day clock keeps it honest, then it archives — still searchable forever.
A member describes the problem in their own words. The platform resolves it to the chapter's business categories and ranks the members who fit, with call and email one tap away.
| Capability | Asks | Directory |
|---|---|---|
| Plain-English search | Keyword | Natural language |
| Visible to visitors | Yes, read-only | No — members only |
| Works offline | Yes | Online only |
| Permanent record | Archive, searchable | Live roster |
| Capability | Status | Note |
|---|---|---|
| Email OTP sign-in | Live | No passwords anywhere in the product |
| Passkeys — Face ID / fingerprint | Live | Second visit onward is one tap |
| Offline feed and claims | Live | Queues actions, syncs on reconnect |
| Multi-chapter routing | Live | Slug-per-chapter, one deployment |
| DPDP / GDPR data rights | Live | Member self-service |
| Plain-English directory search | New | The subject of slides 10 to 12 |
Roster and configuration figures are from the live pilot. Ask and referral volumes are deliberately not shown here — we will present those from live data at the review, rather than estimate them.
Six-digit code, valid 10 minutes. Rate limited per address.
A passkey is registered to the member's device on first sign-in. From then on, entry is biometric — no code, no email round trip.
They are shortlisting a gifting vendor for Diwali. Warm intro to Rajesh would help.
Annual facility deep-clean contract goes out for quotes this month.
Category suggestions are drawn from what the chapter already uses, so the taxonomy stays consistent instead of fragmenting into near-duplicates.
| Rule | Behaviour | Why |
|---|---|---|
| Multiple claims allowed | Any number of members can offer | The asker picks the best route, not the fastest tapper |
| Timer starts on first claim | 7 days, configurable per chapter | Creates urgency without punishing a slow week |
| Later claims do not extend | Clock is fixed at first claim | Stops an ask living indefinitely on trickle interest |
| Unclaimed asks expire | Auto-archived at 60 days | Safety net for members who leave the chapter |
| Asker can close early | Any time, one tap | The ask is satisfied — no reason to keep it open |
| Coordinator can close any | Chapter admin override | Housekeeping without escalating to support |
| Target | Company | Category | Asked by | Outcome |
|---|---|---|---|---|
| Rajesh Iyer | Marina Hotels Group | Corporate Gifting | Meera Raghavan | Connected |
| Sunil Bhaskar | Harbour View Hotels | Home Furnishing | Arun Chandrasekhar | Connected |
| Priya Nambiar | Coastal Hospitality | Deep Cleaning | Vivek Balakrishnan | Expired |
| Ganesh Warrier | Marina Hotels Group | CCTV | Nikhil Raghunath | Connected |
Any category the model returns that the chapter does not actually use is discarded before it can affect results.
If the model is slow or unreachable, the directory falls back to keyword search. The page always loads.
Generic trade names. Deduplicated, so the count of members behind a category is not exposed either.
| Control | How it is guaranteed |
|---|---|
| Single egress point | One class in the codebase is permitted to call the model. Nothing else can. |
| Automated privacy test | A test inspects the outgoing request and fails the build if any member name, email, phone or company appears in it. |
| No training on BNI data | Inference-only API. Category labels carry no personal data even if retained. |
| Feature is switchable | Remove one key and the directory reverts to keyword search. No redeployment. |
| Role | View asks | Post ask | Offer connect | Directory | Chapter tools | Create chapters |
|---|---|---|---|---|---|---|
| Visitor | ✓ | — | ✓ | — | — | — |
| Member | ✓ | ✓ | ✓ | ✓ | — | — |
| Coordinator | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| Regional admin | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
A visitor can see open asks and offer a connection — that is how a good visitor earns their seat. They cannot post asks, and they cannot open the directory, because it carries every member's phone and email.
The same individual can be a coordinator in one chapter and a visitor in another. Roles attach to the membership, not to the person, so cross-chapter visiting needs no second account.
| Chapter | URL | Members | Status |
|---|---|---|---|
| Miracles | /miracles-asks | 37 | Live |
| Skyline | /skyline-asks | 41 | Live |
| Harbour | /harbour-asks | 28 | Onboarding |
| Summit | /summit-asks | — | Invited |
Each chapter gets its own URL and branding. Members see "BNI Skyline Asks", not a generic tool.
Asks, rosters and directories are isolated per chapter. No chapter sees another's members.
Claim window and archive rules are configurable per chapter without a separate build.
| Name | Category | Company | Role | Status |
|---|---|---|---|---|
| Anjali Sreedharan | Accounting Services | Ledgerline Advisors | Coordinator | Active |
| Nikhil Raghunath | Electrical Contractor | Voltcraft Electricals | Member | Active |
| Priya Suresh | Psychologist | Mindwell Clinic | Member | Active |
| Fathima Rasheed | Travel | Yathra Holidays | Member | Not verified |
Figures above illustrate the report format. Actual pilot numbers will be presented from live data rather than estimated in a deck.
Added to the home screen. No app store, no review cycle, no separate builds.
Claims made on weak venue wifi are queued and sent the moment signal returns.
The asker is told the moment someone offers to make the connection.
Applies to every Indian chapter. BNI is the Data Fiduciary, Vischari the Data Processor, members are Data Principals.
Engages only where a chapter holds data of members or ask targets in the EU or EEA. Designing to the stricter of the two costs nothing extra.
| Obligation | DPDP | GDPR | In the product | Status |
|---|---|---|---|---|
| Notice at collection | S.5 | Art 13 | Versioned privacy notice, acknowledgement recorded per member | Live |
| Access / summary of data | S.11 | Art 15 | Member downloads a full copy of their own data, unassisted | Live |
| Correction | S.12 | Art 16 | Member edits their own profile; coordinator edits are logged | Live |
| Erasure | S.12 | Art 17 | Self-service account erasure; ask history anonymised, not orphaned | Live |
| Portability | — | Art 20 | Export in open, machine-readable format | Live |
| Accountability | S.8(1) | Art 5(2) | Audit log of who changed which member record, and when | Live |
| Data minimisation | S.6(1) | Art 5(1)(c) | Only query and generic category labels reach the AI; enforced by test | Live |
| Storage limitation | S.8(7) | Art 5(1)(e) | Sign-in codes, dead devices, stale credentials purge on schedule | Live |
| Security safeguards | S.8(5) | Art 32 | Passwordless auth, passkeys, encrypted transport, scoped access | Live |
| Third-party redaction | S.8(3) | Art 17 | Coordinator redacts an ask target's details on request | Live |
| Nomination | S.14 | — | Member nominates someone to exercise rights on death or incapacity | To build |
| Breach notification | S.8(6) | Art 33/34 | Runbook and notification templates; needs BNI's reporting chain | To agree |
Two items are honestly marked open. Nomination is DPDP-specific and has no GDPR equivalent, so it was not in the pilot scope. Breach notification needs BNI's internal reporting chain before the runbook can be finalised. Both are small and sit in Phase 01.
Decides purpose and means. Publishes the grievance officer contact. Answers to the Data Protection Board.
Operates the platform under written instruction only. No independent use of member data. No sub-processor without approval.
Exercises access, correction, erasure and grievance rights from inside the app, without going through a coordinator.
| Point | Position |
|---|---|
| Lawful basis | Member consent at profile setup, plus legitimate use for chapter administration. Consent notice is itemised and versioned. |
| Withdrawal | As easy as giving it — self-service erasure in the app, no email request, no coordinator gatekeeping. |
| Ask targets (third parties) | An ask names someone who is not a member. Notes are minimised to business context, and a coordinator can redact on request. This is the sharpest privacy edge in the product and is treated as such. |
| Children's data | Out of scope. Members are adult business owners; the platform collects no data on under-18s, so DPDP S.9 parental-consent duties are not engaged. |
| Cross-border transfer | Member data is hosted in BNI's chosen region. The AI call is the only outbound flow, and it carries no personal data — so DPDP S.16 restricted-territory exposure does not arise on that path. |
| Significant Data Fiduciary | Unlikely at chapter or regional volume. Must be reassessed before national rollout, since SDF status adds a DPO in India, independent audit and DPIA duties. |
| Retention | Active while the membership is active. Credentials and sign-in artefacts purge on schedule. Ask archive is retained as chapter record, anonymised on member erasure. |
By signing below, the undersigned confirm that the workflow described in this walkthrough is a true representation of the process to be supported, and that the proposed roles, permissions, data boundary, dashboards and rollout sequence are acceptable as the basis for a regional licence.