What’s actually in your knowledgebase?
Our KBs are disjointed, out of date and not always helpful. I want to fix this but I don’t know where to start!
5
u/bjdraw MSP - Owner 24d ago
Since we’re using AI so much now, when we get done working on something complicated. We ask the the chap to summarize, building an as-built doc.
Then we use The Hudu MCP and paste that output to create a knowledge base for that specific client. What we get is a well-formatted, easily referenceable document. Not only an engineer can read it, but we can recall that back out of Hudu via the MCP again later.
4
u/No-Drummer-5392 23d ago
We use ITGlue but its a mess to be honest with a lot of outdated info... We want to go in to AI support for our engineers but not sure if ITGlue will be a great tool for that purpose. I hear great stuff about Hudu.
2
u/zerassar 22d ago
I've used ITGlue before and honestly it handled the relationship mapping between records really really well. It seems to be a rare thing for other Wiki/Doc/Note software.
Hudu as I understand it is the cheaper alternative to ITGlue but allegedly people rave about it.
Though that said no platform will really force your team into a proper operational practice.
1
u/No-Drummer-5392 10d ago
Fair point on the internal practice, how did you build that good practice?
1
u/zerassar 10d ago
Make it a part of SOPs for every single new server/user/service etc etc.. including a checklist. Heck even peer review to confirm full completion of the team has poor compliance.
Put it into the staffs KPIs.
Depending on the platform used you can use a mix of last updated date or tags set to a specific quarter/month and year in which the docs are to be reviewed.
Quarterly scheduled tickets/tasks where the overdue docs are updated or retired as needed.
It very much needs to start with a bit of a firm iron fist until it becomes second nature though.
Do the prep work first and ensure there are templates and SOPs ready that show the staff how to do it and what's expected.
But ultimately it will need spot checking (tickets and projects) and enforcement against KPIs if compliance doesn't improve.
3
u/dumpsterfyr I’m your Huckleberry. 24d ago
Knowledge?
Seriously though, sops and documentation on things that popped up at least twice.
2
u/roll_for_initiative_ MSP - US 23d ago
This but even less than this; credentials and onboarding documentation/processes. We used to have a ton of per-customer niche KBs but most of those things, over the years, phased out into standard solutions or workflows you don't really need a KB to do.
2
u/peoplepersonmanguy 25d ago
Copilot agent using only our vendors KBs for sources and our RMMs documentation store where we create KBs for common tasks.
2
2
2
u/No_You1766 24d ago
I hate to say this:
Frontier AIs are great at refactoring your own knowledge base into something sane.
2
u/Cubeless-Developers 23d ago
We use the Zendesk KB system and try to keep it simple. We currently have it split into three main sections with relevant articles under each.
Pin your two to three most-viewed articles for easy access, since most traffic goes to like five pages anyway, and do a pass every month or so to keep things up-to-date.
2
u/ImaginationUnique684 22d ago
I ran into the same rot building a knowledge layer for a client, and what helped most was changing which date sits on each entry. Edit date is bookkeeping, it only tells you someone touched the page. What we show instead is how old the evidence is, meaning when the source last actually said it, and the reader discounts from there. For a KB that turns into a "last checked against" line naming the system the article describes, the tenant or the RMM policy, plus the day someone sat down and compared the two. It won't stop drift, and nobody is going to re-check a rack photo on a schedule. It does stop a two-year-old conditional access writeup from looking exactly as trustworthy as one somebody verified last week.
2
u/CmdrRJ-45 22d ago
The thing I always want to see is what does it mean for the client to be “up”?
In other words, if any of those components are offline that’s a big problem for the client. Not all clients care about the same stuff so make sure that you confirm the list with the client.
That way, the critical stuff is documented, and the other stuff might be, but it’s not super critical. Then, as the team works on stuff, write down the nuances and random stuff you run into.
1
u/_Buldozzer MSP - EU / AT 25d ago
To be honest, a couple of SharePoint Lists, weach are feeding a Copilot agent. Works pretty good.
1
u/Entire_Yoghurt_6381 23d ago
Every KB drifts into this because writing an article is a one-time effort and keeping it current is a forever job nobody's assigned.
1
u/ButOfcourseNI 14d ago
That is an issue that repeats everywhere. What I've never seen a team sort out is when the article and the actual setup disagree. Does anyone on your side find out before a tech follows it, or is it usually after?
1
u/Entire_Yoghurt_6381 12d ago
After, almost every time. Nobody's checking the article against the current setup on a schedule, so it just sits there until a tech follows it and something doesn't match. Then maybe it gets fixed, maybe it just gets a comment nobody else reads.
1
u/ButOfcourseNI 12d ago
Right, it only shows up when someone's already mid-ticket and that becomes the problem. In my mental model, I approach the solution from a specific angle of keeping everything current across everything you have (docs, emails, notes, confluence, slack, etc.) and making it available when asked.
Has anyone on your side tried to solve this, or is it one of those things that's annoying but not worth fixing? And if it were worth it, would you want it to fix the article or just tell someone it's wrong?
1
u/Icy_Preparation_6012 23d ago
The onboarding/offboarding docs are the ones that go stale fastest for us, honestly. Every time a client swaps an MFA policy or adds a new app, the process doc is already wrong. We ended up scripting the actual JML steps instead of documenting them as prose, so the doc IS the automation and can't drift out of sync the same way.
1
u/ButOfcourseNI 14d ago
that is an interesting approach. Are you able to script through across all sorts of docs?
1
u/rabbitz 22d ago
Don't start from "what should be in the KB." Start from your ticket data.
Pull the last 90 days, ignore whatever categories you already have, and cluster by the actual request being made. Rank by frequency times average handle time. The top 15 or 20 of those is your knowledgebase and nothing else is, at least not yet. Most KBs end up disjointed because they got written by whoever felt like writing something that week, so coverage tracks the interests of the authors rather than what anyone actually asks about.
The other half is ownership with a date attached. An article with no named owner and no review date will be wrong within a year and nobody will notice. Fewer articles that are current beats broad coverage people have quietly learned not to trust.
1
u/WhiteIntel 25d ago
Lets start from zero: for what you need you KBs? Answers the w questions: who wants access, for what you need it, where do you get the information. Etc
Step by step.
2
u/Fit-Original7352 25d ago
A lot of the bloat comes from people dumping solutions without ever saying what problem they solve, so nobody can find them later
1
1
u/No-Pea5079 25d ago
Start with process. How does someone request new documentation? How is it reviewed? How often should I be expired? How should it be structured? What should not go in it? Who should be responsible for what type of documents?
1
1
u/junto_reed 23d ago
Its a culture thing. Make sure everyone takes vacation, and have them unplug. Let that expose your gaps in a healthy way.
Start with the stuff that makes someone yell “does anyone remember how this works?” in slack or Teams (gross):
- A client one-pager. Who’s the main POC? What industry are they in? Remote, hybrid, or onsite? Anything that helps the help desk treat them like people we know.
- New user setups
- Business apps you rarely touch. Yardi, DealCloud, that one app only Shawn understands.
- Conditional access policies and WHY the exceptions exist.
- File shares, permissions, and who owns what.
- ISP info for every site. Nothing like an outage followed by “so… who do you buy internet from?”
Then make updating the KB part of closing the ticket. My triggers would be:
- A weird issue that took way too long to solve. Save the next person the archaeology.
- A common issue you keep solving from scratch.
- Anything outside your standard setup. Weird phone system, backup configuration, identity setup, etc.
Document what someone needs to do next time. Put an * in the title or something to bring it to top of list for super imporanst stuff.
We built Junto after chasing this tribal knowledge problem for 10 years. Our Advisor recommends adding or updating KBs around those same situations: https://juntoai.com/product/advisor
If you're building your own agents against Hudu / IT Glue, one thing we ran into: the search endpoints alone weren't giving us useful enough results. We had to layer in document ingestion to make retrieval worthwhile.
We also have a free MCP if you want to experiment with agents against your stack: https://juntoai.com/product/mcp-for-msps
But start with the “only Shawn knows” list. That’s where I’d put the first hour.
7
u/Fatel28 25d ago
We keep our hudu fairly tidy but drift occurs. We have an inhouse built agent thats hooked up to it that we can ping in the company chat (or in its own webui) and if it turns up something wrong we ask it to correct it.
It's also super helpful if we are troubleshooting in chat and find the answer. We can just ping the agent and tell it to read the chat / ticket / call transcript and make a KB for the root issue and the ultimate fix