Most SharePoint intranet projects are declared successful at go-live and quietly abandoned within eighteen months. The launch event draws a crowd, the executive video gets posted, and the IT team closes the project ticket. Then, gradually, people stop going. They find the page they need once, bookmark it, and never navigate through the intranet again. Search returns stale results. The HR department updates their SharePoint page but nobody reads it because nobody knew where to look in the first place. By month twelve, the platform has become a digital filing cabinet that everyone avoids and nobody wants to be responsible for. The problem is almost never the technology. SharePoint, as part of Microsoft 365, is a capable and increasingly sophisticated platform. The problem is architecture — specifically, architecture designed for the organization’s convenience rather than the employee’s workflow.

Why most intranets fail before they launch

The dominant failure pattern in mid-market intranet projects is what we call org-chart architecture. The site structure mirrors the company’s reporting hierarchy: a top-level hub for the company, sub-sites for each department, sub-sub-sites for each team, pages organized by business unit ownership. This structure makes perfect sense to the project steering committee, which is composed entirely of department heads. It makes no sense to an employee who needs to submit an expense report and does not know — or care — whether that process is owned by Finance, HR, or Operations.

Org-chart architecture treats the intranet as a document repository sorted by who created the content. Task-based architecture treats it as a tool sorted by what employees are trying to accomplish. The distinction sounds simple. In practice, making the shift requires overcoming significant political resistance, because task-based architecture means that a Finance page might live inside an “Onboarding” section rather than under the Finance hub, which department heads often experience as a loss of visibility and control.

A secondary failure pattern is scope collapse under governance pressure. Organizations start with ambitions to replace email newsletters, consolidate multiple legacy intranets, and centralize policy documentation. Steering committees add requirements. IT adds security constraints. Legal adds compliance requirements. By the time the project launches, the intranet is a comprehensive system that solves every stakeholder’s problem except the employee’s.

The hub site model: structural foundation for adoption

SharePoint’s hub site architecture, introduced with Microsoft 365, provides the right structural model for mid-market organizations — but only when implemented with clear governance decisions made upfront.

The recommended architecture for organizations between 100 and 2,000 employees is a three-tier model:

• Corporate hub site: The employee homepage. Owns global navigation, company-wide news, enterprise search configuration, and cross-organizational content such as the employee directory, company policies, and the IT help desk. Governed by a central communications or IT team with a defined publishing workflow.
• Departmental communication sites: Associated with the corporate hub but independently managed by each department. HR, Finance, Operations, Sales, and similar functions maintain their own sites with content relevant to their function. These sites inherit the hub’s navigation theme and search scope but are not sub-sites — they are independent sites connected to the hub via association.
• Project and team sites: Microsoft Teams-connected SharePoint sites for active collaboration. These are not part of the intranet navigation. They exist for working documents, not published content. The boundary between collaboration sites and communication sites is a governance line, not a technical one, and it must be enforced deliberately.

The hub association model matters because it solves the central tension in every intranet project: central teams want consistency and governance control; departments want autonomy and the ability to publish without a bottleneck. Hub sites provide both. The corporate team controls global navigation and the hub homepage. Departments control their own communication sites. Search aggregates content across all associated sites automatically.

Navigation design: building from tasks, not titles

Global navigation in a hub site should be organized around the four to six tasks that employees perform most frequently across the organization. In most mid-market companies, these resolve to a predictable set: find a policy or form, complete an HR process, submit an IT request, find a person or team, access a business application, and read company news. Everything else is secondary navigation, accessible from department sites rather than the global menu.

The practical process for task-based navigation design involves three steps that many projects skip entirely:

1. Task inventory: Survey a cross-functional sample of employees — ideally 15 to 25 people representing different roles, tenure levels, and locations — and ask them to list the five things they most commonly need to find or do at work. Analyze the results for frequency and convergence. The top tasks will be obvious; there will typically be six to ten items that appear in more than 60 percent of responses.
2. Navigation card sort: Present those top tasks to a separate group of employees and ask them to sort the tasks into groups they find logical, then name the groups. This is a standard UX technique, and it consistently produces navigation labels that employees understand and that department heads would never have chosen on their own. “Getting things done” is a more intuitive label than “Employee Self-Service.”
3. Treejack testing: Before building the full information architecture, test the proposed navigation structure by asking employees to find specific items using only the menu labels, with no visual design. This catches navigation dead-ends before they are built into the platform.

Most intranet projects allocate zero time to these three steps and then spend the post-launch period trying to understand why adoption is low. The research is not expensive or time-consuming — a task inventory and card sort for a 500-person organization can be completed in two weeks — but it requires the project team to accept that employee intuition, not stakeholder preference, should determine navigation structure.

Content lifecycle management: the discipline that prevents decay

An intranet with no content lifecycle policy will have visibly outdated content within six months of launch. Outdated content — a policy page that references a process changed a year ago, a contact page with a departed employee’s name, a form that links to a decommissioned system — destroys employee trust in the platform faster than any UX problem. Once employees learn that they cannot trust what they find on the intranet, they stop looking.

A functional content lifecycle framework for a mid-market SharePoint intranet includes four components:

• Content ownership assignment: Every published page has a named owner — a specific individual, not a team or department — who is responsible for accuracy. Ownership is recorded as a managed metadata column on every page and is visible to site administrators.
• Review schedules enforced by SharePoint: SharePoint’s page scheduling and expiry features, combined with Power Automate flows, can automatically flag pages for review based on a defined schedule. Policy pages should be reviewed annually. Process guides every six months. News and announcements expire automatically after 90 days unless manually extended.
• Quarterly content audits: The central communications or IT team runs a quarterly audit of all hub site content, identifying pages that have not been updated within their scheduled review window and escalating to page owners. In our experience, the first quarterly audit after launch typically surfaces content issues on 20 to 40 percent of pages.
• Retirement protocol: A defined process for archiving or deleting pages that are no longer relevant. Content that is retired but potentially needed for compliance should be moved to a records management library, not deleted. Content that is simply outdated should be removed from navigation and marked for deletion after a defined holding period.

Search configuration: making the platform trustworthy

SharePoint search works out of the box for finding documents by filename. It does not work particularly well for the way employees actually search — by concept, process name, acronym, or the name of the thing they are trying to do rather than the name of the document that describes it.

Before an intranet goes live, the following search configuration steps should be completed as part of the build, not treated as post-launch enhancements:

The promoted results configuration deserves particular attention. Identify the 20 search terms employees use most frequently — these can be gathered from the task inventory or, if a legacy intranet exists, from its search logs — and create promoted results that surface the correct page for each term. Review and update the promoted results list quarterly as search analytics accumulate.

The launch sequence that builds habits

Most intranet launches are awareness campaigns. They generate a spike in traffic on launch day that decays to baseline within three weeks. Habit-building requires a different approach: a 90-day sequence designed to create repeated, successful experiences with the platform rather than a single high-profile introduction.

The sequence that produces durable adoption in mid-market organizations typically follows this structure:

• Pre-launch (weeks minus-four to zero): Identify and train 15 to 30 intranet champions — typically team leads and department administrators — who will be the first line of support for their colleagues. Champions should have hands-on access to the platform before the general launch and should understand both the navigation structure and the content ownership model. They are not advocates; they are competent users who can answer practical questions.
• Launch week: Communicate the intranet’s existence with a single, specific message about what employees can now find or do that they could not do before. Avoid comprehensive feature tours. Focus on one or two high-value tasks — finding a policy, booking a room, accessing the employee directory — and make those tasks the center of the launch communication.
• Weeks two through four: Publish content that requires employees to visit the intranet to access information they actually need. This means routing at least some operational communications — policy updates, process changes, organizational announcements — exclusively through the intranet rather than email. The goal is to create situations where going to the intranet is the path of least resistance.
• Month two: Publish search analytics and page traffic data to the intranet steering committee. Identify the pages with high traffic and low engagement time (content is not meeting expectations), pages that are frequently abandoned without a click (navigation is failing), and search terms with no results (content gaps). Address the top five issues in each category before month three.
• Month three: Conduct a structured feedback session with a cross-functional group of employees — not champions, but regular users. Ask two questions: what do you use the intranet for regularly, and what do you still find it easier to do some other way? The answers to the second question define the next phase of development priorities.

Frequently asked questions

How many hub sites should a mid-market organization have?

Most organizations between 100 and 500 employees need exactly one hub site — the corporate hub. Organizations between 500 and 2,000 employees may benefit from a second hub for a distinct business unit or geographic region, but this should be driven by genuine operational separation, not political desire for visibility. Multiple hubs increase governance complexity significantly. In our experience, the organizations that create multiple hubs too early spend more time managing hub governance than improving intranet content, and adoption suffers as a result. Start with one hub and add more only when the governance model for the first is stable and well-understood.

Should the intranet replace email for internal communications?

Partially, and with care. The intranet should replace email for persistent, reference-type communications: policy updates, process documentation, organizational announcements that employees will need to find again. It should not replace email for time-sensitive communications that require action, because employees reliably check email and do not reliably check the intranet — especially in the first year. The transition is gradual: as intranet usage habits develop, more communication types can migrate to the platform. Attempting a hard cutover from email to intranet on launch day is a reliable way to generate employee hostility toward the platform.

What is the right governance model for departmental content ownership?

Each departmental communication site should have a designated site owner — a specific individual, not a role title — who is accountable for content quality on that site. That owner should have the authority to approve and publish content without routing through a central communications team for every update. Central governance should set standards — content templates, review schedules, metadata requirements — and enforce them through quarterly audits rather than approval workflows. Approval workflows for routine departmental content create bottlenecks that department heads eventually route around by publishing directly without review, which is worse than no governance at all.

How do we handle legacy content from a previous intranet?

Do not migrate legacy content automatically. Legacy content migration is one of the most common sources of intranet quality problems — organizations migrate thousands of pages of outdated documentation and then spend years trying to clean it up. Instead, conduct a content audit before migration: identify which content is still accurate, still needed, and will be actively maintained. Migrate only that content. Everything else should be archived in a compliance library or deleted. In most mid-market organizations, a rigorous pre-migration audit reduces the migration scope by 40 to 60 percent, which significantly reduces the launch build effort and the ongoing governance burden.

How long does it take for a SharePoint intranet to reach stable adoption?

In our experience with mid-market deployments, meaningful adoption — defined as a majority of employees using the intranet at least once per week without being prompted — typically takes nine to twelve months from launch when the 90-day habit-building sequence is executed well. Organizations that treat the launch as the finish line rather than the starting line typically see adoption plateau at 20 to 30 percent of employees within the first year and require a significant rebuild effort within three years. The investment in the 90-day post-launch sequence is modest compared to the cost of a rebuild.

SharePoint Intranet Design: The Architecture That People Actually Adopt

Most senior operations directors and IT leaders have watched at least one intranet project deliver a technically complete platform that employees stop using within a year. This post offers the architectural and governance framework that produces intranets people actually adopt — and continue to use.