HR Intranet or Answering Layer: Which One Employees Actually Use

<p id="tldr"></p>

TL;DR

• An HR intranet is a destination. Everything else about the purchase follows from that, because destinations only work if people travel to them.
• The usual failure is not bad content. It is a correct, well-designed site that 11 per cent of staff visit in a month, which is a distribution problem dressed up as a content problem.
• Before buying, measure two numbers: monthly unique visitors as a share of headcount, and how many policy questions still arrive by other routes.
• Pricing in this category is almost entirely unpublished. Simpplr, Staffbase, Guru, Slab and Microsoft's own pages returned no server-readable figure when checked on 15 October 2026.
• The real choice is between improving a destination and adding delivery, meaning something that brings the answer to where people already are.
• Do both only if you have an owner for both. An unowned intranet decays into an archive within two quarters.

The Site Everybody Built and Nobody Visited

The redesign took four months and it was good. Proper information architecture, a search box that worked, policies grouped the way employees thought about them rather than the way the HR team filed them, and a homepage that did not open with a photograph of a handshake. Somebody had clearly cared.

Six weeks after launch, the analytics said 34 unique visitors in the previous month against a headcount of 290. The HR inbox volume had not moved. Managers were still being asked about leave carry-over and still answering from memory. The project was, by every internal measure anybody had agreed in advance, a success, and by the only measure that mattered it had changed nothing at all.

Recommended Tools

Best tools for HR Operations

B BambooHR HR management system R Rippling HR & IT automation W Workday Enterprise HRIS

View all recommended tools

What went wrong was not the build. It was the assumption underneath the build, which is that the reason people did not find policy information was that the policy information was badly organised. Sometimes that is the reason. More often the reason is that nobody thinks to go and look, because going to look requires remembering a site exists, opening a tab, and forming a search query, at a moment when sending a message to a colleague costs nothing and feels faster.

The real issue is not whether your HR intranet is good. It is whether an intranet is the right shape of answer to the problem you have.

When You Don't Need an HR Intranet

You have fewer than about 80 people. At that size everybody knows who to ask and the asking works. An HR intranet solves a coordination problem you do not yet have, and building one early mostly produces a site that goes stale because the volume never justifies maintaining it. A shared folder with clear names does the job.

Your content is not settled. If your policies are still changing monthly because the company is changing monthly, you will spend more time maintaining the site than anybody spends reading it. Build the destination once the content stops moving. Until then, a document people can find is enough.

Your actual problem is that managers answer wrongly. This is extremely common and an intranet barely touches it. Managers answer from memory, and a site they also do not visit does not correct their memory. The intervention that works here is a short manager-facing summary pushed to managers, not a site that waits for them.

You already have one that nobody uses. Rebuilding it will not change the traffic unless you have diagnosed why the traffic is low. If the last redesign did not move the numbers, a second redesign is unlikely to, and the money is better spent on delivery than on a third information architecture.

What People Actually Need From an HR Intranet

Five questions, and notice how few of them are about the site.

Where do I go when I do not know the word for the thing I need? Most policy questions arrive without the vocabulary the policy uses. Somebody wants to know if they can take Friday off for a funeral; the document is called Compassionate and Bereavement Leave. Search only works if the searcher's words overlap the document's words, and the gap between those two vocabularies is the single biggest reason intranet search gets blamed for being bad when the index is fine.

How do I know this page is current? A page with no visible date is a page nobody trusts, and distrust routes people straight back to asking a human. Every page needs a last-reviewed date in a place people see without scrolling. This is a fifteen-minute change that measurably moves trust and almost nobody makes it.

Can I get to it on my phone, signed in, in under thirty seconds? For a deskless or partly deskless workforce this is the whole question. If reaching the site requires a VPN, a desktop, or a password nobody remembers, the site does not exist for a meaningful share of your staff.

What do I do when the page does not answer my question? Every page needs an obvious next step, and that next step needs to not be a generic HR inbox. Dead-ending is what teaches people the site is not worth trying.

Who do I tell when it is wrong? Employees spot errors constantly and report almost none of them, because reporting requires knowing who owns the page. One named owner per section, visible, fixes more content problems than any review cycle.

What an HR Intranet Costs, and Why That Is Hard to Answer

This category publishes less pricing than almost any we have looked at. Checking each vendor's own page on 15 October 2026:

Six of seven did not return a figure a server-side fetch could read. That does not mean they publish nothing. Microsoft certainly publishes Microsoft 365 pricing, and the likeliest explanation across the set is that these pages render their numbers in JavaScript. The honest conclusion is that you cannot build a business case for this category from published figures, and you should expect a sales conversation for anything other than Notion.

That matters practically. If five of your six options require a call before you know the price, your evaluation will take weeks longer than you planned, and the two options with visible pricing will enjoy an advantage they have not necessarily earned on merit.

The Honest Alternative: Delivery Instead of a Destination

An HR intranet is storage plus a front door. The alternative shape is delivery: something that answers the question in the place the question was asked, usually a chat tool people already have open.

The two are not competitors in the way vendor marketing suggests. Delivery needs content, and that content has to live somewhere, so an answering layer sits on top of documents rather than replacing them. What changes is who does the travelling. A destination asks the employee to come and find the paragraph. Delivery takes the paragraph to the employee.

Which one you need depends on a number you can measure this week. Take monthly unique visitors to your current HR pages as a share of headcount. Above roughly 40 per cent, you have a destination people actually use, and improving it is the highest-return work available. Below about 15 per cent, you have a destination people have decided not to use, and a better destination is unlikely to change that decision. Between the two, it depends on whether the non-visitors are a specific group, usually deskless or field staff, in which case the answer is delivery for them and a destination for everybody else.

How to Choose: Five Questions Before You Talk to a Vendor

What is your current traffic share? If you cannot answer this, you are not ready to buy either shape. Any intranet, including a SharePoint site, reports unique visitors. Pull the last three months.

Where do your questions actually arrive? Shared inbox, direct messages, managers, or in person. Direct messages and managers both indicate that people are choosing a human over a document, which is a delivery signal rather than a content signal.

Is your workforce at a desk? Deskless staff change the answer completely. A site behind a VPN serves them not at all, and this single fact should probably decide the purchase on its own.

Do you have an owner with named hours? Both shapes need one. An intranet without an owner becomes an archive of things that used to be true, usually within two quarters, and an answering layer without an owner becomes confidently wrong on the same timetable. If you cannot name the person, fix that before you spend anything.

Is the content correct right now? Neither shape fixes wrong content, and delivery makes wrong content worse by distributing it privately and at speed. We have written about making a handbook machine readable, which is the preparation work that determines whether a delivery layer is worth buying at all.

Seven Options Worth Knowing

Notion. Best for teams who want one place for everything and are willing to accept that the intranet is a side effect of a general tool. Chosen because it is the only option in this set with pricing you can read without a call, at $0 Free, $10 Plus and $20 Business per member a month. Where it struggles: no analytics worth the name on the pages themselves, so you will struggle to answer the traffic question that should be driving your decision.

Confluence. Best for companies where engineering already lives there and HR content can join. Chosen because the permissions and page tree genuinely scale. Where it struggles: it reads as a wiki to anybody who is not an engineer, and its pricing page returned no server-readable figure on 15 October 2026, so expect to ask.

Microsoft 365 and SharePoint. Best for companies already paying for the suite, which is most companies over 200 people. Chosen because the marginal cost is usually zero and the identity integration is already done. Where it struggles: building something people want to visit in SharePoint takes real design effort, and the default output is the thing everybody pictures when they imagine a bad intranet.

Simpplr. Best for larger organisations treating internal communications as a function rather than a task. Chosen because it is built for the job rather than adapted to it. Where it struggles: no published price we could read, and the feature depth is wasted below a few hundred people.

Staffbase. Best for deskless and distributed workforces, which is the case where a traditional intranet fails hardest. Chosen because mobile-first is the actual architecture rather than a responsive afterthought. Where it struggles: same pricing opacity, and it is a communications product first, so treat the policy library as a secondary capability.

Matram. Best for teams whose content is already correct and who have concluded that the destination is not going to get the traffic. Disclosure, and it should colour how you read this: Matram is owned by the same people who publish this site. It is $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats and a 30-day trial that takes no card. Flat and seat-independent is the useful property for a growing company, because the bill does not move when headcount does. Where it struggles, stated plainly: there is no free tier, so you cannot run it at zero indefinitely; it answers questions but does not action tickets, so a leave request still needs a system that processes requests; and it is not an HR workflow platform, so cases, approvals and acknowledgement records all live elsewhere. It is also not an intranet. If what you need is a place to publish company news, this is the wrong product entirely.

SiteGPT. Best for teams wanting the same delivery shape on a different commercial basis. Chosen because it is the nearest honest comparison to the entry above. Pricing is one yearly payment of $468, $948 or $3,108, which works out at $39, $79 and $259 a month when billed yearly. Where it struggles: the annual commitment is the model, so there is no real monthly option, and the page-count ceilings matter if your document set is large.

The Decision Table

What the Vendor Demo Will Not Show You

Three things decide whether this works and none of them appear in a demo.

Search depends on your vocabulary, not the vendor's. Every demo search works because the presenter types the word the document uses. Your employees will not. Before you buy, take the ten most common questions from your own inbox, in the asker's words, and ask the vendor to search for those exact phrases against your own content during the call. Vendors who are comfortable with this are telling you something; vendors who want to use their demo content are telling you something too.

Adoption is a launch problem, not a product problem. The sites that get traffic got it because somebody ran an actual internal campaign, linked it from the places people already were, and kept mentioning it for a quarter. The sites that do not get traffic had an announcement email. No product feature compensates for a missing launch, and no vendor will tell you that the deciding variable is six weeks of your own nagging.

Staleness is invisible until it is embarrassing. Nothing in these products makes an out-of-date page look out of date. A page last reviewed in 2023 looks identical to one reviewed last week unless you have deliberately surfaced the date. Decide your review cadence before launch and put the date on the page, because retrofitting that discipline after the content has drifted is a much larger job.

The Vocabulary Test, Run Properly

The single cheapest diagnostic in this category takes about ninety minutes and almost nobody runs it, because it requires admitting you do not know what your employees call things.

Pull the last sixty policy questions from wherever they arrive. Copy them verbatim, including the typos and the vague phrasing, because the vague phrasing is the data. Do not tidy them into proper queries. A question that reads "can i use the thing for the dentist" is more useful than the same question rewritten as "dental appointment leave entitlement", and the rewriting is the mistake most teams make at this step without noticing.

Now search your own HR intranet for each one, exactly as written. Count three outcomes: the right page in the first three results, the right page somewhere below that, and nothing useful at all. Most teams running this for the first time find somewhere between a third and a half of their real questions land in the second or third bucket, on a site whose search they had assumed was fine.

Then read the failures and group them, because the cause is almost always one of three things and each has a different fix. Vocabulary mismatch, where the employee's word never appears in the document, is fixed by adding the employee's word to the page as an alias or a plain-language line near the top. Scope mismatch, where the answer is genuinely in the document but buried in a section about something else, is a restructuring job. And genuine absence, where the policy simply does not address the question, is an editing job that no search index can rescue.

The output of this exercise is a short list of specific page edits, which is a far better use of a week than another redesign. It also tells you something about the delivery decision: if most of your failures are vocabulary mismatches, an answering layer handles them well, because matching a question to a paragraph is precisely the thing it does better than keyword search. If most are genuine absences, delivery will fail for the same reason the site did.

Running the Launch That Decides Whether This Works

Adoption is the deciding variable and it is almost entirely about what you do in the six weeks after go-live. This is the part no vendor will tell you, because it is your work rather than theirs.

Link from where people already are, not from where you wish they were. That means the chat tool, the places managers already look, and the automated messages your systems already send. A new starter should meet the HR intranet inside their onboarding flow rather than in a welcome email they will not reread. Every policy question answered in the shared inbox for the first two months should be answered with the answer plus the link, in that order, because answer-then-link teaches people the site is useful while link-only reads as a brush-off.

Pick three recurring moments and attach the site to them permanently. The month before the leave year resets, the fortnight around any pay or benefits change, and the first week of every new starter's employment. Those are the moments when people have a genuine question and are willing to learn where things live. Generic awareness campaigns in quiet periods teach nobody anything.

Brief managers separately and first. They are the audience that moves the numbers most, because they absorb questions you never see, and they are the group most likely to answer from memory. Give them a one-page map of what lives where and be explicit about the handful of topics they should never answer without checking, which in most companies means anything touching pay, leave entitlement or notice. A manager who checks instead of guessing is worth more than a hundred employee page views.

Then keep mentioning it for a quarter. This is the unglamorous part and it is the part that separates the sites with traffic from the sites without. Teams consistently underestimate how many repetitions it takes before a new habit replaces asking a colleague, and consistently stop at the announcement. Plan for twelve touches over twelve weeks and you will beat a better-designed site that got one.

What Changes When Your Workforce Is Not at a Desk

If a meaningful share of your people do not have a company laptop, this fact should probably decide the purchase on its own, and it is worth being concrete about why.

A traditional HR intranet assumes three things that are false for deskless staff: a browser, a persistent signed-in session, and a moment of unhurried time. A warehouse team leader checking a shift-swap rule has a personal phone, no company email on it, and ninety seconds. Anything behind a VPN or a desktop single sign-on flow does not exist for that person, and the adoption number will show it as a flat refusal that looks like disengagement and is actually a locked door.

Count the split before you buy. Take headcount, subtract the people with a company laptop and a daily email habit, and express the remainder as a percentage. Above roughly 30 per cent and a desk-first intranet will serve the minority of your organisation while appearing to work, because the people evaluating it are all in the group it serves.

The options genuinely differ here. Staffbase and products like it treat mobile as the architecture rather than a responsive layout, which matters for authentication as much as for layout. A general workspace tool used as an intranet will serve deskless staff poorly no matter how well the content is organised. And delivery into a chat tool only helps if the chat tool is actually on the phones, which for many deskless workforces it is not.

The honest answer for a split workforce is usually two things rather than one: a destination for desk-based staff, and for everybody else the shortest possible path from a personal phone to a correct answer, which often means a published number or a channel staffed by a person. That is less satisfying than one system and it reflects the reality that your two populations have different constraints.

Consolidating the Three Sites You Already Have

Most companies above 200 people do not have one HR intranet. They have a current one, a previous one nobody switched off, and a folder structure that predates both, plus two or three pages somebody built in a department tool. The consolidation is usually the real project and it is reliably underestimated, because the hard part is not moving content but deciding what dies.

Inventory first, and inventory by traffic rather than by completeness. Every platform you are running reports its most-visited pages. Pull the top thirty from each source and you will typically find that a small fraction of the content carries almost all the traffic, and that several of the busiest pages are ones nobody on the HR team would have listed as important. Those pages are your migration scope. The long tail is not, whatever its authors think.

Then decide the fate of each legacy source explicitly, in writing, with a date. There are only three honest options: migrate it, archive it read-only behind a clear banner saying it is not maintained, or delete it. The failure mode is a fourth option nobody admits to choosing, which is leaving it live and hoping people stop using it. They do not stop, because search engines inside your own tools keep surfacing it, and a live stale page is worse than a deleted one. A reader who hits a deleted page asks somebody. A reader who hits a stale page acts on it.

Redirect what you can and announce what you cannot. If the old pages sit on a platform that supports redirects, use them, because links to internal pages live in old emails, onboarding decks and manager notes for years. Where redirects are impossible, the banner approach is second best and needs to name the new location rather than just declaring the page old.

Expect contradictions to surface during this and plan for who resolves them. Consolidating three sources reliably reveals two or three places where the same policy says different things, and that resolution is an HR decision rather than a content task. Teams routinely schedule the migration as a week of admin work and then stall for a month waiting for somebody senior to rule on whether notice is four weeks or a month. Identify the likely collisions during the inventory and get the rulings before you start moving anything.

One more thing worth doing while you have the inventory open: note who wrote each surviving page and whether that person still works there. An HR intranet accumulates orphaned content faster than anything else a people team owns, and the moment of consolidation is the only cheap opportunity to assign every surviving page a living owner.

What to Measure After Launch

Decide these four numbers before go-live, because measuring them afterwards against no baseline tells you nothing.

Monthly unique visitors as a share of headcount, which is the headline and the only figure worth reporting upward. Inbound policy questions per week, counted the same way before and after, because a site that works should move this and a site that does not will not. Share of questions arriving by direct message rather than through an official route, which tells you whether behaviour actually changed or people simply have a new place to ignore. And the proportion of pages whose last-reviewed date is within your stated cadence, which is the leading indicator of decay and the one that predicts whether this still works in a year.

Report them monthly for the first quarter and quarterly after that. If visitors rise but inbound questions do not fall, people are browsing rather than self-serving, which usually means the pages are findable but not actually answering. That is a content problem and it is fixable. If neither number moves, you have the destination problem described at the top of this article, and the correct response is to stop investing in the destination rather than to try a different design.

Two metrics are worth deliberately not reporting, because both flatter the project while telling you nothing. Page views, which rise whenever somebody clicks through three pages looking for one answer, so a confusing site can outperform a clear one. And time on page, which is ambiguous in both directions: a long visit might mean careful reading or might mean somebody hunting through a wall of text for a single sentence. Neither number distinguishes a satisfied reader from a lost one, and both get quoted in steering meetings precisely because they tend to go up.

The number that would settle it, whether the person got their answer, is the one none of these tools capture. The closest practical substitute is to ask. Four questions in a quarterly pulse survey, aimed at whether people know where policies live and whether they found what they needed last time they looked, will tell you more than a year of analytics. It is also the only measurement in this list that surfaces the vocabulary problem, because people will tell you in their own words what they went looking for and could not find.

What Getting This Wrong Costs

The direct cost is the licence and four months of somebody's attention. The real cost is the conclusion people draw afterwards.

A redesigned HR intranet that does not move the numbers teaches the organisation that this problem is not solvable. The next person to propose anything in this area inherits that history, and the budget conversation starts from a failure. That is a meaningful cost and it is entirely avoidable by measuring traffic share before committing, because the measurement tells you in an afternoon whether a destination is the right shape at all.

The other failure costs less money and more trust. Delivery deployed on top of stale content answers hundreds of people confidently and wrongly, in private conversations nobody is reading. A shared inbox at least produces a visible pile that somebody eventually notices. Private wrong answers produce no pile and surface weeks later, usually through a complaint.

So the question worth asking is not which HR intranet is best. It is whether your people have already voted on whether to travel, and whether you are willing to believe the number when you look at it.

When You're Ready to Move Beyond a Shared Drive

If your traffic share is healthy, spend on the destination. Add last-reviewed dates, name an owner per section, and run the vocabulary test above against your real questions. That work is cheap, unglamorous and reliably effective.

If your traffic share is poor and your content is correct, stop improving the destination. The decision has already been made by the people you are building for, and a third redesign will confirm it rather than reverse it. Add delivery where your people already are.

And if your content is not correct, do nothing else first. Both shapes amplify whatever they are given. One does it slowly and visibly, the other quickly and privately, and neither is a reason to skip the editing.

Frequently Asked Questions