How to name internal shortcuts
The most common reason internal shortcuts don’t get used has nothing to do with the technology. It’s the name.
If go/pto-request-form-2026-current is in the system, nobody is going to type that from memory. If go/pto is enough, people remember it without looking it up.
Naming sounds trivial. In practice, it fails regularly because different people have different ideas about what makes a good name.
Short beats descriptive
Shortcuts are supposed to work from memory. That means: the shorter, the better. Two syllables is ideal, three is acceptable, anything beyond that gets looked up instead of typed.
go/wiki instead of go/internal-knowledge-base. go/ticket instead of go/jira-support-ticket-create. go/expenses instead of go/expense-report-submission.
When in doubt: how would someone describe the link in a Slack message? “Send me the link for expenses” becomes go/expenses. Not go/expense-report-submission.
Consistent language
Nothing undermines a shortcut system faster than inconsistency. When some links are in English (go/onboarding), others in German (go/einarbeitung), and others mixed (go/new-hire-prozess), everyone has to guess which language applies.
For most teams, a simple rule works: one language for all shortcuts. In international companies, that’s usually English. In a company where everyone speaks the same language, the local language may be the better choice.
What matters more than the language choice is the consistency. Stick with one language, even when it feels awkward for individual terms.
Separators
go/all-hands, go/all_hands, or go/allhands? Many systems resolve all three variants identically. Still, a team should agree on one style so the link library looks consistent.
Hyphens are the most common choice because they’re standard in URLs and feel natural to read. Underscores work but look unusual in some contexts. Concatenated words work for short terms (go/roadmap) but become unreadable for longer ones (go/quarterlybusinessreview).
Categories, not hierarchies
Some teams try to map their entire org structure into shortcut names: go/hr/recruiting/application, go/it/infra/vpn, go/finance/controlling/budget.
This rarely works. First, nobody remembers the full path. Second, department names change, and then the links don’t match anymore.
Better: flat names with an optional prefix for the area. go/hr-pto, go/hr-payroll, go/it-vpn. Or completely flat when the terms are unambiguous enough: go/pto, go/vpn, go/budget.
Avoiding duplicates
The problem appears as soon as more than one team creates shortcuts. Marketing creates go/analytics for Google Analytics, the product team creates go/analytics for the internal dashboard.
The fix is either a light qualifier (go/ga, go/product-metrics) or a convention about who “owns” which terms. In practice, it helps to check whether the name is already taken before creating a new shortcut.
Use abbreviations sparingly
go/qbr saves four syllables compared to go/quarterly-business-review. But only people who know what QBR means will find the link. New hires who haven’t learned the acronym yet are stuck.
Abbreviations work when they’re established within the company. go/jira makes sense to every engineering team. go/qbr might only make sense to the leadership team. When in doubt: use the full word and add an abbreviation as an alias, if the system supports aliases.
Clean up regularly
Shortcut libraries grow fast and go stale just as fast. A quarterly review helps: which links haven’t been clicked in the last 90 days? Which point to pages that no longer exist? Which have duplicate or similar names?
Cleanup is less work than it sounds. Usually half an hour per quarter is enough to remove dead links and fix confusing names.
Checklist
Before creating a new shortcut, three questions are worth asking: can someone who has never seen the link guess it? Is there already a similar name in the system? And does the language and formatting match the existing links?
If all three answers are yes, the shortcut will most likely get used.