SharePoint onboarding sites are usually well built and barely used. The content is accurate, the structure is sensible, and a new starter will still ask a colleague, because reaching the page requires permissions they may not have and vocabulary they definitely do not.
TL;DR
- Two things defeat SharePoint onboarding content: permission boundaries and search that rewards exact terms.
- A new starter often lacks access to the site holding the instructions for getting access.
- Search works well for people who know the internal vocabulary, which excludes everybody in week one.
- Version sprawl is the slower problem: three documents with similar names and no indication which is current.
- Keeping SharePoint as the store and putting retrieval in front of it is cheaper than migrating.
- Page titles written as questions outperform any navigation redesign.
The permission problem comes first
The most common failure is circular and nobody designs it deliberately. The onboarding site sits inside a team or group that a starter is added to as part of onboarding, so the instructions for completing onboarding live behind a boundary that onboarding is supposed to remove.
What the starter sees is not a helpful message. It is a request access screen, or worse, a page that renders with sections missing and no indication anything is absent. The second case is the dangerous one, because the person reads an incomplete document believing it is complete.
Test this properly rather than assuming. Open your onboarding site as a brand new account with only the groups a day one starter has, not as an administrator with a live session. Most teams who do this find at least one page that does not load.
Search rewards people who already know
SharePoint search is competent at finding documents when you know roughly what they are called. That is precisely the knowledge a new starter lacks.
Somebody wondering whether they can claim a taxi searches for taxi. The document is called Travel and Subsistence Policy and does not contain the word taxi anywhere. The search returns nothing useful, the starter concludes the answer is not written down, and asks a person. The content was there, correct and complete, and the retrieval mechanism failed.
This is why rewriting the content rarely helps. The content was not the problem.
Version sprawl, the slower failure
Over a few years a SharePoint site accumulates near duplicates: a policy, a revised policy, a summary somebody made for a presentation, and a copy in a different team’s library. All four are findable and none is labelled as superseded.
An experienced employee handles this by recognising which one people actually use. A new starter cannot, so they take whichever ranked first, which is often the summary because it has a friendlier title. They then act on a document that was never authoritative and was last touched three years ago.
What to do:
- Search your own site for your five most common topics and count the results.
- For each topic, pick one authoritative page and mark it clearly.
- Archive the rest rather than deleting, so links do not break silently.
- Put a visible last reviewed date on the survivors.
- Name an owner per page, not per site.
A migration that was not needed
A sixty person company concluded its SharePoint onboarding content had failed and scoped a move to a different documentation tool. The estimate was six weeks.
Before starting, somebody ran the permission test. Two of the eleven onboarding pages were inaccessible to a day one account, including the one explaining how to request software. They also counted search results for their five most asked topics and found between three and seven pages each, none marked current.
Fixing permissions took an hour. Consolidating to one page per topic took two days. Question volume dropped enough that the migration was shelved, and the content that would have been moved was the same content that now worked.
Retrieval in front, storage behind
If the content is sound and the problem is reaching it, the cheaper architecture is to leave SharePoint as the store and put something in front that answers questions.
This keeps your permissions model, your version history and your compliance position, all of which are reasons people chose SharePoint in the first place. It changes only the retrieval step, which is the part that failed.
Matram is our own product and it works this way: it reads the documents you point it at and answers in the channel people already use, rather than asking them to visit a site. It has no free tier, it is not an HRIS, and its actions reach HubSpot, Zendesk and webhooks only, so it answers and can open a ticket but changes nothing in SharePoint. WhatsApp is coming soon rather than available. Pricing is flat at $29, $69 and $199 a month with unlimited seats. It will not fix the permission problem or the duplicate pages, and if you point it at four versions of a policy it will answer from whichever it was given.
That last point is the one to plan around. Consolidation comes before retrieval, in that order, or you have automated the delivery of an outdated summary.
What to fix, in order
| Symptom | Real cause | Fix |
|---|---|---|
| Starters say they cannot find it | Vocabulary gap in search | Retitle pages as questions |
| Page loads with sections missing | Permission boundary | Test with a day one account |
| Wrong answer from a real page | Superseded duplicate | One authoritative page per topic |
| Nobody trusts the site | No freshness signal | Visible last reviewed date |
| Questions continue after a rewrite | Retrieval, not content | Answering layer over the store |
The checklist worth keeping
Checklist:
- Onboarding site opened with a day one account, every page loading.
- One authoritative page per topic, duplicates archived.
- Page titles phrased the way people ask.
- Last reviewed date visible on each page.
- A named owner per page.
- A pinned link where the team already works.
Final Thoughts
SharePoint is rarely the reason onboarding content goes unread. Permissions that exclude the people the content was written for, titles that do not match how anybody asks, and four versions with no indication which is current will defeat any platform.
Run the day one account test, consolidate to one page per topic, and only then consider whether you need something in front of it. Teams that do those two things first often find they needed nothing else.
Frequently asked questions
Why do new starters not use our SharePoint onboarding site?
Usually one of two reasons. Either they cannot reach some of it, because the site sits behind a group membership that onboarding itself is meant to grant, or they cannot find things, because search rewards knowing the internal name of a document and week one is exactly when nobody knows it. Both are fixable without moving the content anywhere.
How do we test permissions properly?
Open the site using a freshly created account with only the group memberships a day one starter has, in a private browser window so no administrator session is reused. Visit every onboarding page. Teams who do this commonly find at least one page that fails to load, and often one that renders partially with no warning that anything is missing.
Should we migrate off SharePoint?
Rarely, if the complaint is that content is hard to find. Migration moves the same documents into a different store and usually reproduces the same problems within a year, because the causes were titling, duplication and permissions rather than the platform. Fix those first and re-evaluate, since the work is needed either way.
What should we call our pages?
Name them the way people ask rather than the way you file them. A page called Can I expense a taxi is findable by somebody who has never seen your documentation, while Travel and Subsistence Policy is findable only by somebody who already knows the term. Keep the formal title inside the page for anybody who needs to cite it.
Will an answering layer fix duplicate documents?
No, and it can make the consequences worse. A retrieval tool answers from whatever it was given, so pointing it at four versions of a policy means it will confidently answer from one of them without signalling the ambiguity. Consolidate to one authoritative page per topic before adding anything in front, not afterwards.
How often should onboarding pages be reviewed?
Twelve months is reasonable for most content and six for anything containing a number, a threshold or a named person. The review is a confirmation rather than a rewrite and usually takes a few minutes per page. What matters is that the date is visible to readers, because a new starter has no other way to judge whether a page is maintained.
