Running HelpDocs with HelpDocs: Our Self-Service Setup

There's something weirdly meta about writing a blog post about our knowledge base software on our knowledge base software's blog 🤯

But here's the thing—if we're asking you to trust HelpDocs with your customer support and internal documentation, we better be using it ourselves, right? And not just using it, but actually relying on it for the stuff that matters.

So today I'm pulling back the curtain on how we actually use our own product. Because honestly, being your own customer teaches you things you'd never learn otherwise.

Our Internal Brain Dump Lives Here

Like most growing companies, we have that classic problem: information scattered everywhere.

Slack threads that disappear into the void, important decisions buried in email chains, and that one person who knows how to do the thing but forgot to write it down.

Our internal HelpDocs instance has become our single source of truth for pretty much everything. And I mean everything. We've got articles on:

• How to handle difficult customer situations (with actual examples from real tickets)
• Our brand voice guidelines (because consistency matters)
• Code deployment processes (because breaking things is expensive)
• Meeting agenda templates (yes, we documented how to run meetings)

The weird part? We reference our own docs in Slack and customer support tickets constantly. Someone will ask "How do we handle refund requests again?" and instead of typing out the whole process, we just drop a link to the relevant article.

It's made us realize how crucial good knowledge base organization really is. When you're searching for something at 4 PM on a Friday, you need it to be findable fast.

Customer Support That Actually Scales

Here's where things get interesting. We use HelpDocs for our customer-facing support, obviously, but we've also integrated it into our support workflow in ways that have genuinely surprised us.

When a customer emails us with a question, our first stop is our knowledge base.

Nine times out of ten, we've already answered that exact question, and we can send them a link to a detailed, tested answer instead of typing something out on the fly.

But here's the kicker—we've started using our own search analytics to predict what customers need before they ask. If we see a spike in searches for "API rate limits," we know to proactively update that article or maybe create a FAQ section.

We've also connected our knowledge base to our customer support tools, which means when someone writes in about password resets, we can instantly surface the relevant articles. It's like having AI-powered support but actually reliable.

The Analytics That Actually Matter

Being our own customer means we obsess over the metrics that actually indicate whether our knowledge base is working. And spoiler alert: it's not just about page views.

We track:

• Search success rate: Are people finding what they're looking for, or are they bouncing after searching?
• Article feedback scores: We ask "Was this helpful?" on every article and actually look at our score.
• Time to resolution: How quickly can someone (customer or team member) solve their problem using our docs as the basis for it?
• Internal adoption: Are our own team members actually using the knowledge base, or are they still asking questions in Slack?

The most eye-opening metric has been tracking which articles our team references most in support conversations. Those high-traffic articles get extra love—better formatting, more screenshots, clearer language.

We've learned that good documentation isn't just about having the information. It's about presenting it in a way that makes sense when someone is stressed, frustrated, or in a hurry.

What We've Learned From Being Our Own Customer

Using your own product daily teaches you things you'd never discover otherwise. Here are the biggest lessons:

• Search is everything. If your search function sucks, your knowledge base sucks. We've spent tons of time making sure our search understands typos, synonyms, and the weird ways people actually phrase questions.
• Mobile matters more than you think. We constantly find ourselves pulling up articles on our phones during meetings or while traveling. If it's not readable on mobile, it might as well not exist.
• Consistency beats perfection. We'd rather have 50 articles that follow the same format than 10 perfect articles and 40 random ones. Predictable structure helps people scan and find information faster.
• Internal feedback loops are gold. When someone on our team says "I couldn't find the thing about X," we don't just tell them where it is. We figure out why they couldn't find it and fix the problem.

The biggest surprise? Our team has started contributing to the knowledge base without being asked. When someone figures out a tricky process or solves a weird bug, they just... write it up.

Because they know it'll save everyone time later.

The Uncomfortable Truth About Self-Service

Here's something we learned the hard way: even when you have great documentation, people still want to ask a human sometimes. And that's okay.

We've stopped trying to force everything through self-service.

Instead, we use our knowledge base as a foundation that makes human interactions better. When someone emails us, we can give them a comprehensive answer plus links to related resources. They get help now and the tools to help themselves next time.

How We Integrate Knowledge Base Articles into Support Tickets

Get the lowdown on how we tackle tickets and improve our knowledge base in the process.

HelpDocs BookmarkedRiver Sloane

This connects to something we've written about before regarding balancing efficiency with empathy. Documentation should enhance human support, not replace it entirely.

The Little Things That Made a Big Difference

Some of the most impactful changes we've made to our own setup are tiny:

• Displaying "Last updated" dates on every article (because outdated info is worse than no info)
• Using consistent naming for similar processes ("How to..." vs "Setting up..." matters more than you'd think)
• Including screenshots/videos for every UI-related instruction (because our interface changes and people forget to update text)
• Displaying "Related articles" to the bottom of everything

We've also gotten used to optimizing our content for AI, because we know more customers are using AI tools to find information. Structured content with clear headings and step-by-step instructions works better for both humans and machines.

What This Means for You

If you're building or managing a knowledge base, the best advice I can give you is this: actually use it.

Don't just publish articles and hope for the best. Use your own documentation for real work. Try to find answers to actual questions your team has. Experience the frustration of searching for something that should be easy to find but isn't.

Your knowledge base should feel like a tool that makes your life easier, not a chore you have to maintain. If it doesn't pass that test for your own team, it won't pass it for your customers either.

And remember—being your own customer isn't just about finding bugs or missing features. It's about understanding how documentation fits into real workflows, real stress, and real human behavior.

The goal isn't perfection. It's building something so useful that people actually want to use it 🚀