How our CX Team Uses Storytell to Write Changelogs

As part of our “How We Use Storytell to Build Storytell” series, our Customer Experience (CX) team shares how they use Storytell to turn engineering updates into clear, user-facing changelogs. This helps ensure every feature we ship is communicated consistently, so teams across Storytell and our users always know what changed and why it matters.

Each changelog we write starts with a Collection. From there, we use the Chrome Extension to pull in the latest commits and tickets, then run a structured SmartChat™ prompt that generates the full entry. The result includes a summary, context, technical details, and a plain-English explanation.

In this blog, we’ll walk through how the CX team uses Storytell to write high-quality changelogs, why structure matters, and how you can replicate this workflow for your own product updates.

Why changelogs need more than a list of fixes

Engineering teams move fast. By the time a feature is deployed, the changelog can be an afterthought or worse, only a partial view of what changed.

Our CX team writes changelogs so that everyone—support, sales, product, and users—can quickly understand what was released, who it was built for, and why it matters. But writing them manually is time-consuming. It often means bouncing between GitHub, Linear, Slack, and Notion just to piece together the full story.

We needed a workflow that was:

• Consistent and repeatable
  
• Grounded in real ticket and commit data
  
• Easy to adapt across different types of updates
  

So we built it inside Storytell.

From release notes to ready-to-publish

Here’s the workflow our CX team follows:

1. Start with the release

We begin by reviewing the latest GitHub release page to see what shipped.

2. Build a Collection

Using the Chrome Extension, we gather all relevant Linear tickets, commits, and internal references into a single Collection.

3. Pull in the details

With the Chrome Extension, we quickly ingest full ticket content, commit messages, and discussion links—so SmartChat™ has everything it needs.

4. Run the changelog prompt

Inside the Collection, we run a structured SmartChat™ prompt that generates a full changelog draft. It includes:

• A summary headline and key bullets
  

• The intended user or use case
  

• The problem the feature solves
  

• A breakdown of what shipped
  

• A simple explanation for non-technical readers
  

• A technical deep dive

Want to try it on your workflow? Here’s the exact prompt our CX team use: 

I need to write a changelog entry about a feature/s we just built and shipped. Here is some context to help you prepare your answer:

1. Linear ticket from our engineering team that details the changes they made, which are already provided to you

I want you to use this as the content for your answer.

In your answer you should give me the following sections, always in this order:

1. Feature Shipped/Bug Fixed: With the heading "Feature Shipped" or "Bug Fixed", generate a title for the feature. And summarize this feature update into a concise changelog entry that is clear, scannable, and user-friendly. It should start with a short, attention-grabbing headline and briefly explain what changed and why it matters. List key updates in bullets. Keep it 3–6 sentences max for readability. I want you to refer to the feature name in this section.

2. Who We Built This For: If you can identify specific users or use cases we were building this feature for, add a section called "Who we built this for" and name the user(s) we are building this for and what use cases we're solving for them by shipping this feature.

3. The Problem We Solved: Create a section called "The problem we solved with this feature" and describe why we built this. What problem were we solving? Why does it matter?

4. Specific Items Shipped: Create a sub section Specific items shipped: List in bullet point format each detail we built. For each bullet point, provide a bold summary and then a few sentences of detail describing that bullet point.

5. Explained Simply: Explain this feature like you're talking to a smart 15-year-old who isn't technical. Use simple but precise language, real-world analogies, and make it relatable to everyday situations. Avoid jargon, but don't dumb it down and respect their intelligence.

6. Technical Details: Create a sub section in this summary called "Technical details" and delve into a deep technical analysis of what we just shipped so an engineer can really understand how it works.

Guidelines to follow:

1. If referring to collection/s as a noun, capitalize the first letter like "Collections"

2. Do not refer to it as "our system", "the AI platform", or anything similar. It should be called "Storytell"

3. If relating to threads, rename thread/threads into SmartChat™ or SmartChats™

4. Separate groups into "New Features" and "Bug Fixes"

5. IGNORE ANY TICKETS OR CHANGES/UPDATES THAT START WITH "DOC-XXX"

After giving me your answer, re-print it in Markdown mode for me to copy & paste. Avoid using exclamation marks and emojis. Here is the Markdown format you will use: 

## Summary 

## Who We Built This For 

## The Problem We Solved With This Feature: 

## Specific Items Shipped: 

## Explained Simply: 

## Technical Details:
  

Why structure matters when writing changelogs

The structure built into our prompt isn’t just a formatting choice—it’s a reflection of how different teams consume changelogs. Here’s why each part matters:

• The summary helps teams scan quickly. Most readers want a quick overview. Starting with a feature title and bullet list gives them what they need in seconds.
  
• “Who we built this for” connects updates to users. This section helps Sales, Support, and Product understand the “why” behind a feature.
  
• Explaining the problem grounds the update. Features are easier to appreciate when you know what they’re solving.
  
• The simplified explanation makes it accessible. Not everyone reading the changelog is technical. This section builds shared understanding across teams.
  
• Technical details serve the builders. Engineers and PMs often want to know what changed under the hood. Having that information ready saves back-and-forth.
  

By separating out these parts, we make changelogs easier to write, easier to read, and more useful across the board.

What it looks like in practice

Below is a real changelog we wrote using this exact process, with SmartChat™ pulling directly from a GitHub release and Linear tickets.

This changelog was drafted in a few minutes. It was reviewed, lightly edited, and then published with full confidence that the information was accurate, complete, and useful.

A workflow worth reusing

This isn’t just about moving faster. Writing changelogs in Storytell has made our product communication more reliable, especially across teams that don’t always have full context.

It also gives us a repeatable way to keep changelogs from becoming a last-minute scramble. With SmartChat™ and Collections, we’re turning documentation into a natural step in the product workflow—not a burden at the end.