What are common intranet implementation mistakes to avoid?

Most failed intranets weren't failed by the platform. They were failed by the implementation, usually in ways that were entirely avoidable and, in hindsight, obvious. A company picks a genuinely capable tool, rushes through the setup, skips a few steps that felt optional at the time, and ends up with the exact scattered, untrustworthy mess the intranet was supposed to fix in the first place.

The good news is that these mistakes follow a fairly predictable pattern, which means they're avoidable if someone knows to look for them in advance. Here's where implementations most commonly go wrong, and what tends to prevent it.

Treating launch day as the finish line

The most common mistake isn't a bad decision made during setup. It's the absence of any plan for what happens after the platform goes live. A project team pours weeks into structure, content, and training, gets everyone logged in on launch day, and then quietly stops paying attention, assuming the hard part is over.

It isn't. An intranet that launches well and then has nobody responsible for it afterward decays at roughly the same rate as any unmaintained shared drive or wiki. Pages go stale, ownership becomes ambiguous, and within a year the platform looks a lot like the scattered mess it replaced, just with a nicer interface.

The fix is straightforward but easy to skip under launch-week pressure: decide, before going live, who owns ongoing maintenance, how often content gets reviewed, and how the company will know if the platform is actually working. Treating launch as the beginning of the real work, rather than the culmination of it, is the single biggest predictor of whether an intranet is still relevant in two years.

Migrating everything instead of curating

Faced with years of accumulated documents, emails, and files, the instinctive move is to migrate as much of it as possible into the new intranet, on the theory that more information is better than less. This is almost always the wrong call. Dumping years of undifferentiated content into a new platform just relocates the same clutter into a nicer-looking container, and it buries the handful of pages that actually matter under a pile of outdated material nobody will ever open again.

A more disciplined approach treats migration as an editorial decision, not a technical one. Before anything gets moved, someone should be asking whether a given document is still accurate, still relevant, and still needed, rather than assuming its existence justifies its inclusion. Content that fails that test should be archived or deleted, not carried forward out of habit. A smaller, curated intranet that people trust beats a comprehensive one nobody can navigate.

Structuring around the org chart instead of how employees actually think

This is one of the more subtle mistakes, and one of the most damaging, because it feels like the obvious, sensible way to organize an intranet. Structuring content by department, mirroring how the company is drawn on an org chart, seems logical from the inside. It rarely works from the outside, because employees don't experience their jobs that way.

Visma, which grows through acquisition and now spans more than 160 companies, ran directly into this problem. Their internal communications specialist, Mandy Burger, who led the effort to rebuild the company's fragmented intranet, described the core insight plainly: employees don't think in org charts. Nobody starts their workday needing to navigate the legal department's structure. They need to get something approved, and the difference between those two framings turned out to be the entire problem. Visma's environment had accumulated more than 28 separate, team-owned page groups, each organized according to that team's own internal logic, and employees responded by routing around the system entirely, asking a manager directly because it felt faster than searching. As Burger put it after diagnosing the issue, this wasn't a content problem. It was an architecture problem.

The fix that Visma landed on, collapsing team-based categories into pages organized around what an employee is actually trying to accomplish, is a useful model for any company setting up an intranet for the first time. Structure around tasks and intent, not around whichever team happens to own a given piece of content.

Skipping the pilot and building on assumptions instead of feedback

A common shortcut is designing the entire intranet structure internally, based on what the project team assumes employees need, and only asking for feedback after the full platform has launched. By that point, structural changes are far more disruptive than they would have been earlier, and a lot of avoidable friction has already been baked in.

Burger's own retrospective on the Visma project named this directly as one of the things she'd do differently if starting over: lead with user feedback, not internal assumptions. The people already using the existing system, however broken, generally know exactly where it breaks down and what would actually help, and that input is far more useful gathered before the structure is finalized than after. A short pilot with a small group of real employees, ideally including newer hires who haven't yet developed workarounds for a broken system, tends to surface problems a project team would never think to ask about on its own.

Rolling out without a clear leadership mandate

An intranet rollout that leadership treats as a background IT project, rather than something they actively and visibly support, tends to struggle for adoption regardless of how well it's built. Employees take cues from what leadership seems to care about, and a platform that launches with a quiet email rather than a clear message from the top reads as optional, even when it isn't meant to.

This was another point Burger flagged specifically from the Visma project: get leadership mandate early, not partway through. Restructuring how a company organizes its knowledge is a meaningful ask, and it's a much easier one to make when leadership has already explained why it matters and how it connects to broader business goals, rather than leaving a project team to make that case alone after the fact. Waiting until adoption numbers look weak to bring leadership in tends to mean a much harder recovery than securing that support before the first page goes live.

Overbuilding the structure before anyone's used it

There's a natural instinct, especially among teams that have felt the pain of a disorganized system, to build the most comprehensive, deeply categorized structure possible right from the start, anticipating every future need in advance. This usually backfires. An intranet that's too complex for a new employee to understand within a few minutes of looking at it will struggle regardless of how thoughtfully it was designed, because complexity that isn't yet justified by actual content or actual usage just adds friction nobody asked for.

The third lesson from Visma's retrospective addresses this directly: keep the structure simple enough that a new employee can understand and navigate it within minutes, and resist the urge to replace an old, messy system with a new, differently complicated one. Structure should grow in response to real usage patterns, not get front-loaded based on guesses about what might eventually be needed.

Never deciding how success will be measured

A surprising number of intranet implementations launch without anyone deciding, in advance, what "working" actually means or how it will be tracked. Without that decision, a company has no real way to know whether the platform is succeeding or quietly failing, and problems tend to go unnoticed until they're serious enough to be obvious without any data at all.

This mirrors a broader pattern documented well beyond any single company. GitBook's 2026 State of Docs survey found that nearly half of organizations surveyed weren't tracking any internal documentation metrics at all, which means the majority of companies have no real signal for whether their knowledge systems are helping or simply accumulating. Deciding upfront to track something as simple as page age, last review date, or how often specific content actually gets opened gives an implementation team an early warning system that most companies never bother to build, and it turns "is this working" from a guess into something that can actually be checked.

Where Happeo can help

Several of these mistakes are structural, and the right platform can help avoid them by design rather than relying on a project team to catch every risk manually. Happeo's Pages and Channels structure gives companies a built-in answer to the org-chart trap, organizing content around how long information needs to matter rather than which department happens to own it. Automated content health tools flag pages that have gone stale or lost a clear owner, directly addressing the measurement gap that sinks so many implementations that never decide how to track success. And because ownership can be assigned to specific pages and spaces from the start, the platform makes "who owns this after launch" a decision made upfront rather than an afterthought nobody gets around to.

A partner in avoiding these mistakes, not just a platform

Knowing these mistakes exist in the abstract is different from catching them in the middle of your own rollout, when deadlines are tight and it's genuinely hard to see your own project as clearly as an outside pair of eyes could. This is where Happeo's role goes beyond providing the software itself.

Having guided implementations across a wide range of company sizes and starting points, Happeo has seen most of these mistakes play out in real projects, and the dedicated deployment consultant assigned to each implementation is there specifically to catch them before they happen, not just to configure the technical setup. That means flagging when a migration plan is trying to move too much content forward, when a proposed structure is mirroring an org chart instead of employee intent, or when a rollout is missing the leadership visibility it needs to land well. Happeo's implementation process, including a structured pilot phase built into the standard rollout, exists specifically because skipping that step is one of the most common and most avoidable mistakes companies make on their own.

That's a meaningfully different relationship than simply buying a license and being left to work out the implementation independently. A successful rollout is a better outcome for everyone involved, and helping a company avoid its own predictable mistakes is treated as part of the job, not an extra.

Learning from mistakes that don't have to be yours

The companies that implement an intranet well aren't necessarily the ones with the most experience doing it, since most companies only go through this once. They're the ones willing to learn from mistakes other companies have already made, rather than discovering each one the hard way through their own failed rollout. None of the mistakes above are exotic or hard to understand once named. They're just easy to miss in the middle of a project, which is exactly why naming them in advance matters.

Frequently asked questions

What's the single most common intranet implementation mistake?
Treating the launch date as the finish line rather than the beginning of ongoing work. Platforms that launch well but have no plan for ownership, review, or measurement afterward tend to decay within a year, ending up as disorganized as whatever they replaced.

Should a company migrate all its existing documentation into a new intranet?
No. Migrating everything just relocates old clutter into a new container and buries the content that actually matters. A more disciplined approach evaluates each document for accuracy and relevance before deciding whether it's worth carrying forward, resulting in a smaller, more trustworthy intranet.

Why does organizing an intranet by department usually fail?
Because employees don't experience their work in terms of org charts. They think in terms of tasks: getting something approved, finding a policy, completing a process. Structuring content around departments instead of what employees are actually trying to do tends to produce exactly the kind of scattered, hard-to-navigate system an intranet is meant to fix.

Is it necessary to run a pilot before a full company-wide launch?
Strongly recommended. Structural problems are far easier and less disruptive to fix before a platform is fully rolled out than after. A pilot with a small group of real employees, especially newer hires without existing workarounds, tends to surface issues a project team would never think to check for on its own.

How do you know if an intranet implementation is actually succeeding after launch? Only if success was defined and tracked from the start. Simple metrics like page age, last review date, and actual usage give a company an early signal of whether the platform is staying useful, rather than waiting until problems are obvious enough to notice without any data at all.