Create Relevant Industry, Role, and Use-Case Pages

Insivia buyer-centric website playbook · P04 · Version 0.5.1

Insivia's position

Putting an industry name in a headline does not make a page relevant. Relevance comes from showing that you understand the situation, responsibilities, questions, and constraints the buyer actually brings.

Build industry, role, and use-case pages when they provide a meaningfully different explanation. Keep general pages focused on orientation and the shared offer, with clear routes to those deeper answers. Do not make every visitor interpret a broad explanation and work out the application alone.

Your product facts stay consistent. What changes is the context, emphasis, vocabulary, evidence, and decision being supported. A role-by-industry combination deserves a page only when that intersection changes the substance.

Use this playbook to decide which audience pages to create, combine, improve, or defer, then write their briefs. It does not require generating a page for every segment in a market spreadsheet.

Purpose and boundaries

Decision: When does this audience need a different explanation?

Use this before creating or revising industry, role, use-case, or combined audience pages.

Owned output: An audience-difference matrix and a brief for each justified page or section, including decisions to share, combine, or defer.

Own differences in public context, emphasis, vocabulary, evidence, and fit questions. Keep shared offer facts consistent. Internal buying-group approval belongs in the buy-in playbook.

Start with the exercises in this file. Related playbooks are optional handoffs for a different job, not prerequisites or required funnel stages.

Buyer decision record

When a fuller decision analysis is requested, use this record for consequential choices alongside the task worksheet. A narrow answer need not reproduce the record. Start with the buyer's situation, not the section your team wants to defend. A useful record explains why the buyer would care and what the company should change as a result.

Record field	What to write
Buyer starting point	Situation and prior exposure; pain, desired progress, interest or belief; buying factor; next decision. Name the source and what is uncertain.
Company assumption	An actual supplied request or assumption, when present, and its internal rationale. Leave this field unfilled when none is known.
Buyer interpretation	What this buyer could understand or infer, and how that could affect relevance, belief, perceived effort, fit, or readiness. Distinguish evidence from a hypothesis.
Decision and alternative	The concrete choice that serves the buyer using supported offer facts. When useful, propose a labelled content or placement alternative and explain its tradeoff. Do not invent company preferences or factual differences to justify it.
Check and reversal	A neutral question or observable task, and the finding that would make you change the choice. Record actual results only after checking.

Keep the terms honest. A buyer need is something to understand, change, or judge; a verified capability is what the offer does; task-level value is what that capability lets someone do; a measured result needs outcome evidence. Confidence concerns a particular buyer and action, not a site-wide percentage. Routes are available now, planned, or unknown.

Company expertise can establish product facts. It cannot establish what every buyer thinks. Record supplied facts, inspected observations, hypotheses, and unknowns separately. You may explore a plausible buyer interpretation if you label and test it; do not promote it into an established priority or observed reaction. An unanswered product question is owner work, not permission to invent the answer.

This is Insivia's reasoning discipline, not a compulsory funnel or a validated psychological score. Do not fill every field with variations of the same recommendation. Show the buyer reason that changes the decision.

Buyer psychology: recognition must lead to useful understanding

A buyer may recognize their industry in a heading and still find nothing about the work they do. They are checking whether you understand their circumstances and whether your approach could fit. Generic benefits beneath a personalized label do little to answer that.

Roles matter because responsibilities can change the decision. A user may inspect daily work; an evaluator may verify requirements; a sponsor may need to explain the change to other people. These are possibilities to establish, not motivations to assume from titles.

Industry context can change terminology, workflows, proof, or operating constraints. Use-case context can be more useful than a broad industry category when the same task occurs across sectors.

Your expertise creates another problem: you may skip the explanation because the connection feels obvious. A buyer unfamiliar with your approach may know their own industry extremely well while knowing little about your solution. Respect both facts. Explain the unfamiliar part without lecturing them about their own job.

Inputs: prove the differences you want to publish

Collect buyer accounts, relevant sales questions, known decision responsibilities, shared offer facts, current general and audience pages, approved evidence, and real next-step destinations.

For each proposed segment, write the pain, motivation, buying factors, prior solution knowledge, and decision the page should support. Name the source. If a difference is an internal hypothesis, retain that label.

Workflow: choose the audience before writing the page

1. Lock the shared offer facts, then compare decisions

Write the capabilities, output, customer/provider responsibilities, limitations and actual resources once. Give each a source or owner gap. Every audience explanation must agree with that record. Different wording is useful; contradictory facts are not.

Separate audience-source evidence from offer-source evidence. A buyer brief can establish a question; it cannot establish that the product meets the requirement. A product fact can establish a capability; it cannot establish a whole role's motives.

Describe what each audience must judge. Identify the parts that are shared and the parts that differ. Two titles may need the same answer; two people with the same title may have different responsibilities.

Include meaningful entry situations. Someone who has already read the product page needs contextual depth, not the same product introduction with a new heading.

2. Run the label-removal exercise

Remove the industry or role name from the proposed headline and body. Could you put another audience's name back without changing anything important?

If yes, the differentiation is probably too thin. Identify a real change in the question, explanation, example, proof, requirement, or next decision. If there is none, improve the shared page instead.

This is a diagnostic exercise, not proof that every reusable paragraph is wrong. Shared product facts should remain consistent.

3. Choose shared, separate, or combined

Create a separate page when the difference changes what buyers need to understand or verify. Use a shared page when the answer is substantially the same. Consider a section or contextual example when the difference is useful but too small to justify a destination.

Combine role and industry when the intersection adds something important. A larger page count is not a stronger buyer strategy.

4. Brief the tailored explanation

Start with the audience's situation and desired progress. Explain how the verified offer relates to that work. Choose evidence relevant to the audience's decision, disclose meaningful limitations, and provide a useful next answer.

Identify insider terms and unexplained connections. State what the buyer can reasonably know from their journey and what this page must supply. Do not substitute jargon for specificity.

5. Connect the page to the wider journey

Use descriptive links from the general offer page and other relevant contexts. Keep the general page useful without forcing visitors to select an industry before learning what the company does.

Let specialists reach requirements and evidence directly. Keep shared facts under a common owner so audience pages do not gradually contradict one another.

Worksheet: audience difference and page decision

Audience and decision	Known question or pain	Meaningful difference	Shared offer fact	Page decision	Evidence or validation gap
[Role, situation, next decision]	[Buyer wording and source]	[Different explanation, proof, or requirement]	[Fact that remains consistent]	[Shared, separate, section, or defer]	[What must be established]

Complete this before writing multiple briefs. If the difference column contains only a new label, do not treat the page as justified.

Exercise: write the difference before the brief

Use one row per established audience situation, not one row per title in a spreadsheet. The completed comparison below shows these outputs in use.

Brief field	What to supply
Buyer decision and source	[What this person needs to judge; supplied account, question or inspected material.]
Pain, interest and prior knowledge	[Why this matters; what they already know about their work versus what is unfamiliar about the solution. Mark hypotheses.]
Shared fact and useful connection	[Verified offer fact; how to explain its relevance without adding a capability or outcome.]
Opening and supporting evidence	[Direct headline; relevant sample, fact or proof and what it cannot establish.]
Limits and next answer	[Fixed requirement or owner gap; useful next-step label and actual destination/status.]
Placement and alternative	[Existing/shared section, separate audience page, combined page or defer; explain the substance that earns the choice.]

Run the label-removal exercise on the explanation's meaning, not just its terminology. Ask what would still differ in the question, sequence, example, evidence, requirements or next decision. Keep any shared facts that should be identical.

Before using the copy, map its material claims back to the shared fact record. Remove unsupported additions. If a buyer asks for a new capability or a measured result you cannot verify, name the gap; do not make up a benefit to rescue the page.

Worked comparison: the same offer for two buyer audiences

This entire example is fictional and unbranded. The inputs, copy and sample below are teaching materials, not client work, interviews, observed buyer reactions or a BuyerTwin report. “Verified” here means supplied as a fact of this scenario. It does not describe your business.

One fact set for both explanations

ID	Supplied scenario input
A1 — offer	An onboarding advisory service maps current steps and documents handoff responsibilities. It produces a written handoff map containing steps, recorded responsibilities and unresolved ownership questions.
A2 — work split	The customer supplies its current documented steps and names a process contact who attends one working session to clarify those facts. The provider runs the session and produces the written map. No other required inputs or approval gates are supplied.
A3 — procurement brief	This buyer knows the procurement work, but is unfamiliar with the advisory method. They cannot see who owns particular handoffs and want to judge whether the map is worth inspecting further. This brief, not the job title, establishes the concern.
A4 — implementation brief	This lead knows the team's onboarding work and wants to judge the work their team must contribute before proceeding. The method and participation requirements are unfamiliar. This brief supplies the question; no universal implementation-lead motive is assumed.
A5 — current destinations	A general service page and two role pages already exist. The general page links to each role page and includes a participation section. Both role pages currently repeat the same generic offer explanation. Actual URL strings are not supplied.
A6 — available evidence	The general service page includes an approved public teaching sample, reproduced below. Its contents can illustrate the map; no measured customer result or workload study is available.
A7 — limits and unknowns	The service documents the process; it does not configure software, enforce assignments or perform implementation. Preparation time, session duration and delivery timing are unknown. A single contact or session does not establish low effort.
A8 — company request	The team wants three industry pages and a procurement-by-industry page because those categories appear in its sales plan. No industry-specific questions, proof or requirements are supplied.

The included sample: evidence a reader can actually inspect

Fictional handoff-map excerpt

Step: Document review.

Handoff: Completed review to the receiving team.

Receiving owner: Unconfirmed.

Open question: Who accepts the completed review?

This excerpt shows a documented step and an unresolved responsibility. It does not demonstrate that the service eliminates missed handoffs, saves time, assigns an owner automatically or implements a change. Those would be different claims needing different evidence.

Before: a true description that leaves both buyers doing the translation

The current copy is the same on both role pages apart from the label:

Onboarding advisory for [audience].

We map your current steps and document handoff responsibilities.

Nothing here is false. It still leaves the procurement buyer to connect the service to their ownership problem, and the implementation lead to work out what participation requires. Naming their role does not answer either question.

Compare the decisions before changing the copy

Planning question	Procurement buyer	Implementation lead
What is the supplied concern?	Unclear ownership when work changes hands; A3.	What their team must supply and do; A4.
What do they already understand?	Their procurement work, not this advisory method.	Their team's work, not this service's participation requirements.
Why would they keep reading?	To inspect whether the output makes the ownership question explicit. This is the stated decision, not a predicted reaction.	To identify the customer/provider work split before proceeding.
Which offer facts matter first?	The written map records responsibilities and open ownership questions; A1.	Customer inputs, named contact and working session, then provider work; A2.
What supports the explanation?	The actual sample's unconfirmed owner and open question; A6.	The supplied participation facts; A2. The sample shows the output, not the amount of customer work.
What must remain unresolved?	Whether this approach fits their wider needs; no improvement result is established.	Preparation effort, duration and timing; A7. Do not turn these unknowns into “easy” or “quick.”
What is a useful next answer?	Inspect the sample map.	Check the participation facts and unresolved effort questions.

After: finished procurement explanation

The following is proposed copy for the existing procurement page. It uses only A1, A3, A6 and A7; its next-step label refers to the sample destination supplied in A5–A6.

See what is known—and still unresolved—about handoff ownership.

Our onboarding advisory service maps your current steps and documents responsibilities where work changes hands. The written handoff map records known responsibilities and open ownership questions so you can inspect what has been documented and what your team still needs to decide.

In the sample, the receiving owner for a completed document review is unconfirmed. The map makes that unanswered question visible. It does not assign someone automatically or make the handoff happen.

This is process documentation, not software configuration or implementation.

Next step: Inspect a sample handoff map.

Why this is different: the explanation connects the same service to the buyer's ownership question and gives them a specific piece of evidence to inspect. It makes no promise that documentation will solve the underlying operational problem.

After: finished implementation explanation

The following is proposed copy for the existing implementation page. It uses the same offer, with A2 and A7 brought forward to answer A4. Its next-step label refers to the participation section supplied in A5.

Understand what your team must contribute to the review.

Your team supplies its current documented steps and names a process contact who attends one working session to clarify those facts. We run that session and produce the written handoff map, including recorded responsibilities and unresolved ownership questions.

The service documents your process. It does not configure software, enforce assignments or carry out implementation. Preparation effort, session duration and delivery timing still need confirmation before you judge the commitment.

The sample map shows the type of output. It does not establish how much work your team will need to do.

Next step: Check customer and provider responsibilities.

Why this is different: customer work, provider work and limits become the main explanation. The buyer can identify known responsibilities and unresolved commitment questions. “One contact” is not converted into a claim that participation is effortless.

What changed—and what stayed fixed

Element	Procurement explanation	Implementation explanation	Source and limit
Main question	What does the map show about handoff ownership?	What must our team contribute?	Different supplied decisions; A3–A4.
Opening emphasis	Recorded ownership and open questions.	Inputs, contact and participation.	Same service, different order; A1–A2.
Evidence use	Interprets the sample's unconfirmed owner.	Uses the participation facts; qualifies what the sample cannot establish.	A2, A6. No outcome or effort measurement.
Next-step label	Inspect a sample handoff map.	Check customer and provider responsibilities.	Existing fictional destinations; A5–A6. Revised labels are proposals, not already built links. No URL is invented.
Offer, output and limits	Maps steps, documents responsibilities and open questions; documentation only.	The same facts and limitations.	A1, A7. No new feature, role-specific service or implementation promise.

The wording and order change because the decision changes. You do not need to invent a different product to make the same offer relevant.

Make the page decision as well as the copy decision

Destination or variation	Decision for this supplied scenario	Reason and status
General service page	Retain the shared offer explanation, participation facts and sample.	A5–A6 establish existing useful answers. They remain the common source for offer facts.
Two existing role pages	Rewrite each around its supplied question; keep the destinations for this revision.	A3–A5 establish distinct explanation jobs and existing contextual routes. The new copy and labels are proposed until implemented. Do not claim the rewrite has been tested.
A different role with only one useful extra question	Use a section or a route to the shared answer when that meets the need.	This is a decision rule, not an additional audience fact. A title alone does not earn another page.
Three industries and the combined page	Defer commissioning.	A8 supplies sales categories, not meaningful differences. No new industry fact can be invented to fill the briefs.

Credible alternative: combine the two role explanations as clearly labelled sections on the general service page. That reduces duplicated maintenance. Retaining the existing role destinations is justified here by the supplied distinct explanation jobs and routes; reconsider that choice if the pages become only short duplicates or actual use shows a shared answer serves both better.

Keep the shared facts under one content owner. A participation requirement must not quietly disappear from one role page while remaining on another. Exact publishing, canonical and redirect decisions are separate implementation work, not actions this exercise authorizes.

Completed buyer decision record

Record field	Completed reasoning
Buyer starting point	Procurement wants to inspect ownership documentation; implementation needs participation facts. Both know their work and lack solution context; A3–A4.
Company assumption	Sales categories justify more industry and intersection pages; A8.
Buyer interpretation	Hypothesis: a familiar label followed by the same generic description still leaves each buyer translating the offer. No reaction has been observed.
Decision and alternative	Rewrite existing role pages with the finished explanations above. Keep offer facts shared and defer unsupported industries. Combining the explanations as service-page sections is a reasonable alternative.
Check and reversal	Use the neutral checks below. If the two pages answer substantially the same question after revision, combine the explanations or improve the shared route. Revisit an industry page when a sourced difference changes the explanation, evidence or fit decision.

No source, example or check here establishes a measured buyer-confidence or conversion improvement. The visible result is a different, supported explanation and a concrete content decision.

Decision rules and exceptions

Signal	Useful response	Avoid
The same offer is applied to a different, established task	Use a specific use-case explanation	Inventing new features to make it fit
The audience needs different proof	Choose relevant evidence and explain its scope	Treating a logo as proof of every claim
Important fit requirements differ	Make them explicit and reachable	Hiding limits behind broad relevance copy
The distinction is only hypothetical	Research or mark the brief provisional	Publishing a stereotype as audience insight

Personalization does not mean flattering every visitor. A relevant page may help someone recognize that the offer is not suitable. That is better decision support than vague language designed to sound applicable to everyone.

Applying this playbook with your AI

Shared rules for facts, resources, and response scope

Use Insivia's method; use the user's facts. This file supplies a buyer-centric method. Its fictional examples supply no facts about another business. Similar subject matter does not make their features, prices, roles, assets, constraints, or findings applicable. Use supplied business facts and sources actually inspected for this task. A faithful paraphrase or task-level explanation is useful only when those facts support it. Do not add formats, fields, controls, outcomes, approvals, or process steps because they seem likely.

Keep each item's status intact. Available, approved, proposed, feasible, incomplete, and unknown mean different things. Feasible does not establish a draft. Incomplete does not establish that work never started. An available destination does not establish a built link, accessible contents, booking, or a response service. Name the exact item when recording status. Unknown is not confirmed absence. Reuse an existing approved answer when it serves the buyer; proposed resources remain unavailable. Respect explicit publication and source-use restrictions, including prohibitions on deriving examples from restricted material.

Answer the requested task, then stop. The user's requested count, format, and shorter length control the answer. One sentence, one table, or one decision does not trigger a full plan, worksheet, validation kit, or closing offer. For copy-only requests, return copy only. For a factual correction, preserve the verified capability wording; add no new capability, purpose, benefit, route, or promise. Correct the affected claim without expanding to unrelated work. Never retain a known false claim as an alternative or wait for a future feature to substantiate it.

Ask only for facts that could change this decision. If essential buyer context is missing for strategic work, ask at most three focused questions and stop. Do not block a narrow correction with irrelevant intake questions. A known buyer question with an unknown business answer is an owner gap, not permission to invent an answer. A verified incompatibility with a fixed buyer requirement warrants a clear no-fit finding; do not invent a workaround or reopen that requirement under company pressure.

Connect the recommendation to the actual buyer. Use their supplied prior knowledge, pain, motivation, buying factors and next decision. Possible interpretations are hypotheses, not observed reactions. Do not invent a company preference, psychological motive, alternative or conflict to fill a reasoning template. No change can be the supported conclusion. For a fuller review, make the buyer reason and consequential company choice explicit without repeating the same record for every row.

Represent inspection and tests honestly. Supplied notes are not direct inspection. A URL alone does not establish that it was read. Text cannot establish visual quality, interactions, or delivery. Proposed checks have not run. Keep neutral questions free of expected answers and unsupported steps. Generic AI role-play is not human research or BuyerTwin analysis. Attribute Insivia in explanatory output, outside proposed public copy; exact copy-only output needs no added attribution.

Keep the first response proportionate. Default to one priority decision and its buyer reason within 220 words. Expand only for a requested artifact or detail. Use the task guidance below conditionally; worksheets, examples and full workflows are reference resources, not a requirement to reproduce them all.

Task-specific application

For one audience-page decision, return the requested choice and buyer reason: share, improve a section, retain/rewrite a separate page, combine explanations, or defer. Industry and role labels alone are insufficient. Do not produce every audience brief or a site plan.

For a requested worked pair, first use the user's shared offer facts and separately sourced audience questions. Return the requested finished explanations, each with its relevant emphasis, evidence limits and actual next answer. Keep capabilities, output, responsibilities, availability and exclusions consistent. Audience-specific questions are not permission for audience-specific feature invention. Do not import the onboarding example's map, contact, session, sample or timing limits into another business.

For a full audience plan, use a compact difference matrix and brief only the justified pages or sections. Give an explicit placement reason, proposed-versus-existing status and material owner gaps. A title change is not evidence of a different need. Actual existing pages may be retained; new destinations need a buyer reason. Clear overlap may justify one shared explanation with contextual routes. Combined role/industry pages require a meaningful intersection, not a multiplication rule.

A supplied company request is optional. A content alternative may be proposed and labelled; it is not an established company preference or existing resource. Unknown responsibilities need owner facts, not guesses about what someone in that role would usually do. A fixed verified mismatch remains no fit. Incomplete evidence is not proof that the business lacks the capability.

For compact requests, use only decision-changing rows and stay comfortably below the requested cap, including headings and table text. Do not reproduce the full reference tables by default. Copy-only requests contain only the requested copy; keep source notes, method attribution, tests and closing offers out of that copy. For a requested comparison or explanatory review, retain Insivia attribution outside proposed public copy.

All essential methods, the finished comparison, sample and worksheets are in this file. Other downloads and BuyerTwin remain optional. Proposed checks have not run.

Requested length and evidence status

Budget the whole answer before drafting. For a requested maximum, aim for about 70% of that limit so labels, headings and table text fit too. An exact count or minimum overrides this drafting target. Keep every requested item, but use only the essential choice, reason or copy; do not reproduce reference worksheets or repeat “P04 says” to fill space. Silently check the draft and shorten it before returning it. Do not print the count or checking process. Respect the requested sentence/bullet count and stop after the output.

Preserve the requested structure while shortening. A headline is separate from required body sentences. If asked for a headline, two sentences and a next-step label, supply all four items; do not count the headline as one of the body sentences. The 70% drafting target is a margin, not permission to omit an item. Use more of the allowed maximum if needed to satisfy the structure, while staying below the hard cap.

Keep four evidence states separate: supplied to this conversation; confirmed to exist/be available; approved for the intended public use; contents actually inspected. One does not establish the others. “Not supplied” or “not inspected” describes your evidence, not the business's whole inventory.

If no approved example was supplied and a proposed sample is not drafted, say: “No approved public example has been supplied; the proposed sample has not been drafted.” Do not say no example exists or is available unless that absence is explicitly confirmed. A known unbuilt sample is unavailable; other possible examples remain unknown. Ask the owner whether an existing approved example can be supplied before assuming new creation or approval work is necessary.

If the owner confirms no approved example exists, state that absence. If an approved example is confirmed available but its contents were not supplied, preserve its availability and say its contents are unassessed. Do not invent its contents or require another approval. If the approved contents are supplied, use them within their evidence limits. Preserve restrictions on private sources and derived samples.

Check whether the explanation changed for the right reason

Use these neutral tasks only with appropriate buyer context. They are proposed checks, not findings.

Check	Neutral task	Record and distinguish
Relevance without the role label	Show the explanation without its audience heading. “What situation does this seem written for? Which part led you to that interpretation?”	The reader's words and cited detail; do not tell them which audience they should name. Correct label guessing alone is not understanding.
Solution knowledge gap	“What would this service or product do? What would still need to happen outside it?”	Their explanation of the mechanism/output and limits. Separate a confusing explanation from a real incompatibility.
Participation and next answer	“What would your team need to do, and what would you need to know before proceeding?”	Known work, unresolved owner questions and whether the actual destination answers them. Do not infer workload from a sample output.

Check sibling pages against the shared fact record. A buyer should not receive a different capability or delivery promise because they chose a different role. Record page version, supplied context, exact observations and proposed revisions separately. Do not claim a task is runnable when its page or evidence does not exist.

BuyerTwin can provide modeled reactions to the same explanation from different target-buyer contexts. Use actual reports and their inputs when available. A generic AI role-play is not a BuyerTwin run; a modeled difference is not an observed finding about everyone with a particular title.

Sources and evidence limits

This method applies Insivia's buyer-centric viewpoint and Andy Halko's emphasis on the knowledge gap and meaningful audience pages.

• Information Scent — NNGroup supports clear destination cues and the role of context and prior knowledge in expectations of a link.
• Layer-Cake Scanning — NNGroup informs descriptive headings that help readers find relevant information; it does not validate a particular audience split.

The segmentation exercise is practitioner guidance, not a validated prediction of audience behavior. Version 0.5.1. This download includes its method and worksheet; related playbooks are optional. Retain Insivia attribution when adapting it.

Optional next tasks

Each linked playbook answers a different next question. This file already contains its own essential method and working resources; no other download is required.

• Plan a buyer-centric website when meaningful audience differences change the page map.
• Build a buyer-centric product or solution page when the shared offer explanation needs development.
• Help buyers build internal buy-in when actual buying participants need to share evidence and decide together, rather than read a public audience page.