Skip to content

article

Managing the Knowledge Base and Help Center

Understand how StretchSupport's published products, categories, and articles work, how they power your public help center, and how they support ticket deflection.

Why the knowledge base matters

The fastest support ticket is the one a customer never has to open because they found the answer themselves. StretchSupport's knowledge base is the published help content that makes that possible — and the very same content agents rely on when they reply. It's structured, searchable, and shared between your internal console and your public help center.

How the knowledge base is structured

Your help content is organized in three layers:

  • Products — the top-level hubs, one per app or topic area (StretchSupport itself is one).
  • Categories — groupings within a product, such as Getting Started, Features, Guides, and FAQ.
  • Pages — the individual documents. The most common page type is an article; there are also product-hub and category-hub pages that act as landing pages.

Only content with a published status counts toward your live knowledge base and appears on the help center. Draft or unpublished pages stay out of both the customer-facing site and the agent snapshot.

One source, two audiences

The knowledge base does double duty:

  1. Customers read the published articles on your public help center — the place they land when they search for an answer before contacting you.
  2. Agents use the same published content as their canonical answer source inside StretchSupport, and can link an article to a ticket to record which article resolved it.

Because it's one shared store, you publish an article once and it serves both. The dashboard's knowledge-base snapshot reports how many products, categories, pages, and articles are published, plus how many search terms exist — a quick read on how complete your help center is.

Linking articles to tickets

StretchSupport tracks KB links — connections between a ticket and the knowledge-base article that answers it. When you resolve a ticket using an article, linking it does two things: it gives the customer a durable reference, and it builds a signal about which articles actually deflect tickets. The dashboard shows a KB links count so you can see how often your content is doing real work.

A workflow for growing the knowledge base

  1. Watch the board for repeats. When the same question shows up three times, it's an article waiting to be written.
  2. Draft the article in the right product and category, with clear steps and a realistic example.
  3. Publish it so it appears on the help center and in the agent snapshot.
  4. Link it from the tickets it answers, and reach for it in future replies.
  5. Review the KB links count to see which articles pull their weight, and expand the ones that do.

A realistic example

Over two weeks you notice five tickets all asking how to add teammates once a plan hits its seat limit. You write a Getting Started article, "Adding seats when you hit your plan limit," with numbered steps and a screenshot, and publish it. The dashboard's published articles count ticks up. The next time a similar ticket arrives, you reply with a two-line answer and link the article; the ticket resolves in one exchange, and the KB links count rises. A month later, several of those customers self-serve from the help center and never open a ticket at all.

Tips

  • Write for the searcher, not the expert — use the words customers actually type.
  • Every article should have numbered steps and at least one concrete example; those are what make an answer usable.
  • Link articles from resolved tickets so you can see, via the KB links count, which content deflects real work.
  • Prune and update aggressively — a wrong published article is worse than no article, because it appears on your public help center.

FAQ

Do unpublished articles show anywhere? No. Only published products, categories, and pages count toward the live knowledge base and the customer-facing help center.

What's the difference between a product, category, and page? A product is a top-level hub, a category groups pages within it, and a page (usually an article) is the actual document customers read.

How do I know if my articles are helping? Watch the KB links count on the dashboard — it reflects how many tickets are linked to knowledge-base articles — and watch whether repeat questions decline over time.

Was this helpful?

Help us improve this article

Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.