How do I explain what is included in a product plan or package?

First, collect the proposed details in one place and sort each one into three groups: included for everyone on the plan, not included, or available only if a condition is met. Don’t treat a benefit mentioned in a sales conversation or an old draft as confirmed. Check each item against the current plan information or ask the person responsible for approving plan details.

Then lead with the most useful confirmed information. Clear, concise wording and putting important information first make business writing easier to follow; avoid jargon and organize details so readers can scan them. [S1]

A simple structure is:

1. Included: [confirmed item and quantity or scope]
2. Not included: [relevant exclusion]
3. Available under conditions: [item, condition, and any required next step]

If you can’t confirm a detail, leave it out of the published claim until it is checked.

Name the item, state the condition in the same section, and explain what the reader must do or check next—if that has been confirmed. Don’t place a condition in a footnote while describing the item as though it comes with every plan.

For example, using entirely hypothetical details: “Optional setup session: Available if selected during checkout. Confirm availability before publishing this wording.” The second sentence is an editorial placeholder, not a claim about an actual product. Replace it only after checking the real process.

If the condition, cost, timing, or availability is unknown, flag that exact point for confirmation. Don’t fill the gap with vague language such as “may be available” unless the responsible plan owner confirms that wording is accurate.

Include exclusions that affect a reader’s understanding of the package; keep them in a labeled section close to the inclusions they qualify. Use specific terms rather than a broad catch-all if you can verify the specific boundary. For instance, a placeholder could read: “Not included: [item or service confirmed as excluded].” Don’t use that example to imply that any particular product excludes anything.

For an online purchase flow, label choices so people can tell what they are selecting. W3C’s guidance discusses clear labels or instructions for choices such as checkboxes and radio buttons, and cautions against too few or too many instructions. [S2] That supports clear presentation of choices; it does not establish what a plan contains or what conditions apply.

Keep the page scannable, but don’t remove a meaningful limitation just to shorten the copy.

Use this copyable structure, replacing every bracketed field with verified information:

[Plan or package name] includes

• [Item]: [confirmed amount, scope, or description]
• [Item]: [confirmed amount, scope, or description]

Not included

• [Confirmed exclusion, if relevant]

Available only when

• [Item]: [confirmed condition and what the reader needs to do, if anything]

Before publishing, ask the plan owner to confirm the details and any conditions. Check that the headline and summary don’t imply more than the itemized list promises. If a field is unresolved, keep it out of the public copy or clearly hold it for internal review; don’t publish the placeholder as though it were a product fact. The final page should let a reader distinguish what comes with the plan from what does not and what depends on a condition.