The SharePoint intranet business case: how to build one that gets approved in 2026

I spend a lot of my time talking to people who are trying to get an intranet funded. Very few of them are stuck on the size of the number. They are stuck because nobody in the room feels certain enough to say yes.

That changes what you should spend your time on. If you think the problem is cost, you will polish a savings calculation for three weeks. If you understand the problem is doubt - about who owns this, what is in scope, what it really costs in year three, and whether it survives the next round of priorities - you will write something quite different, and something far more likely to get signed.

In summary: an intranet business case sets out the problem, the evidence behind it, the options considered, the expected benefits, the full cost over three to five years, and the cost of doing nothing. The strongest cases use evidence from the organisation itself instead of industry averages, separate benefits that produce cash from benefits that release capacity, and answer the ownership and governance questions before anyone has to ask them.

Why do intranet business cases fail?

The same anxieties come up whatever the sector or the size of the organisation. Who owns this once it is live? What exactly is included in that implementation figure, and what turns out to be extra? What does it cost in year three? What happens if it does not work? And, more and more often, will this get parked when something else takes priority?

None of those are questions about whether an intranet is a good idea. That part is usually settled. What the person cannot do is defend the decision to a room asking harder questions than they are.

So the failure is almost always uncertainty, not price. Which means every section you write is there to remove a reason to say no.

Why do senior leaders push back on intranet investment?

Usually because the intranet reads as tactical rather than strategic, because its value is spread so thinly across so many stakeholders that no single sponsor feels ownership of the benefit, and because a good deal of what it delivers is hard to put a number on.

That is a subject in its own right, and Dan has written it up properly in why nobody uses the intranet. It is worth reading before you start drafting, because the objection you are actually facing shapes what the business case has to do.

The practical consequence for the document itself is that you are not writing for one audience. Your finance director, your IT director and your HR director will each read the same case looking for different things, and a case that answers only one of them tends to come back.

How do you prove there is a problem worth funding?

Almost every conversation I have about this starts in the same place. Someone knows the intranet is costing the organisation something, and they cannot prove it.

What usually happens next is that they reach for a published statistic about how long the average employee spends looking for information, apply it to their headcount, and present the total. I understand the temptation. It is also the point at which a lot of business cases start to come apart, because a finance director recognises a borrowed assumption immediately, and once they have picked apart one figure they will discount the rest of the document with it.

As Dan puts it: "Be particularly wary of presenting cost savings which are based on tenuous calculations."

So I am not going to give you an industry average here, because your finance director should not accept one. There are three things you can measure in your own organisation this week, without a vendor, a budget or a procurement process.

Time to find. Give a group of employees real tasks - find the parental leave policy, find who approves expenses over a certain amount - along with a text-only version of your navigation, and record whether they succeeded and how long they took. This is a tree test. It runs on your existing intranet before you buy anything, and it returns a task success rate and a time to find that are unarguably yours.

Time to answer. When someone cannot find what they need they do not give up. They work out who is likely to know, message them, wait for that person to be free, and wait again for an answer. That sequence bills twice, and the person interrupted is usually more senior than the person asking. Helpdesk tickets for questions that should be self-serve, and the frequency of "does anyone know where..." messages in Teams, both evidence it.

What your AI answers. If you have Microsoft 365 Copilot switched on, put twenty questions employees genuinely ask to it and record how many come back correct, current and singular. This one is a demonstration, not a claim, which is what makes it land in a board meeting. You are not telling anyone the content is inconsistent. You are showing them the tool they already pay for reporting it.

The full method for all three, including sample sizes and how to run the exercise in front of a board, is in our guide to measuring intranet findability.

Want help turning this evidence into something a board will accept? Our intranet health check reviews your current SharePoint estate and gives you a structured picture of where it stands - a useful input before you have committed to anything.

How do you present the benefits credibly?

By separating benefits that produce cash from benefits that release capacity, and refusing to blur the two.

The standard argument goes: our people waste fifteen minutes a day looking for information, we employ five hundred people, therefore the intranet saves us this much a year. It is a tempting calculation and it does not survive contact with a finance director, for a simple reason. The payroll bill does not fall.

Nobody makes an employee redundant because search got faster. What you get back is time that person can spend on work that actually matters, and that is worth saying plainly rather than dressing it up as a saving.

Sort your benefits into three tiers and treat each differently.

Cash out. Monetise it. Goes straight into the financial case. Retired software licences, cancelled maintenance and support contracts, avoided replatform costs, reduced print.

Cash avoided. Monetise carefully, and show the working. A deferred hire, reduced contractor or support spend, lower helpdesk load where it changes a resourcing decision.

Capacity released. State it, evidence it, do not put a price on it. Time to find, time to answer, fewer interruptions, employee self-service.

The third tier is where your test results belong. Present them as hours, and as what those hours make possible: people spending more time on the work they were hired to do, and less time chasing colleagues for information that should have been available.

There is one exception worth being clear about. If your organisation sells its people's time - a consultancy, an agency, a law firm, an engineering business - then an hour recovered is an hour that can be billed, and that is cash rather than capacity. I have had exactly that conversation with a client this year, and putting a monetary figure on recovered time was the right call for them. For everyone else, time returned is capacity, and you should present it as capacity.

Get that judgement right and the rest of the document is easier to defend. When a system answers people quickly they use it, which is why adoption is a consequence of getting this right and not a separate benefit to claim.

What does a SharePoint intranet cost, and which budget does it come from?

Less than a replatform in most cases - and the second half of that question matters more than people expect.

It is an uplift, not a replacement programme

If your organisation is already on Microsoft 365, you are paying for SharePoint Online whether or not you use it as an intranet. The tenant exists. Security, permissions and authentication are configured. Your people know the interface and your IT team knows how to administer it.

An intranet built on SharePoint is therefore an incremental uplift on an asset you already own, not a new platform with new licensing, hosting, integration work, training and a migration programme attached. For a business case, that is a much smaller ask.

Two honest qualifications. It is not free - there will be design, configuration, content, governance and very likely a product licence on top, and assuming otherwise is a mistake I see regularly. And it is not automatically cheaper over five years, because an uplift that turns into heavy custom development can overtake an off-the-shelf product. Compare like for like across the full period.

We have written separately about the different approaches to a Microsoft 365 intranet and about whether to build or buy.

Total cost over three to five years

An intranet is a multi-year investment, so a one-year cost is not a business case.

Use this grid in the document itself and fill the numbers for your organisation:

• Product licensing
• Implementation and configuration
• Design and content work
• Custom development
• Internal admin and management resource
• Training and change management
• Ongoing consulting or support

Two costs get missed most often: the internal resource needed to run the intranet after launch, and the change management required to get people using it. Leaving them out does not strengthen the case. It makes it easier to challenge.

Capital or operating budget?

This quietly determines whether your business case is affordable, and it is the question I most often find nobody has asked.

A perpetual licence is a one-time purchase that can often be treated as capital expenditure, which in some organisations reaches a budget that revenue spending cannot. An annual subscription is operating expenditure - easier to approve at lower amounts, but a recurring commitment you defend every year.

Neither is universally better. What matters is knowing which pot you are asking from before you write the ask, because it determines the size of the number, who approves it, and how often you justify it again. Talk to finance early. Our pricing page sets out how each model works.

What does waiting cost?

More than the benefits you defer, because the price of the fix rises while you wait.

Most business cases handle this badly. "Cost of inaction" becomes a paragraph about missed opportunity and disengaged employees, which is both true and impossible to defend. The stronger version names the specific mechanisms by which delay makes the eventual project more expensive.

Adoption gets harder every year. People failed by a system stop trusting it and build workarounds - asking a colleague, keeping local copies, running things through chat. Those habits then have to be broken, so the change management effort grows the longer you leave it. The implementation figure in your business case is only valid if the decision is made now.

Communications keep missing. Another year of important messages sitting unread, and the gap widens as email volume grows. Where something carried an obligation and was missed, that is a dated exposure and not a vague risk.

Software costs increase. Renewal uplifts on whatever you have now, licence creep as headcount grows, and tactical add-ons bought to patch gaps a proper solution would have covered. Worth saying out loud in the room: deferring usually means signing another renewal, so "let's revisit next year" often commits the organisation for three.

The estate grows. This is the one you can measure most easily. Remediation cost is a function of estate size, and the estate only gets bigger - more sites, more duplicate documents, more orphaned pages, more permissions drift. Pull your site and page counts today, compare them with twelve months ago, and the growth rate is your argument.

Expect a fair challenge here: if the estate is sprawling, is that not a governance problem you could fix for nothing? Partly, and it is worth conceding the point. Governance is part of the answer. But governance that depends on people doing the disciplined thing against an interface that makes the undisciplined thing easier does not hold, which is why estates keep growing while everyone agrees they should not.

Should you fund AI instead of a new intranet?

Some organisations are standing down intranet funding and redirecting it into AI initiatives, so this may be the objection you are facing.

The short answer is that it is not a choice between the two. AI is pull and communication is push - an assistant answers questions people know to ask, but it does not tell anyone what they needed to know and had no reason to look for. It also answers from your content, so funding the answering layer while the content layer deteriorates tends to disappoint on both counts.

I have set out the full argument, including how to reframe intranet work as AI enablement and fund it from a better resourced programme, in six realistic use cases for AI on your SharePoint intranet.

What should you include in an intranet business case?

Most organisations have a required format - use yours if you have one. These are the elements I see in the cases that get approved:

• Mission and vision - where you are trying to get to, in a sentence a board will repeat

• Problem statement - the specific issues this resolves, not a general case for intranets

• Evidence - your test results. Numbers show the extent, anonymised quotes show what it feels like

• Alignment with organisational strategy, using the language of your own strategy documents

• Alignment with sub-strategies - HR, IT, internal communications, knowledge management, and any AI programme

• Benefits, sorted into the three tiers above

• Options considered, including doing nothing, and why you rejected each

• Costs over three to five years, including internal resource

• The cost of waiting, with mechanisms rather than adjectives

• Implementation approach and roadmap - enough to show it is realistic

• Governance and ownership

• KPIs and measurement

• Examples and case studies, ideally from your sector

Who approves it, and who owns it afterwards?

Two questions that stall more business cases than cost ever does.

The approval path. A case of this size usually passes through the originating department, then finance to check the figures, then legal, then the most senior approver. Any one of them can send it back and each return costs weeks. Find out the order before you submit, and get the document as close to final as you can before it reaches legal, who are usually the busiest and least able to absorb something half-finished.

The strongest case I have seen this year went to a board where more than ten people had to sign it. It got through because each of them could find their own concern answered on the page, not because the headline number was persuasive.

This is also where a smaller ask pays off twice. An uplift on infrastructure you already own does not just cost less - it often needs fewer signatures, which means fewer opportunities to stall.

Consider asking in two rounds

One approach worth considering, particularly in organisations with a formal budgeting cycle, is to split the ask in two.

The first round secures budget for the project in principle - there is a problem, here is the evidence, here is roughly what solving it costs. The second commits to a specific solution once you have run a proper selection process.

The reason this helps is practical. Intranet software costs vary enormously depending on the approach you take, so a business case that names precise figures needs a solution already chosen - which means doing selection work before you know whether the project is funded at all. Splitting the ask lets you get agreement on the problem first and the answer second. Your finance team will tell you whether your budgeting process allows it.

Ownership after launch. This is the most common unanswered question I see in an intranet business case. Who owns permissions? Who owns the workflows? Who is accountable for content quality in eighteen months when the project team has moved on? If your case does not answer that, someone will ask, and the absence of an answer is usually enough to defer the decision.

Name the roles. Say whether the team changes at go-live. It costs a paragraph and removes a reason to say no.

Why choose SharePoint as the base technology?

Because it is the platform you already own, your people already know, and your AI already reads.

• You have already bought it. SharePoint Online comes with Microsoft 365, so the licensing question is what you add, not what you replace.

• It fits your existing security and compliance setup. Permissions, authentication and governance are already configured in your tenant, removing a significant chunk of integration and assurance work.

• It is familiar - to employees and to the people who will publish and administer content, which lowers one of the biggest barriers to adoption.

• It integrates across the Microsoft stack - Teams, Viva Engage and the Power Platform, under single sign-on.

• Copilot reads it natively. If you are investing in Microsoft's AI, having the content it draws on sitting in a well-structured SharePoint estate is a real advantage.

SharePoint is a strong platform and a limited out-of-the-box intranet. That is a fair description and not a criticism - Microsoft built it to be configured. Products like Lightspeed365 extend it with the intranet capabilities most organisations need, inside the tenant they already own. Microsoft 365 intranet options

Lightspeed365 is built by Content Formula, Microsoft 365 digital workplace specialists since 2005. We deliver intranets across all three approaches - native SharePoint, product-based and custom build - which is why we can be straightforward about when each one makes sense.

Making the case

A business case is not a sales pitch for an intranet. It is a document that removes the reasons a group of cautious people might have for saying not yet.

If you take one thing from this, make it the evidence. A modest case built on your own organisation's numbers will beat an ambitious one built on somebody else's averages, every time.

Start with the intranet health check for a structured view of where your current SharePoint estate stands. If you would rather talk it through, book a demo.