---
title: "Creating a Knowledge Base Article from a Messaging Conversation"
description: "Overview"
canonical_url: "https://help.brainfi.sh/articles/creating-a-knowledge-base-article-from-a-messaging-conversation-bvRyTa22KZ"
md_url: "https://help.brainfi.sh/articles/creating-a-knowledge-base-article-from-a-messaging-conversation-bvRyTa22KZ.md"
---
# Creating a Knowledge Base Article from a Messaging Conversation

## Overview

This article describes how to convert a workplace messaging conversation (Slack, Teams, etc.) into a publication-ready knowledge base (KB) article.

## When to Use

Use this process when a conversation contains a question, decision, troubleshooting steps, or a resolved issue that should be documented for broader reuse.

## Process

### 1) Analyze the conversation structure

* Identify the conversation thread and sequence of messages.
* Find the triggering user query (the message that initiated the discussion).
* Distinguish user questions from assistant replies.
* Note how the discussion progresses toward a conclusion.

### 2) Evaluate AI-generated responses

For any assistant/AI messages:

* Confirm accuracy and completeness.
* Decide whether the content materially contributes to the final solution.
* Exclude incorrect or unhelpful guidance unless it’s useful as a “common mistake” example.

### 3) Classify the document type

Select the most appropriate KB format based on the conversation:

* **Help Article** (problem/solution)
* **Tutorial/How-to** (step-by-step task)
* **Troubleshooting Guide** (diagnosis + fix paths)
* **Decision Document** (options + final decision)
* **Best Practices** (recommended standards)
* **Reference** (specs/definitions)
* **Announcement** (new changes/updates)

### 4) Extract and organize content

Capture only relevant, accurate details:

* Main topic/problem/question
* Final solution/answer/decision
* Steps, commands, configurations, file names, and error messages
* Prerequisites and context
* Warnings, caveats, and tips

### 5) Apply technical writing standards

**Style**

* Use clear, professional language.
* Prefer active voice and imperative mood for instructions.
* Keep terminology consistent.

**Formatting**

* Use numbered lists for procedures.
* Use bullet lists for options or non-sequential items.
* Format technical tokens with inline code (for example, `commands`, `file_names`).
* Use fenced code blocks for multi-line snippets.
* Use a clear heading hierarchy with `##` for major sections.

### 6) Filter excluded content

Remove:

* Personal names (unless they are product/feature names)
* Timestamps and metadata
* Greetings, thanks, and conversational filler
* Off-topic tangents
* Incorrect/failed attempts (unless explicitly helpful)
* Internal-only references
* Emojis and informal expressions

## Recommended Output Structure

Choose a structure that matches the document type:

### Help Article

* Overview
* Problem
* Solution (step-by-step)
* Additional Information

### Tutorial/How-to

* Overview
* Prerequisites
* Instructions
* Verification
* Tips

### Troubleshooting Guide

* Overview
* Symptoms
* Cause
* Resolution
* Prevention

### Decision Document

* Context
* Options Considered
* Decision
* Implementation

### Best Practices / Reference / Announcement

* Overview
* Details
* Impact or Application
* Next Steps

## Output Format

Publish the final KB article as a JSON object:

* `title`: Clear, descriptive, not phrased as a question
* `content`: The full article in Markdown

Example:

```json
{
  "title": "Descriptive Article Title",
  "content": "## Overview\n..."
}
```

## Notes

If the source conversation contains minimal technical detail, document the repeatable process and request missing specifics (error messages, commands, environment details) before publishing a definitive troubleshooting or how-to article.