Skip to content

[Feature Gap] Map & visualization: Demographic territory overlays for planning and segmentation #218

Description

@brycejohnson1417

Feature Gap: Demographic territory overlays for planning and segmentation
Category: Map & visualization
Priority: Medium
Source: Competitive research

What comparable field-sales CRMs do
Comparable field-sales CRMs package demographic data access with territory management so teams can evaluate territories by population, market size, or other planning attributes.

What map-app currently has
Not implemented. map-app shows tenant territory overlays and account metrics, but not demographic or market-planning layers tied to territories.

Why this matters
Demographic overlays help managers rebalance territories and identify whitespace beyond the current customer base.

Suggested approach
Add configurable external territory-data layers with source attribution, map display controls, and territory report rollups.

Labels

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

Full working requirements

  • Territory planning layers support demographic/market attributes by geography such as ZIP, county, state, or custom area.
  • Layer controls include metric, time/version, color scale, opacity, boundaries, and legend.
  • Territory reports roll up demographic metrics with account/activity/revenue metrics.
  • Admin can configure data source, refresh cadence, and which roles can view/export layers.
  • Planning UI highlights whitespace, over/under-covered regions, and data gaps.

Acceptance criteria

  • A manager can toggle a demographic overlay on the territory map.
  • A territory report includes demographic rollups for visible territories.
  • Layer legend and source/freshness are visible.
  • Users without permission cannot view/export demographic data.
  • Missing data areas are shown explicitly.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    competitive-researchBacklog item derived from competitive researchfeature-gapCompetitive parity feature gapmappingMap, routing, territory, and visualization workmedium-priorityMedium priority feature gap

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions