Categories

Support KB Article Generator — One‑Shot Prompt Template

Generate publishable, SEO-friendly knowledge base articles, troubleshooting trees, and escalation-ready responses in one prompt.

What You'll Get

• One-shot prompt template with required input slots (feature/problem, persona, tone, UI terms, screenshots, sections).

• A fully formatted, publish-ready KB article (H1/H2 structure, meta description, TL;DR, steps, screenshots placeholders).

• Policy-safe response macros, escalation triggers, SLA wording, and canonical chatbot/email replies.

• Stepwise troubleshooting tree with checks after key steps and diagnostic questions list for escalations.

• Publish checklist, related internal links suggestions, and CTA wording with exact diagnostic items to collect.

How to Use

• 1Copy the prompt into ChatGPT and set the model to deterministic temperature (low) for consistent outputs.

• 2Provide all required inputs: feature_problem, persona, doc_type, desired_tone, audience_level, ui_terms_list, screenshot_placeholders_list, required_sections_list. If any are missing, answer the prompt's clarifying questions.

• 3Review the generated article for product-specific accuracy and remove any placeholder text; add real screenshots and internal links before publishing.

• 4Run a quick PII/compliance check (remove customer identifiers) and assign a documentation reviewer and support owner before publishing.

Quick consistency tip

Lock the UI terminology list and tone in a shared config file used across all KB prompts so every article uses the same labels and escalation language; this reduces revision cycles and avoids mixed terms (e.g., 'Account settings' vs 'Settings > Account').

Works Best With

When to use this one-shot KB generator

• You have a specific feature or error to document (provide a concise feature_problem).

• You can supply UI terms and screenshot placeholders for accurate in-article labels.

• You want publish-ready KBs for Help Center, chatbots, and email replies with clear escalation data.

• You need both customer-facing copy and support escalation diagnostics in one artifact.

• You can provide desired tone and audience level to tailor wording and technical depth.

Prompt Template

## Goal
- Produce an SEO-friendly, customer-facing Knowledge Base article (ready to publish) for a specific feature or problem so support can reuse it in Help Center, chatbots, and email replies.

## Inputs
- Context: product background or incident notes (if any).
- Stakeholders: support owner, documentation owner, reviewer.
- Constraints: character limits for title/meta, branding/tone, allowed troubleshooting actions.
- Required inputs (prompt will ask if missing): {{feature_problem}}, {{persona}}, {{doc_type}}, {{desired_tone}}, {{audience_level}}, {{ui_terms_list}}, {{screenshot_placeholders_list}}, {{required_sections_list}}.

If any of the above are not supplied, the prompt will ask clarifying questions before generating the article.

## Prompt
Generate one complete, publishable Knowledge Base article per the inputs below. Output must be ready for copy/paste into a help center and include short, scannable sections and SEO elements. Use the exact tone: {{desired_tone}} and write for {{persona}} at skill level {{audience_level}}. Include UI labels and terminology from this list: {{ui_terms_list}}. Insert screenshot placeholders exactly as provided in this list: {{screenshot_placeholders_list}}. Ensure the article contains the required sections in this list: {{required_sections_list}}.

Deliverables (produce each labeled section exactly as specified):
1. Title — SEO-friendly, ≤70 characters, include the primary keyword derived from the topic.
2. Meta description — ≤160 characters, customer-focused, with a call-to-action.
3. Suggested keywords — 5-8 short keyword phrases (comma-separated).
4. TL;DR — one clear sentence for customers summarizing the fix/outcome.
5. Overview — 1-2 short paragraphs explaining the problem/feature and why it matters to {{persona}}.
6. Step-by-step resolution — numbered steps (concise), include checks after each major step and expected results. Use {{ui_terms_list}} where UI names appear.
7. Screenshots/placeholders — for each item in {{screenshot_placeholders_list}} provide:
   - Placeholder label (use the exact placeholder string)
   - Short caption (what the screenshot shows)
   - Suggested alt text (1 short sentence)
   - Step number(s) where to include it
8. Troubleshooting section — 3 common failure symptoms, diagnostic questions to ask, and quick fixes for each (use bullet lists).
9. FAQ — 3 short Q&A pairs addressing common edge cases and policy constraints.
10. Related links / resources — 3 recommended internal links (e.g., settings page, billing FAQ, release notes) and one external authoritative reference if relevant.
11. CTA for contacting support — single-sentence next step with expected SLA and what details to include when contacting support (include the exact diagnostic items to collect).
12. Publish checklist — 5 quick publish checks (tags, category, reviewer, screenshots, slug).

Formatting rules:
- Use H1 for the title, H2 for main sections, H3 for subpoints.
- Keep paragraphs ≤3 sentences. Steps should be numbered; checks as bold short sentences.
- Highlight any **assumptions** you made about missing inputs in a short bullet list under a subheading "Assumptions".
- Under a "Diagnostic questions" block, list the minimum data support must collect before escalating (timestamps, logs, screenshot placeholders, account IDs).
- Output must not state policy or legal claims without a source; if you reference a policy, include a link or cite "internal policy doc" placeholder.

If any required input is missing or ambiguous, stop and list only the clarifying question(s) needed.

## Output Format
Support-style enforced: Diagnosis questions → Response draft → Next steps
- Diagnosis questions: a concise checklist of items to collect from the customer (use the provided screenshot placeholders).
- Response draft: the full Knowledge Base article (Title → Meta → TL;DR → Sections 1-11 as above), fully formatted and ready to publish.
- Next steps: publish checklist and escalation triggers (who to contact, severity thresholds, and required evidence).

Produce the full article in Markdown. Do not include internal commentary or generation notes beyond the "Assumptions" list.

## Guardrails
- Separate facts vs assumptions: include an "Assumptions" list if any input was inferred.
- Do not invent product behavior—if uncertain, flag as assumption and include a recommended verification step.
- Do not make policy or legal claims without citing a source; when citing internal docs, use the phrase "see internal policy: [link]".
- Keep tone strictly within {{desired_tone}} boundaries; do not use humor unless explicitly allowed.

## Examples
- Mini decisions/actions excerpt:
  - Decision: Publish KB article "How to resolve {{feature_problem}}" as canonical.
  - Action: Documentation owner assigns reviewer — Owner: {{persona}} team lead / Due: 3 business days.
  - Risk: Missing screenshot for Step 4 — Action: request screenshot from product team before publish.

Variables

Usage Notes

Not for

• • Authoritative legal, medical, or certified compliance statements that require counsel or auditors.

• • Actions that require live customer credentials or direct access to production systems (do not run with real API keys).

• • Replacing incident response tooling for active security incidents — use your incident response playbook instead.

Do not include

• • Customer PII (names, emails, payment data) or API keys/secret tokens inside prompt inputs or outputs.

• • Unverified claims about product SLAs or uptime without linking to an official internal policy or public status page.

• • Internal-only secrets, access credentials, or proprietary metrics that must remain in internal systems.

Support KB Article Generator — One‑Shot Prompt Template

Convert a feature/problem brief and a small set of inputs into a ready-to-publish KB article, diagnostic checklist, chatbot macros, escalation triggers, and a publish checklist — all policy-safe and review-ready.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

• Auto-fill & personalize from your inputs

• AI-assisted edits: tone, structure, constraints

• Attach context so outputs stay consistent

• Iterate and save versions

What you'll get

Output format

Markdown

Best used when

• When working on template or detailed.

Avoid when

• Authoritative legal, medical, or certified compliance statements that require counsel or auditors.

Sign in to save, like, or rate this prompt.

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

Feature Problem

Provide the key details needed for this variable.

Persona

Provide the key details needed for this variable.

Doc Type

Provide the key details needed for this variable.

Desired Tone

Provide the key details needed for this variable.

Audience Level

Provide the key details needed for this variable.

Ui Terms List

Provide the key details needed for this variable.

Screenshot Placeholders List

Provide the key details needed for this variable.

Required Sections List

Provide the key details needed for this variable.

Rules

• Copy the prompt into ChatGPT and set the model to deterministic temperature (low) for consistent outputs.

• Provide all required inputs: feature_problem, persona, doc_type, desired_tone, audience_level, ui_terms_list, screenshot_placeholders_list, required_sections_list. If any are missing, answer the prompt's clarifying questions.

• Review the generated article for product-specific accuracy and remove any placeholder text; add real screenshots and internal links before publishing.

• Run a quick PII/compliance check (remove customer identifiers) and assign a documentation reviewer and support owner before publishing.

Canonical Examples

Input: Ecommerce checkout shows 'Payment failed' for customers paying by card. Persona: frontline support agent. Doc type: Knowledge Base article. Tone: clear, professional. Audience level: non-technical customers. UI terms: [Checkout, Payment method, Billing page, Order summary]. Screenshot placeholders: [screenshot_checkout_error, screenshot_billing_page]. Required sections: Overview, Step-by-step resolution, Troubleshooting, FAQ, Related links, CTA, Publish checklist.

Loading result...

Failed to load output.

# Fix 'Payment failed' at Checkout

TL;DR: If you see 'Payment failed' on Checkout, verify card details, try a different Payment method, and confirm Billing page settings; contact support with the listed diagnostics if the issue persists.

Why it works: This example demonstrates a customer-facing KB article designed for non-technical agents and customers that is short, scannable, SEO-friendly, and includes explicit diagnostic checklist items agents must collect before escalating. It uses provided UI terms and screenshot placeholders and highlights assumptions about the payment gateway.

Input: SaaS customers report Webhook 'no delivery' for event notifications. Persona: support engineer. Doc type: Knowledge Base article. Tone: technical, concise. Audience level: intermediate (technical customers). UI terms: [Webhooks, Events page, API keys, Delivery logs]. Screenshot placeholders: [screenshot_webhook_settings, screenshot_delivery_log]. Required sections: Overview, Step-by-step resolution, Troubleshooting, FAQ, Related links, CTA, Publish checklist.

Loading result...

Failed to load output.

# Webhooks not delivering events

TL;DR: Verify Webhooks are enabled, API keys are valid, and Delivery logs; collect the webhook ID, timestamps, and screenshot_delivery_log before escalating.

Why it works: This example shows a more technical KB article for support engineers and intermediate customers. It includes exact diagnostic data to collect (timestamps, delivery logs, webhook IDs), uses provided UI terms and screenshot placeholders, and includes clear escalation triggers for engineering.

Works Best With

When to use this one-shot KB generator

• You have a specific feature or error to document (provide a concise feature_problem).

• You can supply UI terms and screenshot placeholders for accurate in-article labels.

• You want publish-ready KBs for Help Center, chatbots, and email replies with clear escalation data.

• You need both customer-facing copy and support escalation diagnostics in one artifact.

• You can provide desired tone and audience level to tailor wording and technical depth.