R32Map a broad offering
Pro

Network scale with local action

Establish the coverage of the whole network, then immediately let the visitor act in one local, personal or code-level place.

Back to page recipes

Section sequence

6sections, in the order the visitor meets them. Bar height is the section's weight in the page.

  1. ProveNetwork metric
  2. ProveCoverage map
  3. ActLocal action
  4. DemonstrateLocal result
  5. ProveAvailability detail
  6. ConvertAct where you are

How the page argues

  1. 1

    Open with the network fact: the coverage that only a network can claim.

  2. 2

    Show the coverage map or list, so the claim can be checked locally.

  3. 3

    Immediately narrow to one local action the visitor can take now.

  4. 4

    Show the local result, tied back to the network that produced it.

  5. 5

    State availability honestly, including where the network does not reach.

  6. 6

    Convert on the local action, not on the network claim.

What each section has to be

ProveNetwork metric
The coverage or volume fact, with unit, scope and date, that only a real network can state.
ProveCoverage map
Where the network reaches, at a granularity the visitor can check for their own location or stack.
ActLocal action
One small action in the visitor's own context: their city, their account, their code.
DemonstrateLocal result
The outcome of that action, explicitly connected to the network fact above.
ProveAvailability detail
Regions, latency, limits and gaps, stated plainly including where coverage is absent.
ConvertAct where you are
Conversion scoped to the local action, with the network as the reason it works.

Is this the right sequence?

Who it is for

Buyers who need the network to be large and the first step to be small, in that order.

Products it suits

Networks and coverage-based products where global reach and immediate local usability are both required.

Not for

Products where scale is irrelevant to the decision, so a coverage claim answers nothing.

Evidence strategy

Which proof modes carry the page, in the order they land.

  1. Primary: network scale, which nothing local can substitute for.
  2. Secondary: the local action, which converts an abstract claim into a personal one.
  3. Tertiary: honest availability gaps, which make the coverage claim credible.

CTA plan

What the page asks for, what it offers instead, and where.

Primary
Run the local action for your own location or stack
Secondary
Check coverage, or read the availability detail
Placement
Local action within the first two screens, directly after the coverage map; the network metric never carries a CTA alone.

Responsive behavior

What the sequence has to do when the viewport stops cooperating.

  • The coverage map becomes a searchable region list rather than a pinch-zoom graphic.
  • The local action stays fully usable on touch, with detected location shown and editable.
  • Availability gaps remain visible on mobile; never hide them behind a desktop-only tooltip.

Anti-patterns

The failure modes that make this sequence stop working.

  • A network metric with no local action, which impresses without converting.
  • A local action with no network context, which throws away the differentiator.
  • A coverage map that cannot be checked for a specific place.
  • Silence about gaps, which turns one unavailable region into a credibility problem.

Build spec

Pro

What an agent needs in order to build Network scale with local action: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.

Checking access to the build spec

Agent tags

The vocabulary an agent matches this recipe on.

  • network-metric
  • coverage-map
  • local-action
  • availability-gaps
  • scale-to-local