Release Communications

The IndexMind workflow for changelog entries, monthly release digests, LinkedIn posts, customer email, and headliner selection.

Every release communication starts from the product record, then gets adapted for the channel. The changelog is the durable source. Social posts, customer email, docs links, and internal QA tickets all point back to that source.

Source record

Create or update a changelog entry for every customer-facing release. Each entry needs:

  • Release date in YYYY-MM-DD format.
  • Product area and plain-language title.
  • One-sentence summary with the user outcome.
  • Two to three detail paragraphs that explain what changed and who should care.
  • Audience tags: Executive, Developer, Content, or Agency.
  • A citation sentence that can stand on its own in an AI answer.
  • One docs link for deeper implementation context.
  • FAQ content when the release changes how customers evaluate or buy IndexMind.

Use the public changelog URL as the canonical link for external release references.

Monthly digest

Send one digest per month when at least two material releases shipped. The digest should read like an operating update, with the strongest customer outcome first.

Recommended format:

  1. Lead with the month’s strongest outcome in one sentence.
  2. List three to five releases with date, title, and business impact.
  3. Link each item to the public changelog anchor.
  4. End with one recommended next step for active customers.

Example structure:

Subject: IndexMind product updates for April 2026

This month, IndexMind moved further from reporting into governed execution.

- Agent OS Phase 1, Bob now supports autonomy levels, schedules, guardrails, and approvals.
- MCP server, developers can inspect IndexMind recommendations from compatible IDEs.
- Custom dashboard views, executives, developers, and content teams can use one project record with role-specific framing.

Start here: /changelog#2026-04-18-agent-os-phase-1

LinkedIn format

Use LinkedIn for the headline release only. Keep the post grounded in what shipped and why the release changes the customer workflow.

Recommended format:

  1. Name the release in the opening line.
  2. State the workflow change in one sentence.
  3. List three specifics.
  4. Link the changelog entry.

Example:

IndexMind shipped Agent OS Phase 1.

Bob can now move from analysis into governed execution with autonomy levels, risk profiles, schedules, and approval workflows.

What changed:

- Teams decide which fixes Bob may propose.
- Risk profiles keep sensitive actions under review.
- Approved work can route into the delivery workflow.

Full release record: /changelog#2026-04-18-agent-os-phase-1

Customer email format

Use customer email for releases that change how active customers should work. Keep the message direct and action-oriented.

Recommended format:

  1. Subject line names the customer outcome.
  2. Opening line says what shipped.
  3. Body explains the new workflow and the exact next step.
  4. Footer links to docs and the changelog.

Example:

Subject: Bob can now route approved AI visibility work

We shipped Agent OS Phase 1 for IndexMind.

You can configure Bob with autonomy levels, risk profiles, schedules, and approval workflows. Start by choosing which actions Bob may propose, then route approved work into your delivery process.

Docs: /docs/bob/configuration
Release record: /changelog#2026-04-18-agent-os-phase-1

Headliner criteria

A release becomes the monthly headliner when it meets at least two of these criteria:

  • It changes the core workflow from finding to fixing.
  • It affects more than one audience view.
  • It introduces a durable source record, integration, or approval path.
  • It has a clear docs page and support path.
  • It creates a new reason for a customer to run or revisit a project.

If two releases qualify, choose the one closest to the product’s main promise: IndexMind turns AI visibility analysis into shipped fixes.

QA handoff

Each release communication QA ticket should include:

  • The exact route or surface to validate.
  • The audience view or logged-in state required.
  • The expected copy source.
  • Structured data requirements when the page is public.
  • Screenshot evidence from the approved browser validation path.

Do not close the QA ticket until the changelog anchor, docs link, and screenshot evidence are attached.