Most new employees don't struggle because information is missing. They struggle because it is everywhere: a welcome PDF in one folder, tool logins in a chat thread, the real process in a colleague's head. The first weeks turn into a scavenger hunt, and the people who already know the answers spend their days repeating them.
An internal knowledge base fixes that, but only if new hires know where to begin. In 2023 we at eniston wrote about why a knowledge database is the key to successful onboarding, covering the phases of onboarding and why documentation matters. This article is the practical follow-up: a concrete "Start here" structure for internal knowledge base onboarding, organized by day 1, week 1 and the first 30, 60 and 90 days, with role-based categories and clear ownership.
A typical internal wiki is organized by department or by tool. That makes sense for people who already know what they're looking for. A new hire doesn't. They don't know that the expense policy lives under "Finance" or that the deployment checklist is filed under "Engineering > Ops > Releases".
Onboarding content works better when it is organized by time and role:
By time, because a new hire's questions change week by week. On day 1 they need a laptop and a login. In month two they need to know how decisions get made.
By role, because a designer, a support agent and a developer share a few company basics but otherwise need very different information.
With an owner, because onboarding articles go stale faster than almost anything else. Tools change, people leave, processes get renamed.
If you're setting up an internal knowledge base from scratch, our guide on how to create a knowledge base covers purpose, categories and launch. Here we focus on the onboarding part.
Everything begins with one page. Call it "Start here" or "Welcome", pin it as the entry point of your internal knowledge base and send the link with the offer letter or the first-day email.
A good "Start here" page is short. It is a map, not a manual:
A two-sentence welcome from the team lead or the managing director.
What to do today, as a link to the day 1 checklist.
The onboarding path, with links to week 1 and the 30-60-90 day pages.
Your role's category, with one link per role.
Who to ask, with the onboarding buddy, the IT contact and the HR contact by name or role.
How to use this knowledge base, in two lines: use the search, and tell us when something is wrong.
Resist the temptation to put the employee handbook on this page. Every extra paragraph pushes the next step further down.
The day 1 page answers one question: what do I need to be able to work tomorrow? Keep it to a checklist a new hire can finish in a few hours.
Accounts and logins, with one short article per tool rather than one long page for all of them
Hardware and security basics: laptop setup, password manager, two-factor authentication
Where people talk: which chat channels to join and what each one is for
The first-week calendar: who they meet, when and why
Practical basics: working hours, office access or remote setup, how to report sick
Company history, the full org chart, every policy. Link to them from later pages instead. On day 1, the goal is that nothing blocks the new hire, not that they know everything.
By the end of week 1 a new hire should understand how the company works and what their team does. This page links to a handful of articles, not dozens.
Company basics: what we sell, who our customers are, how we make money
How we work: meetings, how decisions are documented, where tasks live, response-time expectations
Team overview: who does what in your team, and which neighboring teams you'll work with most
Key processes: the three to five processes every employee touches, such as booking time, requesting leave, submitting expenses or handing over a customer request
A first small task: a real but low-risk piece of work, with the articles needed to complete it
That last point matters. Reading builds context, but doing a real task shows the new hire where the documentation has gaps. Ask them to note every question the knowledge base couldn't answer. That list is your best backlog.
After week 1, onboarding becomes less about information and more about ownership. A 30-60-90 day page gives both the new hire and their lead a shared picture of what "settled in" means.
Complete the role-specific learning path (see below)
Shadow colleagues on core processes
Take over first recurring tasks with support
Hold a check-in with the team lead at the end of the month
Work independently on standard tasks
Improve or write at least one knowledge base article in your area
Take part in a cross-team project or process
Check in on what's going well and what's unclear
Own a defined area, client or process
Become the owner of the related articles
Onboard or support the next new hire on one topic
Hold a 90-day review with goals for the next quarter
Keep these pages generic enough to apply to everyone and link to role pages for the specifics. A 30-60-90 page that tries to describe every role ends up describing none of them well.
Company-wide content is the same for everyone. Role content is where most of the real knowledge lives. A simple category structure for an internal onboarding knowledge base could look like this:
Start here: welcome page, day 1 checklist, week 1, 30-60-90 day plan
Company: mission and customers, org overview, policies, benefits
How we work: communication, meetings, tools, security
Roles: one subcategory per role, for example Support, Sales, Design, Development, Project management
Processes: step-by-step guides that several roles share
Reference: glossary, contacts, templates
Within each role subcategory, start with a short learning path: five to ten articles in the order a new person should read them, ending with the role's 30-60-90 specifics. Write the step-by-step articles with a consistent structure. Our knowledge base article templates for how-to, troubleshooting, FAQ and reference articles work just as well for internal documentation as for a public help center.
Agencies have an extra layer: client knowledge. Keep internal onboarding separate from client-facing documentation, ideally in its own workspace. We describe the client side in how agencies can run a separate help center for every client.
Onboarding content has a short shelf life. A login article that describes an old tool sends a new hire straight back to asking colleagues, and they'll stop trusting the knowledge base quickly.
Three simple rules keep it current:
Every article has an owner. One person or role, not "the team". Write it at the top or bottom of the article, for example "Owner: IT. Last reviewed: October 2026".
Every article has a review date. Day 1 and tool articles every three months, policies and processes every six to twelve months.
Every new hire is a reviewer. Ask them to flag anything outdated during their first two weeks. Nobody notices gaps better than someone reading the documentation for the first time.
A quarterly 30-minute review, where owners go through their articles, is usually enough. Start with the "Start here" category, because that is what every new hire sees first.
An onboarding knowledge base contains things that shouldn't be public: internal processes, contact details, client names, sometimes system information. Before you invite the first new hire, decide who can see what. If you're in the EU, our GDPR checklist for knowledge bases covers access control and personal data in more detail.
We built eniston for public help centers and internal knowledge bases alike, and onboarding is a common use case among our customers. One of them, Nico Tjarks of Homepage Helden GmbH, describes it on our homepage: "We use eniston for on-boarding new staff members and for documenting various internal processes. This helped us to speed up tasks, which is a huge win."
The structure above maps directly to eniston's features:
Categories and subcategories for the company, process and role structure. See categories and subcategories.
Sections to group categories, for example "Start here", "Company" and "Roles". Each section can have its own starting point, either a category or an article, which is a natural home for your "Start here" page. See using sections.
Frontend authentication so that only invited team members can open the workspace. Combined with the Read-only role, new hires can read everything but can't change content until you give them an editor role. See restricting access and roles and permissions.
IP restriction or passwords as alternatives: allow only your office IP addresses, or protect the workspace or individual categories with a password.
Instant search so new hires find answers without knowing the structure.
Article feedback and statistics to see which onboarding articles are read most and which ones readers don't find helpful.
Version history that keeps the 20 latest saved versions of a published article, so a well-meant edit is easy to undo. See version history.
Team features, including frontend authentication with team members and the Read-only role, are available on our Business plan. Because we don't charge per user, onboarding ten new people a year doesn't change your bill.
A good onboarding knowledge base isn't the biggest one. It is the one where a new hire knows exactly where to start. Build one "Start here" page, a day 1 checklist, a week 1 overview and a 30-60-90 day plan, then add role-based categories with clear learning paths. Give every article an owner and a review date, and let each new hire help keep it current.
If you'd like to set up your own "Start here" structure, start your free 30-day trial. No payment information is required. Our plans are flat, with no per-user fees: Plus at €8 per month with 2 workspaces and Business at €28 per month with 10 workspaces (excl. VAT). See pricing for details.
Our knowledge base software offers a great variety of features to manage your knowledge articles. Try eniston for free for 30 days. No credit card required.
