[Feature Gap] Mobile: Business card scanner for contact and company creation

[brycejohnson1417]

Feature Gap: Business card scanner for contact and company creation
Category: Mobile
Priority: Medium
Source: Competitive research

What comparable field-sales CRMs do
Comparable field-sales CRMs include business card scanning so reps can capture new contacts from the phone and convert them into company/person records with minimal typing.

What map-app currently has
Not implemented. map-app has contact records and import concepts, but no camera/OCR capture workflow for business cards or contact review.

Why this matters
Trade shows, visits, and in-person meetings still produce business cards. Scanning reduces manual entry and helps reps capture new contacts immediately.

Suggested approach
Add a mobile-first scan/review/create flow with OCR provider boundary, duplicate detection, and account/contact linking.

Labels

• feature-gap
• competitive-research
• medium-priority
• mobile

Full working requirements

• Mobile scan flow supports camera/file input, OCR extraction, manual correction, duplicate detection, and create/link decisions.
• Captured fields include name, title, company, email, phone, address, website, and source image metadata where allowed.
• Review screen lets user create contact, create company/account, link to existing account, or discard.
• Scans queue offline if offline mode exists or clearly require connectivity otherwise.
• Original images follow tenant retention/privacy settings.

Acceptance criteria

• A rep can scan/import a card image and review extracted contact fields.
• Duplicate contacts/accounts are suggested before save.
• Corrected fields persist to the created contact/account.
• OCR failure falls back to manual entry without losing context.
• Scan workflow is unavailable with clear explanation if OCR provider/config is missing.

UI completeness contract

• The feature must be fully usable from the running browser UI by the target role; no backend-only, CLI-only, mock-only, or hidden-admin implementation counts.
• Use real tenant-scoped runtime data and persisted configuration. Demo placeholders are allowed only in unauthenticated marketing/docs surfaces, not inside the product workflow.
• Include loading, empty, error, permission-denied, unsaved-change, save-success, and destructive-action confirmation states where relevant.
• Support desktop and mobile layouts for field-rep workflows; manager/admin-heavy tables may be desktop-first but must not break on mobile.
• Respect organization_id scoping, tenant-session authorization, provider-secret boundaries, audit logging, and existing adapter/package patterns.

Validation expectations

• Add deterministic unit/service coverage for business rules, transforms, scoring, permissions, or sync conflict logic introduced by the feature.
• Add integration/API coverage for tenant scoping, unauthorized access, validation errors, and successful persistence.
• Add browser coverage for the primary user flow using real visible controls and persisted state, not implementation internals.
• Run the repo verification baseline plus the targeted checks documented in the PR.

[linear-code]

BRY-99