Table of Content
A strategic guide for CIOs, Heads of IT, HR, and Internal Comms on building a governed, AI-ready intranet on Microsoft 365
Before we start — this article won’t walk you through how to technically build an intranet. Microsoft has excellent resources and templates for that, and we’d recommend starting with the SharePoint intranet planning guide on Microsoft Learn.
What we want to do here is different. We want to show you why so many intranets end up as a liability rather than an asset — and how to plan and build yours in a way that doesn’t repeat those mistakes. This comes directly from our experience working with organisations across industries, auditing existing intranets, and helping teams build new ones on Microsoft 365.
Why Most Intranets Fail
Whenever we audit an existing intranet, we come across the same three challenges consistently — regardless of platform, organisation size, or industry. We want to help you understand them before choosing or configuring any technology, because this is the most important first step.
Challenge 1: Built once, never governed
The intranet launches with a strong structure, well-written content, and enthusiastic adoption. Six months later, the first batch of stale pages appears. A year in, there are duplicate policy pages, broken links, and sections nobody has touched since go-live. The platform isn’t the problem — the absence of a content lifecycle process is.
We see this in almost every organisation we work with. The build gets investment and attention. The governance doesn’t.
Challenge 2: No ownership model
Every intranet needs someone accountable — not for the platform, but for each section of the content. When ownership is ambiguous, content becomes everyone’s responsibility and therefore nobody’s. IT keeps the lights on. Communications publishes announcements. But nobody’s asking the question that matters: is this section still accurate, and does it still belong here?
The pattern we see most often is an intranet where IT owns the technology but business units own the content — and neither side has a clear picture of what the other is responsible for. The result is a slow accumulation of content that nobody has the authority to remove.
Challenge 3: Built for IT, not for employees
The navigation reflects how IT organises data, not how employees think about their work. Labels are department names rather than task-oriented ones. Search returns too many results with too little context. The intranet becomes a place people visit only when forced to — for the expense form, the IT helpdesk link, the mandatory training.
We’ve seen intranets with beautifully designed homepages that employees describe as “fine, but I can never find anything.” The structure made sense to the team that built it. It didn’t make sense to the people using it.
You’re probably in one of three situations right now:
- No intranet yet — you have the opportunity to build it right from the start, without migration debt or legacy habits
- A legacy or third-party intranet — your existing platform is either end-of-life, under-governed, or disconnected from the rest of your Microsoft 365 investment
- SharePoint already in place but ungoverned — you have the platform and the content, but the governance model was never designed and the accumulated debt is now visible
In all three cases, the path forward is the same. Governance first, then build.
Why SharePoint Is the Right Platform
The strategic case for SharePoint isn’t about features. It’s about integration, total cost of ownership, and AI readiness. Here’s how we frame it when we’re working with leadership teams:
It’s already in your licence
If you’re on Microsoft 365 E3 or above, SharePoint is included. You’re not paying for an additional platform. Every euro or dollar spent on a third-party intranet product is a cost SharePoint doesn’t carry — and a separate governance conversation SharePoint doesn’t require.
It’s the deepest integration point in Microsoft 365
SharePoint isn’t a standalone intranet platform. It’s the document storage layer behind Teams. It’s the content source Copilot reasons over. It feeds Viva Connections for the employee experience layer. It integrates natively with Microsoft Search, Purview for compliance, Entra for identity and permissions, and Places for hybrid workplace coordination. No third-party platform can match that level of integration without custom connectors that create their own overhead and governance complexity.
Third-party intranet products solve UX problems by creating governance ones
Platforms like Powell Intranet or Omnia offer polished templates and faster time-to-value. In specific circumstances, they’re worth considering. But they add a licensing layer ($3–8 per user per month), a separate vendor relationship, and a content model that sits on top of SharePoint rather than being part of it. When those platforms are decommissioned — and eventually they always are — the governance question returns to SharePoint. We’d rather help you build that governance model once, on the platform you already own.
It’s where your AI value is created
We’ve written about this in detail in our article on SharePoint as the AI control plane. The short version: Microsoft 365 Copilot reasons over SharePoint content. Intranet pages, document libraries, and site data are all inputs to Copilot’s knowledge model. An intranet built and governed on SharePoint makes Copilot more reliable. One built on a third-party platform contributes nothing to that model without additional connector configuration — and even then, the quality of what it contributes depends entirely on what you’ve built and how you’ve governed it.
The Relationship Between Teams and SharePoint
This is the most consistently misunderstood relationship in Microsoft 365. In almost every organisation we work with, Teams and SharePoint are treated as separate products. They’re not. They’re two surfaces of the same underlying platform — and understanding this changes how you think about governance.
What’s actually happening under the hood
When a team is created in Microsoft Teams, a SharePoint site collection is automatically provisioned behind it. The Files tab in every channel is a SharePoint document library. When your colleagues share documents in Teams, those documents live in SharePoint. When Copilot searches a team’s files, it’s searching SharePoint.
This means SharePoint governance is Teams governance. Permissions set on a SharePoint site affect what people can access through Teams. Metadata applied in a SharePoint library affects how documents appear in Teams search. Information architecture decisions made in SharePoint determine how content is organised when accessed from Teams. You can’t govern one without governing the other.
How we help clients think about this
Rather than asking “should we use Teams or SharePoint?”, we ask: which surface does this content live in, and which surface do people encounter it through?
- Use SharePoint intranet pages for content broadcast to a wide audience — company news, policies, procedures, HR information, organisational programs. Content designed to be found by many, authored by few
- Use Teams for content created and edited collaboratively within a defined group — project files, working drafts, team-specific documents
- Surface SharePoint intranet content through Teams via Viva Connections — giving employees access to intranet news and policy content without ever leaving Teams
Because Teams and SharePoint share the same data layer, a governance model that covers your SharePoint intranet automatically covers the document libraries behind every Team. That’s one of the most compelling arguments for designing SharePoint governance before your Teams deployment scales any further.
Governance First: The Strategic Concept Before You Build
The single biggest mistake we see organisations make is starting with the platform before designing the governance. Sites are created, content is published, navigation is configured — and six months later, someone asks who owns the HR section and nobody has a clear answer.
Governance added after the fact is always more expensive and more disruptive than governance designed before the first site is created. The five steps below represent the foundation we build with every client before any technical work begins. None of them require SharePoint configuration. They’re decisions that need to be made and documented first.
Your intranet needs two levels of ownership, and in our experience, most organisations only think about one of them.
The first is a platform owner: the person accountable for the overall intranet — its information architecture, navigation, quality standards, and governance model. This usually sits with IT or Digital Workplace, but it needs a named individual, not a team. “The IT team owns the intranet” is not ownership. It’s diffusion of accountability.
The second is section ownership: each major content area needs a business owner accountable for the accuracy, relevance, and lifecycle of content within it. Document what this means in practice: the owner reviews content on a defined cycle, approves new pages within their section, and is the escalation point when content becomes outdated or disputed.
How we do this: Before any sites are created, we run a one-hour ownership mapping session with IT and the relevant business leads. We leave with a named owner for every section of the intranet and a one-page brief that defines what ownership means in practice for each of them.
How we did it: A 3,000-person manufacturing company asked us to help them recover an intranet where content ownership had completely broken down. Before touching a single page, we ran the ownership mapping session. The Head of Internal Communications became the overall intranet owner. HR took the People & Culture hub. IT took the Technology & Tools hub. Finance took the Finance & Compliance hub.
Each hub owner received a one-page brief defining their review responsibilities. When the restructured intranet launched six weeks later, every section had an accountable human behind it. The intranet hasn’t needed a recovery project since.
Without an explicit content policy, everyone makes their own decisions — and those decisions are inconsistent. We see this constantly. One team publishes a project update as an intranet news post. Another creates a Teams channel for the same project. A third emails a PDF to the distribution list. The same information ends up in three places, none of them authoritative.
The content policy answers three questions: What types of content belong in the intranet? What belongs in Teams? What belongs in a SharePoint document library? It doesn’t need to be long. One page is enough.
How we do this: We build a simple content decision matrix with the client — usually in a 90-minute workshop with IT, Communications, and one or two business leads. When a content creator isn’t sure where something goes, the matrix answers the question without an IT ticket.
How we did it: A financial services firm came to us after their intranet search consistently returned duplicates — the same policy in three different places, none of them clearly marked as the authoritative version. We ran the content policy workshop and produced a one-page matrix.
Policy documents went to the intranet as pages, with a PDF copy stored in the Compliance document library. Working drafts went to Teams. Finalised client documents went to a governed library with retention labels applied. Within a month, duplicates dropped by 70% and employees stopped asking which version was current.
Naming conventions and site URL structures are almost impossible to change after sites are created and linked. A site created as /sites/HR-Policies-2023 will carry that URL into 2026 and beyond, even when the content has nothing to do with 2023. Naming decisions made informally early in a build set a precedent that other site creators follow — usually inconsistently.
How we do this: We define naming conventions for three levels before the build starts. Sites use a department-function pattern (e.g., HR-Benefits, IT-ServiceDesk). Hub sites use a business domain pattern (e.g., HumanResources, InformationTechnology). Pages use descriptive, search-optimised titles — no dates, no initials, no project codes. These conventions are enforced as part of the site creation approval process.
How we did it: A global professional services firm came to us with a SharePoint estate where every team had invented their own naming pattern. Searching for anything was unreliable because the same type of content had a dozen different URL structures.
We spent two hours before the intranet build defining a naming standard: all hub sites use [Domain]-Hub, all department sites use [Department]-[Function], no site names include years, initials, or project codes. That conversation, which took less than a morning, prevented years of URL debt and made search results immediately more predictable.
Business domains are more stable and consistent, whereas org charts change. If you build an intranet around the org chart, it requires restructuring every time the organisation restructures. We’ve seen this happen, and it’s expensive and demoralising for the teams involved.
We recommend building around business domains — Finance, HR, Legal, Operations, Technology, Communications — so you don’t need to restructure during reorganisations. The domains persist even when the reporting lines shift.
How we do this: We map your hub structure to five to eight domains that represent how employees look for information, not how leadership is organised. We test this by asking a simple question with a cross-section of employees: when you want to find the expense policy, which domain do you think of first? If the answer doesn’t match your proposed navigation, the navigation changes.
How we did it: A 1,500-person retail organisation initially designed its intranet around its four business units. After a reorganisation eighteen months later, the intranet needed significant restructuring. On their second attempt, we helped them redesign around six functional domains:
- People
- Technology
- Finance
- Operations
- Customer
- Legal
This structure remained stable through two subsequent organisational changes. The same employees who had complained about “having to relearn the intranet every time the structure changes” stopped raising the issue entirely.
Most intranet projects are measured by go-live date. That’s the wrong metric. The more useful measure is launch readiness: what conditions must be true before the intranet is released to employees?
Without explicit launch criteria, the intranet goes live when it’s “good enough” — which usually means with structural gaps that are immediately visible and create a first impression that’s genuinely hard to recover from. Employees form an opinion of the intranet in the first few visits, and “broken at launch” sticks.
How we do this: We define a launch checklist with every client before the build starts. It typically includes: every section has a named owner, every owner has been briefed, the top twenty most-queried content items are published and reviewed, navigation has been tested with employees from at least three different roles, and search returns relevant results for the ten most common queries.
How we did it: A technology company we worked with defined a twelve-point launch checklist before the build began. Point nine was: “All pages in the top navigation have been reviewed by their section owner within the last thirty days.”
That single criterion delayed the launch by three weeks. It also prevented an intranet where the IT helpdesk page linked to a ticketing system that had been decommissioned the previous quarter. The three-week delay was uncomfortable. The alternative would have been worse.
Governance in Microsoft 365: How to Set It Up
Hub sites are the primary structural element of a modern SharePoint intranet. Unlike the old subsite model — rigid, hierarchical, expensive to change — hub sites model relationships as links. A site can be associated to a hub without being owned by it, and that association can change when the organisation changes.
Hub sites also scope search automatically. When someone searches from any site associated to the HR hub, they get results from across the entire HR hub family, filtered by their permissions. Create hub sites for each of the business domains defined in the governance section above. Designate a root intranet hub as the home site. And avoid creating a hub for every team or department — hubs should represent major logical groupings, not individual units.
How we did it: A logistics company we worked with created five hub sites: Company (root), People, Operations, Finance, and Technology. The HR Policies site, the Benefits site, and the Learning & Development site were all associated to the People hub.
Before this structure, employees had to know which site contained the parental leave policy. After it, a search from any People hub site returned results from all three — and the most common HR queries dropped out of the IT helpdesk queue within a month.
In the SharePoint Admin Center, the default setting in many tenants allows any user to create a SharePoint site. That’s the primary driver of site sprawl. Changing this to require IT approval — or routing creation through a governed request process — is one of the highest-leverage governance actions available. It’s free to implement and takes an afternoon to configure.
We implement a lightweight request form using Power Automate that captures three things: the intended purpose of the site, the proposed owner, and the hub it will be associated to. A same-day approval process adds almost no friction while giving IT the visibility to prevent structural debt from accumulating.
How we did it: A professional services firm we audited had 340 active sites, of which 180 had had no activity in twelve months. Open site creation had been enabled for years and nobody had been tracking what was being created.
We implemented a three-field site creation request form. Site creation dropped by 60% in the first quarter. Every new site had a named owner from day one. Twelve months later, their active site count was 40% lower and their search relevance score had measurably improved.
Most intranet pages should be readable by all employees — but specific sections need more controlled access. Executive communications, pre-announcement content, restricted policy drafts: these shouldn’t be accessible to everyone, and managing permissions site by site creates governance overhead that doesn’t scale.
We configure sensitivity labels at the site level in Microsoft Purview, which allows IT to enforce access distinctions automatically. At the tenant level, we set default sharing to “People in your organisation only” for intranet sites, with stricter settings applied to sensitive hubs — Legal, Finance, HR Executive.
How we did it: A healthcare organisation we worked with had sensitive HR executive content sitting on an intranet site with standard permissions — accessible to a far broader audience than intended. Nobody had set out to expose it; the permissions had just never been deliberately scoped.
We applied a “Confidential — Internal” sensitivity label to their HR Executive hub. When content within that hub is labelled accordingly, Purview automatically prevents external sharing, applies a retention policy, and logs access for audit purposes — without manual permission management on individual pages.
Microsoft 365 provides site lifecycle management tools in the SharePoint Admin Center that can automatically detect inactive sites, notify owners, and initiate archiving or deletion workflows. Configure these before launch, not after the estate has grown ungoverned. The cost of configuring them before launch is an afternoon. The cost of not configuring them is a rebuild three years later.
We set an inactivity threshold of 90 days and configure automated owner notification when a site crosses it. If the owner doesn’t respond: a second notification, then IT review, then archiving. Archived sites remain accessible to IT but are removed from navigation and search, reducing noise without risking permanent data loss.
How we did it: A technology company implemented a 90-day inactivity policy across all intranet sites as part of a governance refresh we ran with them. In the first quarter, 47 sites were flagged as inactive.
31 were confirmed redundant by their owners and archived. The remaining 16 were refreshed and stayed active. Search relevance improved measurably within two months. The IT team described it as “the first time search has actually felt useful.”
The SharePoint Admin Agent — available in the SharePoint Admin Center for organisations with Microsoft 365 Copilot licences — provides AI-powered governance monitoring across the entire tenant. It surfaces inactive sites, identifies oversharing patterns, flags permission anomalies, and provides recommendations for improvement.
We assign a named IT administrator to review its findings monthly and act on them. We connect those findings to the site lifecycle process in Step 4 — Admin Agent findings trigger the same notification and review workflow as automated inactivity detection. It’s governance as a continuous process, not an annual event.
How we did it: An enterprise client using the SharePoint Admin Agent received a monthly governance digest. One month, it flagged that a Finance hub site had its default sharing settings changed to allow external access — a change that wasn’t part of any approved request.
IT investigated, found a settings error made during a SharePoint update, and corrected it within 24 hours. Without the Admin Agent, this would’ve been caught only in an annual audit — if at all.
Microsoft Purview extends governance beyond SharePoint’s native settings into the full compliance framework: data loss prevention, retention policies, eDiscovery, and audit logging. For organisations in regulated industries — financial services, healthcare, legal, public sector — this isn’t optional. For everyone else, it’s the compliance infrastructure that becomes essential as the intranet scales.
We configure retention labels for intranet content categories: policies (seven years), organisational announcements (two years), project documentation (five years after project close). We apply these automatically based on content type or location using Purview’s auto-labelling capabilities — so content owners don’t need to think about retention. It’s enforced at the policy level.
How we did it: A legal services firm we work with configured automatic retention labels on all pages in the Legal hub. When a junior associate accidentally deleted a policy page, Purview’s retention hold prevented permanent deletion. IT recovered the page from the compliance centre within fifteen minutes.
Without Purview, that page would have been gone. The firm estimated recreating it manually would’ve taken two days and required sign-off from three partners.
The Lifecycle of Tools: How to Keep Your Intranet from Becoming Tomorrow’s Problem
The most common reason a well-built intranet becomes a problem is that it’s treated as a project rather than a product. Projects have end dates. Products have lifecycles. We’ve seen organisations spend significant budget on a rebuild, only to be back in the same position three years later because nothing about how they manage the intranet changed after launch.
Plan covers governance design and information architecture. Build covers configuration, content creation, and testing. Launch covers go-live, employee communication, and adoption. Govern covers ongoing ownership, review, and lifecycle management. Evolve covers regular improvement based on usage data, feedback, and organisational change.
Govern and Evolve are where most organisations underinvest. We budget a quarterly intranet review as part of the ongoing operating model for every client we work with. Not as a project, not as a one-off audit — as a standing process.
How we did it: A global retailer we work with budgets two days per quarter for an intranet governance review. Over eighteen months, those quarterly reviews identified and resolved 140 content issues that would otherwise have accumulated into a legacy debt problem requiring a full rebuild.
The two-day quarterly investment replaced what would have been a six-month rebuild project.
No page should be published without a named owner and a defined review date. In SharePoint, we enforce this through page metadata — a required “Page Owner” field and a “Next Review Date” field on every communication site page. These fields feed into governance reports and Admin Agent dashboards, giving IT and Communications an ongoing view of content health.
We calibrate the review cycle to content type: policy content reviewed annually, program and process documentation every six months, time-sensitive content with a natural expiry date. These defaults are set at the content type level so owners are prompted automatically.
How we did it: An insurance company we worked with implemented mandatory “Page Owner” and “Review Due” metadata fields on all intranet pages. Three months after launch, an automated report showed 23 pages with overdue reviews.
The Communications team contacted each owner. Eighteen pages were updated; five were retired. The process took two hours. Without the metadata fields, those pages would’ve remained live and inaccurate indefinitely — and been surfaced by Copilot as authoritative answers.
A content audit is a structured review against a simple set of quality criteria: Is it accurate? Is it owned? Is it still needed? Does it duplicate something else? High-traffic pages should be reviewed quarterly. An outdated policy on a page nobody visits is a governance issue. On your most-visited page, it’s an employee experience and compliance issue.
We use SharePoint analytics — available natively in every modern SharePoint site — to identify highest-traffic pages. We build the audit calendar into the quarterly governance review and assign specific pages to specific owners rather than running a broad “please review your pages” campaign that generates inconsistent responses.
How we did it: A media company we worked with identified their top twenty pages using SharePoint analytics. The IT helpdesk page received 4,200 visits per month — the most of any page on the intranet.
A quarterly audit revealed it hadn’t been reviewed in eleven months and contained two broken links and an outdated ticket submission process. The fix took 30 minutes. The cost of not fixing it — 4,200 frustrated employees per month — was harder to calculate.
Pages that are no longer needed should have a defined exit path, not an indefinite existence on the intranet. We define retirement criteria for every client: a page is a candidate for retirement when it hasn’t been viewed in 90 days, when its content has been superseded, or when its owner confirms it’s no longer needed.
We also define what replaces a retired page. If employees have been navigating to a page and it disappears without explanation, they’ll contact IT. A redirect or a navigation update should be part of every retirement action — not an afterthought.
How we did it: A pharmaceutical company we work with retired their “COVID-19 Response” section two years on. The retirement process included archiving all pages to a designated archive site, updating navigation links, and publishing a brief “This content has been archived” page at the original URL with a link to the archive.
Three employees contacted IT about the change. Without a retirement process, that section would’ve remained live as a ghost section of the intranet — and continued to surface in Copilot answers as apparently current content.
Every tool or system integrated into the intranet — a Power App embedded in a page, a Power Automate flow triggered from a form, an external connector surfacing HR system data — is a dependency. When that tool changes or is decommissioned, the intranet page that depends on it breaks. We’ve seen this happen repeatedly, and it’s always because the integration had no owner.
We apply the same ownership and review requirements to integrations as to content pages. Every integration gets a named owner, a review cycle, and a retirement path. When a tool is decommissioned, the intranet integration owner is notified with a defined window to update or remove the integration.
How we did it: A retail organisation embedded a Power App for shift swap requests directly in the HR section of the intranet. When HR moved to a new workforce management platform, the Power App was decommissioned — but the intranet integration wasn’t updated.
For three weeks, employees clicked a broken link on the most-visited HR page. Nobody noticed until an employee flagged it to their manager. An integration ownership register connected to the tool lifecycle process would’ve caught this before the new platform went live.
The intranet is never finished. It’s a living product that reflects the state of the organisation. When your organisation changes — new leadership, a restructuring, a new strategic initiative, a change in how people work — the intranet should change with it. That requires ongoing investment, not just a launch.
The minimum ongoing investment for a well-maintained intranet in an organisation of 500 to 5,000 employees is roughly 0.2 to 0.5 FTE — a part-time intranet manager role, within IT or Communications, whose primary responsibility is the health of the intranet as a product. We always recommend this as part of the transition plan at launch.
How we did it: A professional services firm we worked with launched their intranet with a dedicated project team, then transitioned to a 0.3 FTE intranet manager role within Communications at go-live.
Two years later, a competitor firm that had taken the “project only” approach was mid-way through a costly rebuild. This firm’s intranet had an adoption rate 40% higher and a content freshness score their IT team reports to leadership every quarter.
Ease of Use: Building for Adoption, Not Just Structure
Structure is the prerequisite. Adoption is the goal. An intranet that’s perfectly governed but rarely visited has failed. Here’s how we approach adoption with every client:
Design navigation for employees, not for IT
Navigation should reflect how employees think about their work, not how IT categorises data. We test every proposed navigation structure with employees from different roles and tenures before building it. We ask them where they’d expect to find the expense policy, the IT helpdesk, and the new starter guide. If their answers don’t match the navigation, the navigation changes — not the employees.
Surface the intranet through Teams via Viva Connections
The most effective adoption driver we’ve found is making the intranet accessible without requiring a separate URL. Viva Connections embeds a customisable intranet dashboard directly in the Teams sidebar — putting news, tools, and policy content in the interface people use every day. For organisations where Teams is the primary work surface, Viva Connections is the difference between an intranet people visit and one they actually encounter.
Make it the single authoritative source for critical information
Adoption follows authority. If the expense policy lives in the intranet, in a PDF attached to an email, and in a Teams channel message, people will use whichever version they find first — and that version may be outdated. We retire all other versions as part of the launch process. When employees learn that the intranet is where accurate information lives, they go there.
Use personalisation to make content relevant
SharePoint’s audience targeting allows content — news, quick links, announcements — to be shown to specific groups based on their Microsoft 365 profile. An employee in the London office shouldn’t need to scroll past Frankfurt-specific announcements to find what’s relevant to them. We configure audience targeting from the start, using the same organisational structure that informs the hub architecture.
The AI Angle: Why Intranet Quality Equals Copilot Quality
We’ve written about this in detail in our article on SharePoint as the AI control plane. But it’s worth repeating here because it’s directly actionable in the intranet context — and it changes how you prioritise governance work.
Microsoft 365 Copilot reasons over SharePoint intranet pages. When an employee asks Copilot “what’s the parental leave policy?”, Copilot searches the intranet. When a new starter asks “who should I contact about IT access?”, Copilot searches the intranet. The quality of those answers — their accuracy, relevance, and trustworthiness — is a direct function of the quality of the pages Copilot is reasoning over.
Human-readable isn’t the same as AI-ready. A page written for visual consumption doesn’t necessarily give Copilot the structured, unambiguous signal it needs. An AI-ready intranet page has a clear descriptive title, explicit section headings, and content that states facts directly rather than implying them through layout.
Duplicate and outdated pages are amplified by AI. When two near-identical policy pages exist, Copilot surfaces one of them as the answer — without flagging the ambiguity. Maintaining a single authoritative page per topic isn’t a content quality issue. It’s an AI reliability issue.
The governance investment made in the sections above isn’t just an intranet investment. It’s a Copilot reliability investment. Every outdated page removed, every ownership gap closed, every duplicate retired makes Copilot answers more accurate for every employee who uses it.
Questions to Ask Before You Build
Before you commission a build, migrate a platform, or restructure an existing intranet, these are the questions we run through with every client:
Governance & Strategy
- Do you have a named intranet platform owner before the first site is created?
- Have you defined the content policy — what belongs in the intranet, Teams, and document libraries?
- Is your hub architecture built around business domains, or around the current org chart?
- Do you have explicit launch criteria, or just a go-live date?
Microsoft 365 Configuration
- Have you restricted open site creation in the SharePoint Admin Center?
- Are sensitivity labels and sharing defaults configured before content is published?
- Is a site lifecycle policy in place — not planned for later, but configured now?
Lifecycle & Adoption
- Does every published page have a named owner and a review date?
- Is the intranet budgeted as an ongoing product, or as a one-time project?
- Can employees access it from within Teams without visiting a separate URL?
AI Readiness
- Do your ten most-queried intranet topics each have a single, current, authoritative page?
- Are your pages structured for machine reasoning, not just visual consumption?
- Is your intranet governance connected to your Copilot readiness work — or running as a separate initiative?
If most of those questions are uncomfortable to answer, the intranet isn’t ready to build — or isn’t ready to scale. That discomfort is useful. It tells you exactly where to start.
A Governed Intranet Is a Strategic Asset. An Ungoverned One Is a Liability.
SharePoint gives you a capable, deeply integrated, AI-ready intranet platform at no additional licence cost. It connects to every tool your employees already use. It feeds the AI capabilities your organisation is investing in. It scales with you rather than requiring a platform change every five years.
But it only delivers on that promise when the governance model behind it has been designed deliberately. An ungoverned SharePoint intranet isn’t a neutral outcome. It’s an actively accumulating liability: stale content that misleads employees, orphaned sites that inflate your governance perimeter, and AI answers that are only as reliable as the pages they’re drawn from.
The organisations that build their intranet right — governance first, structure aligned to how employees think, lifecycle discipline built in from day one — find that the intranet becomes a compounding asset. It improves adoption of every other Microsoft 365 investment. It reduces the IT cost of managing information requests. And it becomes the knowledge foundation that makes Copilot genuinely useful.
Not sure where to start — or whether your existing SharePoint environment is a foundation worth building on?
Our team works with organisations at every stage of the intranet journey — from greenfield builds to ungoverned SharePoint estates that need a governance retrofit before they can scale. We’ll assess your current environment, design the governance model that fits your organisation, and build a roadmap that makes SharePoint the strategic asset it
blog
News from Impactory
Find out the latest from our company and stay up to date with everything worth knowing about our intelligent solutions and services from the multifaceted Microsoft Office world.
What is an Intranet? Definition, Benefits and Features.
Having a good intranet means it’s used by your employees. If they don’t ever open it, that simply means it’s not done right.
Microsoft 365 Apps
Microsoft 365 Apps are available in various subscription plans for both individual users and businesses, with different levels of features and services.
SharePoint New Landing Page and Templates Gallery
Microsoft is refining the SharePoint experience to make content creation easier, more visual, and faster.
Ultimate Guide on How to Use SharePoint (and Intranet)
With Microsoft’s SharePoint new concept of Modern Intranet, things can get really beautiful, nice and easy to use and in a much quicker way.
[UPDATED] Microsoft Viva – Employee Experience Platform EXP
With the introduction of Microsoft Viva, Microsoft’s goal is to strengthen the position of Teams as a hub for everyone’s workday, connecting everything to make it more convenient.
IMPACTORY
Your reliable, high-performance partner
We offer a wide range of consultancy services for the planning, introduction, and implementation of SharePoint, Microsoft 365, and hybrid applications. Benefit from our many years of experience in the industry.