R29Map a broad offering
Pro

Role-based entry

Put the roles near the top, give each one a tailored scenario, and keep a single shared explanation underneath.

Back to page recipes

Section sequence

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

  1. OrientShared promise
  2. NavigateRole tabs
  3. DemonstrateTailored scenario
  4. ProveShared platform section
  5. ConvertRole-specific action

How the page argues

  1. 1

    Open with a promise general enough to be true for every role, specific enough to matter.

  2. 2

    Put the role selector high, labelled with titles people use for themselves.

  3. 3

    Give each role one concrete scenario with its own artifact.

  4. 4

    Keep a shared platform section, so the product is one thing rather than several.

  5. 5

    Convert per role, into whatever that role would actually do next.

What each section has to be

OrientShared promise
One promise true for every role listed, avoiding a lowest-common-denominator platitude.
NavigateRole tabs
Four to seven roles named as people name themselves, with the highest-volume role as the default.
DemonstrateTailored scenario
One scenario per role: their trigger, their artifact, their outcome. Not a reskinned generic story.
ProveShared platform section
What every role gets: the common data, admin and integration layer that makes it one product.
ConvertRole-specific action
The next step that role would really take — a template, a pilot, a security review, a demo.

Is this the right sequence?

Who it is for

Departmental buyers inside one organization who each need to see their own work reflected before they believe the product fits.

Products it suits

Horizontal products used differently by several functions, where one generic story satisfies nobody.

Not for

A specialist product with one buyer and one job, where role tabs manufacture ambiguity.

Evidence strategy

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

  1. Primary: recognition — the visitor sees their own job described accurately.
  2. Secondary: the per-role artifact, which proves the scenario is real, not a persona exercise.
  3. Tertiary: the shared layer, which turns several role stories into one purchase.

CTA plan

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

Primary
Start with your role's scenario
Secondary
See the shared platform, or switch role
Placement
An action inside each role panel, plus one platform-level action after the shared section.

Responsive behavior

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

  • Role tabs become a scrollable chip row with the active role always visible and deep-linkable.
  • Scenario artifacts crop to their meaningful region rather than scaling to illegibility.
  • The shared platform section keeps its position after the tabs at every breakpoint.

Anti-patterns

The failure modes that make this sequence stop working.

  • Roles that share one generic scenario with the noun swapped.
  • Nine roles, which dilutes every one of them.
  • Role content that only exists behind interaction, leaving crawlers and skimmers with nothing.
  • No shared section, so the page reads as five products under one logo.

Build spec

Pro

What an agent needs in order to build Role-based entry: 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.

  • role-tabs
  • tailored-scenario
  • shared-platform
  • default-role
  • role-cta