Picture this: it’s late Friday afternoon, and a client’s CEO is on the phone. They’ve locked themselves out of their email and absolutely must send a cat meme to their board of directors. No judgment—it’s urgent to them, so now it’s urgent to you. You log into IT Glue, type “email password” into the search bar, and brace yourself for chaos. What comes up? A smorgasbord of cryptic document names like:
- “Random Login Info”
- “CEO-Important (NEW!!!)”
- “DO NOT DELETE!!!”
The problem isn’t IT Glue or the search tool—it’s your lack of naming standards. Poor naming conventions create a nightmare for any MSP trying to provide timely IT services. I know because I’ve been there. Back when I owned my MSP, we struggled with this for years. Every time a ticket escalated into a mad scramble to find the right doc, we’d swear we’d fix it. And then we didn’t. Until we did.
After a lot of trial and error, we finally settled on a naming standard that actually worked. Along the way, we tried other approaches—some decent, some terrible, and some that seemed brilliant until they completely fell apart. Here’s what we learned, and how you can implement a system that keeps your IT documentation clean, searchable, and frustration-free.
The Standard We Settled On: Customer Code – Service – Name
When it came to improving our documentation, we knew the solution had to make sense not just to the person creating the document but also to every other technician. Eventually, we settled on the format:
CUSTOMER_CODE - Service - Name
Example:
For a client named MegaCorp, we’d create docs like:
- MEGA – SharePoint Online – How to Add Management to Privileged Sites
- MEGA – VPN – User Setup Guide
- MEGA – Office365 – Reset CEO Email Password
Why This Worked for Us:
This standard was a game-changer. First, the Customer Code grouped all documents for a client together, so searching for “MEGA” brought up only MegaCorp’s docs. Second, adding the Service in the middle made it easy to identify the type of document without clicking through every result. Finally, the Name provided a plain-English description that anyone—whether a help desk tech or project engineer—could understand.
One Friday afternoon, a ticket came in for MegaCorp’s CEO, who needed his SharePoint access adjusted ASAP. Thanks to this standard, the tech handling the ticket typed “MEGA SharePoint” into IT Glue and instantly found the exact document they needed. It was one of those rare moments in MSP life where things just worked.
What We Tried First: Category-Based Naming
Before we landed on Customer Code – Service – Name, we thought it would be brilliant to group documents by category. The idea was simple: categorize by the type of document, so everything about credentials, procedures, or configurations could live under its own umbrella.
Format: Category - Customer - Specific Detail
Example:
- Credential – MEGA – CEO Email Login
- Procedure – ACME – VPN Setup Guide
- Configuration – DATA – Firewall Rules
It seemed like a logical system at first. Grouping by Category made sense on paper—after all, if you’re looking for a credential, wouldn’t you search under “Credential”? But here’s the problem: in real life, when you’re handling 30 tickets a day for 15 clients, you don’t remember which category the document falls under. Searching for “VPN” gave us every single VPN doc across all clients. If you’ve ever tried to pick the right one out of a dozen with the same name, you know the pain.
Lesson Learned:
Category-based naming works if you have a small client base or very narrow focus. For a typical MSP juggling dozens of clients, it gets messy fast.
The Team-Specific Prefix Approach
Next, we thought, “Let’s divide and conquer!” Instead of focusing on the document type or client, we assigned prefixes based on the team responsible for that task—help desk, project engineers, or the NOC.
Format: TEAM - Customer - Task
Example:
- NOC – ACME – Firewall Configuration Guide
- HD – MEGA – Reset CEO Email Password
- PE – DATA – Server Migration Checklist
This worked really well for dividing responsibilities. A help desk tech could search “HD MEGA” and immediately see only the documents they needed. The NOC could focus on backend infrastructure tasks without wading through a sea of help desk guides.
Where It Went Wrong:
While this method worked for team silos, it broke down for cross-functional tasks. If the help desk needed to reference a NOC document—or vice versa—good luck. It also became confusing when multiple teams touched the same project. We ended up with duplicates like:
- NOC – MEGA – VPN Setup Guide
- HD – MEGA – VPN Setup Guide
Lesson Learned:
Great for role-specific MSP workflows, but it created barriers to collaboration.
The Function-Based Approach
Finally, we tried organizing documents based on their function—processes, checklists, or guides. This was an attempt to focus on the purpose of the document rather than its category or owner.
Format: Function - Customer - Purpose
Example:
- Process – MEGA – Employee Offboarding Steps
- Checklist – ACME – Office Move Plan
- Guide – DATA – Setting Up MFA
At first, this seemed like the perfect solution. Need a step-by-step process? Search “Process.” Looking for a to-do list? Try “Checklist.” But as our MSP grew, we started running into trouble.
The Downside:
Not every document fits neatly into a single function. Was a VPN configuration a checklist or a guide? What about a firewall setup—guide or process? And even when we did agree, searching for “Checklist” across all clients returned way too many irrelevant results.
Lesson Learned:
Function-based naming works in theory but struggles to scale for an MSP with complex client needs.
What We Learned (the Hard Way)
Through trial, error, and a whole lot of late-night cleanup sessions, we realized a few universal truths about IT documentation:
- Consistency is Everything: A naming standard is only as good as the team’s ability (and willingness) to follow it. Make the rules simple, train your team, and enforce it.
- Short and Scannable Wins: Long names get cut off in search results, and vague names like “Stuff for VPN” aren’t helpful to anyone.
- Searchable by Client is Non-Negotiable: In an MSP, the ability to filter documents by customer is a must. Any system that doesn’t make this easy will fail.
