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:
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.
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
For a client named MegaCorp, we’d create docs like:
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.
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
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.
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
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:
Lesson Learned:
Great for role-specific MSP workflows, but it created barriers to collaboration.
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
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.
Through trial, error, and a whole lot of late-night cleanup sessions, we realized a few universal truths about IT documentation: