The Modern Intranet: What It Should Actually Do

Somewhere in your company's past there is probably a dead intranet. Maybe two. A SharePoint site with a photo of the old office on the homepage. A branded portal — "The Hub," "Compass," "OneCompany" — that cost six figures, launched with a naming contest, and was quietly abandoned eighteen months later. The pattern is so common it is practically a rite of passage.

And yet the need never went away. Every company past about thirty people rediscovers the same set of problems: nobody knows where the policies live, nobody knows what other teams are doing, new hires spend their first month asking questions that have been answered fifty times, and company news travels by rumor faster than by any official channel. Those problems are exactly what an intranet is supposed to solve. The failure is not the idea. It is what we kept building.

This guide covers why three decades of intranets failed, what employees actually need from one — expressed as concrete jobs, not features — and how to assemble a modern version around three layers: social, knowledge, and tools. It ends with governance and rollout, because the graveyard is full of intranets that launched well and rotted quietly.

A short history of failure

It helps to know the pattern you are trying to escape, because each era failed differently and modern buyers tend to repeat exactly one of these mistakes.

Era one: the digital notice board (mid-1990s to mid-2000s)

The first intranets were static internal websites: HR policies, cafeteria menus, a message from the CEO with a JPEG signature. Built by IT, updated by nobody. The core assumption was that an intranet is a publication — the company talks, employees read. Readership collapsed within months because the content was stale and there was no reason to return. The lasting lesson: a destination without a daily reason to visit is a destination nobody visits.

Era two: the portal and the document dump (2000s to mid-2010s)

Then came the enterprise portal era — SharePoint above all. The intranet became a document management system wearing a homepage. Every department got a "site," every site got a folder tree, and within two years there were 40,000 documents, eleven versions of the travel policy, and a search box that returned all of them. Governance was pushed to departments, which meant governance did not happen. The lasting lesson: storage is not findability. A system where putting things in is easy and getting things out is hard fails at the only part that matters.

Era three: the social enterprise (2010s)

Yammer, Jive, Chatter, and eventually Workplace from Meta bet the other way: the intranet as internal Facebook. This era got something genuinely right — two-way communication, comments, an activity stream that gave people a reason to return. But most deployments failed on a different reef: the social layer floated free of actual work. You could like the CEO's post, but your tasks, documents, and team's status lived elsewhere, so the network became a place you also had to check rather than a place work happened. Engagement concentrated in a vocal 10% while everyone else lurked or left. Workplace's shutdown announcement in 2024 was the era's formal obituary. The lasting lesson: social features without work attached become a ghost town with reactions.

The common thread

All three eras made the same underlying mistake in different costumes: they built the intranet as a separate place — separate from where work happens, owned by a function (IT, comms, HR) rather than used by everyone, filled top-down rather than by daily activity. Employees visit places where their work lives. Everything else requires willpower, and willpower loses to Slack.

What employees actually need: seven jobs

Strip away vendor categories and ask what people actually hire an intranet to do. In practice it is seven jobs. A useful exercise: score your current setup 1–5 on each before reading further.

#	Job	The question it answers
1	Find authoritative answers	"What is the actual parental leave policy — the current one?"
2	Know what is happening	"What changed this week that affects me?"
3	Find and understand people	"Who owns billing? Who is this person in my meeting? Who reports to whom?"
4	Get oriented as a newcomer	"Where is everything, and how do things work here?"
5	Do routine tasks	"How do I request time off / book travel / report an issue?"
6	Ask and be answered	"Nobody wrote this down — who can tell me, in a way the next person can find?"
7	Feel part of something	"Do I know my colleagues as people? Does anyone see my work?"

Two observations about this list.

First, jobs 1–5 are utility and jobs 6–7 are community, and you need both. Utility without community is era two: a filing cabinet people visit under duress. Community without utility is era three: a party in a building where no one works. The intranets that survive are the ones where checking company news and looking up the expense policy and congratulating a teammate happen in the same place, so each visit reinforces the others.

Second, job 3 is the most underrated. People-finding — a real directory with photos, roles, org structure, and what someone is working on — is consistently among the top intranet uses in every study of employee behavior, and it is the feature buyers spec last. In a remote or hybrid company, the directory and org chart are not nice-to-haves; they are the only way a new hire ever builds a mental map of the organization.

The three layers of a modern intranet

A modern intranet is not one thing. It is three layers that share a roof — one login, one search, one navigation.

Layer 1: Social — the reason to come back daily

The social layer is the feed: announcements, wins, questions, polls, event invites, kudos, the occasional dog photo. Its structural role is frequency. Policies change quarterly; the feed changes hourly. It is the layer that builds the visiting habit that the other two layers depend on.

What a working social layer needs:

• A single company feed for announcements and cross-team news, with pinning so important items do not scroll away, and post types beyond text — polls for quick input, events with RSVP, structured announcements that render differently from casual posts.
• Two-way by default. Comments and reactions on, including on leadership posts. An announcement with zero visible questions did not achieve consensus; it achieved silence. (More on making that two-way culture real: Giving Employees a Voice.)
• Group spaces for communities that are not org-chart teams: ERGs, office locations, hobby clubs, guilds. These are where jobs 6 and 7 quietly get done, and they need their own membership and feeds rather than one giant channel.
• Recognition built in. Kudos posts with real reach do more for culture than any quarterly award. The mechanism matters less than the visibility — recognition that only the recipient sees is a private email, not a cultural signal.
• Sidebar ambience: birthdays, work anniversaries, upcoming events, trending posts. Trivial-sounding, disproportionately effective at making a digital place feel inhabited.

The classic failure here is executive absence. If leadership never posts, never comments, and communicates important things by email instead, employees correctly conclude the feed is unofficial and stop treating it as a source of truth. The social layer requires the most senior people to actually live in it — a two-posts-a-month commitment from the CEO is worth more than any launch campaign.

Layer 2: Knowledge — the reason it is trustworthy

The knowledge layer is where durable content lives: the handbook, policies, how-tos, team documentation, and — critically — answered questions.

What it needs:

• A clear line between the authoritative and the working. Policies and handbook content belong in a maintained wiki with named owners. Team notes and drafts belong in team doc areas. Blurring these — era two's sin — is how you end up with eleven travel policies. One practical convention: anything in the handbook space is company truth and has an owner; anything elsewhere is working material.
• Owned pages with review dates. Every authoritative page lists an owner and gets a lightweight review cycle (every 6–12 months, tracked). Staleness is the leading cause of intranet death; a page that is wrong once teaches the reader to never trust the intranet again. The full maintenance playbook is a topic of its own — see the knowledge management guide.
• A Q&A surface. This is the modern layer's biggest upgrade over every prior era. A Stack Overflow-style internal Q&A — questions, answers, votes, an accepted answer — converts the constant stream of "quick question" DMs into a searchable, self-ranking knowledge base. It captures exactly the knowledge nobody would ever sit down to document, in the exact phrasing people actually search for. Teams that add this layer routinely find it outperforms the formal wiki for day-to-day answers.
• Search across everything. One search box covering the feed, the wiki, docs, Q&A, and people. This is the property that dies first when the intranet is stitched from four vendors, and it is the property employees rate as most important. If searching requires knowing which silo to search, jobs 1 and 6 fail no matter how good the content is.

Layer 3: Tools — the reason it is where work lives

This is the layer previous eras skipped, and its absence is why they died. If the intranet is only news and documents, it is a place you visit weekly out of duty. If it is also where you request time off, check the team's project board, answer your async standup, and see the quarterly dashboard, it is a place you inhabit.

You do not need every work tool inside the intranet. You need the shared-surface ones — the tools whose whole point is cross-team visibility:

• Time off: requests, approvals, and a who's-out view. The single most-used transactional feature of any intranet, because everyone takes vacation.
• Events: company calendar, RSVPs, event discussion.
• Status and dashboards: project status pages and reporting dashboards that give any employee a legible view of what other teams are doing — the honest answer to job 2 that no newsletter can provide.
• Check-ins and pulses: async standups and mood pulses, which double as the upward-signal channel leadership always says it wants.
• Links out to everything else, done properly: a maintained launcher for the payroll system, the CRM, the code host. The intranet does not replace deep specialist tools; it federates access to them.

The composition question — which tools live inside versus link out — is where platform architecture matters. Monolithic intranet products give you their fixed feature set; suite-of-tools approaches give you the four-vendor search problem. The composable middle is the current best answer: a platform where you assemble the intranet from modules. This is the model Openbook is built on — a company space composed from rooms, so your intranet might be a Feed room, a Wiki room, a Q&A room, an Events room, and a Time Off room, with the people directory and org chart built in and one search over all of it. The point generalizes beyond any one product: choose an architecture where adding a capability does not mean adding a silo.

Build, buy, or compose: the architecture decision

Before governance and rollout, you have to pick a construction method. There are four, and the tradeoffs are real in every direction:

Approach	What it looks like	Where it wins	Where it fails
Build in-house	Custom internal site on your web stack	Total control; matches your brand and workflows exactly	Becomes an unfunded product; dies at the first reorg of the team that built it
Buy a monolith	Classic intranet suite (portal products, SharePoint + overlay vendors)	One vendor, one contract; strong publishing and governance features	Fixed feature set; the tools layer is usually weak, so work still lives elsewhere
Stitch a stack	Chat + wiki tool + HRIS + survey tool + newsletter tool	Each piece is best-of-breed	Four logins, four searches, no shared directory; jobs 1 and 6 quietly fail; integration maintenance becomes a standing tax
Compose on a platform	Modular workspace where you assemble feed, wiki, Q&A, events, time off as rooms in one space	One search and directory across everything; add capabilities without adding silos	You accept the platform's modules instead of hand-picking each category's leader

A few honest notes on choosing. Building in-house is almost always wrong below a thousand employees — not because the build is hard, but because the maintenance is a product team's job and no one budgets for it. Buying a monolith makes sense when your intranet needs are publishing-heavy and your work tools are settled and untouchable. Stitching a stack is where most companies land by accident rather than decision, and its costs are invisible until you tally them: every silo boundary is a place where search fails, a login that deters a casual visit, and an integration that breaks on somebody's API change. (The full accounting is its own article — see what SaaS sprawl really costs.)

Composing on a platform is the newest option and the one this guide's three-layer model fits most naturally, because the layers stay unified where it matters — search, directory, permissions, notifications — while remaining modular where you need choice. The practical test when evaluating any option: walk through the seven jobs and ask, for each, "how many logins, and how many search boxes?" The right architecture answers "one and one" to at least six of them.

Governance: the boring layer that decides everything

Every failed intranet had a launch party. What none of them had was an operating model. Four roles, none full-time below ~500 employees:

1. An overall owner (comms lead, chief of staff, or people ops) who curates the feed's quality, runs the metrics review, and owns the "where things go" map. Budget half a day a week.
2. Page owners for every authoritative knowledge page, enforced by convention: no owner, no page in the handbook space.
3. Community moderators for group spaces — usually the groups' own organizers, with a two-paragraph moderation norm rather than a policy binder.
4. An executive sponsor whose actual job is to use the thing visibly — post monthly, comment weekly, answer questions in public. Sponsorship-by-usage, not sponsorship-by-budget-approval.

Add two standing rituals: a quarterly content audit (sample 20 authoritative pages, check freshness, chase owners of stale ones) and a quarterly metrics review. That is the entire governance system. It fits on one page, and it is more than eras one through three ever had.

Measuring whether it is working

Vanity metric to ignore: total page views, which mostly measure company size. Measure against the seven jobs instead:

• Habit: weekly active users as a percentage of headcount. A healthy modern intranet in a desk-based company reaches 60–80% weekly. Below 40%, the social layer is failing.
• Findability: in your quarterly pulse, "I can find the information I need to do my job" (tracked), plus top failed searches from search logs — a free, precise to-do list for the knowledge layer.
• Two-way health: percentage of employees who posted, commented, or reacted in the past month (target: well over half — lurker-only cultures decay), and average comments on leadership posts.
• Question capture: Q&A questions asked per month, and percentage with an accepted answer. Rising ask-rates are good news — they mean questions are moving from DMs into shared memory.
• New-hire orientation: ask every 30-day hire to rate "I know where to find things" and name what they could not find. Feed the misses straight into the content backlog.

Rolling it out without a naming contest

A modern intranet launch should be almost boring. The pattern that works:

Weeks 1–2 — seed before you show. An empty intranet at launch is a self-fulfilling failure. Pre-populate: the 20 most-asked policies in the wiki, the org chart and directory complete with photos, three weeks of feed history (backfill real announcements), 15–20 seeded Q&A pairs harvested from what people actually ask in chat.

Weeks 2–3 — pilot with one department plus leadership. Fix the friction they find. Get the executive sponsor posting during the pilot so launch-day visitors see a lived-in space.

Week 4 — launch by redirection, not proclamation. The launch is not an email about the intranet; it is the next three real announcements happening there, with chat channels carrying only a link. Move one high-frequency utility (time-off requests are ideal) to the platform in the same week, so every employee has a transactional reason to log in within a month.

Weeks 5–12 — deprecate the alternatives. This is the step everyone skips and the reason old channels linger for years. Archive the old wiki with redirect notes. Retire the announcement email list with a final pointer. Every surviving duplicate channel taxes the new system's habit formation.

Expect the dip: engagement spikes at launch, sags around week six, then either climbs (if the feed has real news and the tools layer has real utility) or slides into ghost town. The week-six sag is where the executive sponsor and the overall owner earn their titles — it is the moment to ship a wanted feature, run a poll that leadership visibly acts on, and hold the cadence.

The test that matters

Here is the one-question evaluation for any intranet, existing or proposed: If it disappeared on Friday, who would notice by Monday morning?

Era-one and era-two intranets fail this test — someone would notice at the end of the month when they needed a policy. Era-three intranets fail it socially — the lurkers would not notice at all. A modern intranet passes it because Monday morning is when someone needs to request PTO, check the on-call handoff, read the weekend's incident post, answer their async check-in, and look up the person joining their 10 a.m. call.

Practical next steps: score your current setup against the seven jobs this week. Interview three recent hires about what they could not find. Then decide whether your gaps are content problems (fixable in place) or architecture problems (silos with no shared search — fixable only by consolidation). If it is the latter, and you want to see what the composable version looks like, you can assemble a full intranet — feed, wiki, Q&A, events, time off, directory — in an Openbook space in an afternoon, free, at openbook.work. Seed it before you show it.