# Choose where content lives and how readers reach the next step

Complete original constructed exercise. No real people, accounts, studies, enquiries, projects or business results.

Assign each channel a clear job, maintain one intended reference for changing facts and inspect the real handoff to the next destination. Account reach, destination access, opt-in permissions and completed tasks are different conditions; a channel plan must name all of them.

## Start with the journey and constraints

Write the job at each stage: discover a reporting problem, inspect a full explanation, use a worksheet or ask a specific permitted question. A LinkedIn post, maintained blog guide and email to willing subscribers may serve different parts. You do not need every channel. If a destination requires an account, payment or additional information, disclose that before the handoff rather than surprise the reader.

The UK government communications standard recommends choosing channels to fit the objective and constraints. Its mandatory rules apply within its government scope, not to every creator. We adapt the planning question, not its institutional structure. Calling a social account “owned media” does not grant control over platform availability, exports, ranking or access.

## Choose a maintained home for changing facts

Name the reference version for each changing fact, such as a worksheet’s current period definition or a session’s confirmed time. A short native post can describe the task and point to the maintained guide without duplicating every instruction. Some readers need a useful native summary; a bare teaser can fail its discovery job. Decide which context must travel with every copy.

Ownership needs an actual editor, update path and fallback. A blog you cannot access is not maintainable merely because its domain is yours. Record the native post, guide, attachment and optional subscriber message as separate versions with dependencies. Cross-format reuse explains how to adapt their content; this plan decides where they live and how readers legitimately move between them.

## Inspect a three-node route and a correction

Constructed route: N is a public native summary, G a public full guide and W a downloadable worksheet linked from G. G maintains definition D1; N states the essential qualification and links to G; W names G and its own version. Optional email E is excluded from the active plan because permission and list ownership are unverified. That exclusion is not a subscriber count of zero.

If D1 changes, review N/G/W rather than editing G alone and assuming the file changed. If N cannot be edited in the actual account, choose an appropriate permitted correction or replacement with a clear reference; do not promise silent synchronization. Inspect each genuine destination and saved file. A draft map has made no live change.

| Node | Job | Maintained dependency |
| --- | --- | --- |
| N | Native summary | G / D1 |
| G | Complete guide | D1 reference |
| W | Worksheet | G / D1 |
| E | Optional email | excluded: permission unknown |

## Resolve three handoff failures

H-A — Constructed access mismatch: N promises a free worksheet but G requires a paid subscription before W. Decision: align the promise with actual access or provide the genuinely intended route. Outcome: a specified repair, not proof of a real download or purchase.

H-B — Constructed correction drift: G changes D1 while the old W remains downloadable. Decision: version and inspect the replacement, then update references and preserve a relevant correction note. Outcome: named dependent work; a changed page timestamp does not prove file replacement.

H-C — Constructed email shortcut: a commenter asks a public question and the plan adds them to E. Decision: answer through the appropriate permitted route and keep subscription separate. Outcome: no inferred marketing permission or message send.

## Observe each step at its actual level

Keep native impressions, destination visits, file requests, actual task completion and payment verification separate. A server response can prove bytes were delivered in a technical check; it cannot prove a person read the file or solved the task. Different channels may use incompatible denominators and observation windows. Label what was measured before comparing rates.

Use only the attribution and consent actually available. Missing permission is missing data, not a license to stitch identities across channels. A route with no tracking can still be technically tested through destinations and versions. Maintain reader-facing access and explanation first; do not add unnecessary information requests merely to make the funnel easier to count.

## Keep the route usable when something changes

The worksheet records channel role, reader task, actual owner/access, reference fact/version, outgoing destination, promise, permission basis, failure path, correction dependency and evidence level. The packet’s N/G/W fixture verifies a declared route and dependency set, not the availability of any real account or file. No message, external post, subscription or platform change is performed.

Primary planning guidance was read on 1 November 2026 in its declared sections. Our route and cases are original constructions. Use the call-to-action guide for complete form/error/confirmation design and the reuse guide for complete output drafts; those are related tasks rather than more copies of this channel plan.

1. Record the task, scope and actual authority.
2. Inspect inputs and evidence state at the actual source.
3. Work through the full proposal with dependencies and unknowns.
4. Record the decision, owner and next permitted step.
5. Verify actual results separately from plans and constructed examples.

## Primary sources

- [GovS011: Scope and sections5.2–5.5 on objectives, channels and constraints](https://www.gov.uk/government/publications/government-functional-standard-govs-011-communication/government-functional-standard-govs-011-communications)