What is the best way to build a company intranet using SharePoint?

What should a company intranet help employees do?

An intranet earns its place when employees can complete useful tasks. Finding the current expenses policy, requesting equipment, checking an organisational update or locating a new-starter checklist are clearer objectives than “improving engagement”. Define the recurring problems the intranet will solve and identify the people who experience them.

Interview a range of employees, including remote staff, managers, new starters and people who do not spend their day at a desk. Ask what they search for, which questions they repeatedly send to colleagues and where they become uncertain. Department owners will tell you what they want to publish; employees will tell you what they need to accomplish. Both perspectives matter.

Choose a small set of priority tasks and define success. A useful first release might make essential policies, support routes and staff news easy to find. It does not need to reproduce every existing document store. NetMonkeys’ SharePoint services can support the structure and implementation behind that business purpose.

Why should we plan ownership before the home page?

A well-designed home page cannot compensate for unreliable content. If nobody owns a policy, decides whether it is current or responds to an employee’s question, the intranet gradually becomes a directory of uncertain information. Establish responsibility before visual design makes the project feel complete.

Assign an overall service owner and named owners for important content areas. Define who can write, review, approve and publish. In a small company, one person may perform several roles, but the responsibilities should still be understood. Include holiday cover and a route for correcting urgent mistakes.

Microsoft’s SharePoint intranet planning guidance places organisational priorities, audience understanding and governance at the centre of planning. Use that as a technical reference while making your own operational decisions. The strongest design connects what employees need with people able to keep that information useful.

Which tasks should appear in the first release?

Prioritise by frequency, business importance and the effort required to maintain the result. A rarely used page can still be essential if employees need it during an incident, but that does not mean every departmental document belongs on the home page.

Avoid launching with empty areas simply to make the intranet appear comprehensive. A smaller set of reliable pages is easier to explain and support. Maintain a visible backlog so useful later ideas are recorded without delaying the first practical release.

How should we choose sites and hubs?

Use SharePoint structures to reflect purpose and ownership. A communication-oriented area can support information published to a broad audience, while team collaboration belongs in an appropriately managed working space. Related sites may be connected through a planned hub structure where that suits the organisation.

Do not confuse navigation with access control. Linking sites together or showing a page in a menu does not establish the correct permissions for all underlying documents. The information architecture and the access model need to be designed and tested as related but separate responsibilities.

Keep the structure proportionate. A smaller business may need a simple central site and a few maintained areas, while a larger organisation may require a more distributed publishing model. Avoid reproducing a complex organisational chart in the navigation if employees think about their tasks differently. NetMonkeys’ SharePoint consultancy can help assess the appropriate structure rather than beginning with a predetermined collection of sites.

How do we design navigation people understand?

Use the words employees use when asking for information. “Expenses”, “Get IT help” and “New starters” may work better than internal programme names or department abbreviations. Test these labels with people who were not involved in the project and revise confusing choices before they become familiar only to the design team.

Give priority tasks a clear route without making the top navigation carry every page. Use page layout and related links to support deeper journeys. Employees should understand where they are and how to return to the next useful step. Consistency across areas matters more than giving each department a completely different experience.

Run simple task tests. Ask participants to locate a policy, find a support route and identify a process owner. Observe what they try without coaching them. A correct answer after several hints is not evidence of clear navigation. Record the points of confusion and fix the labels or structure that caused them.

What should we do with existing documents and pages?

Audit content before importing it. Identify what is current, duplicated, obsolete or missing an owner. Ask whether an item helps an employee complete a task, meets a record-keeping purpose or belongs in a team workspace rather than the intranet. Preserve required records while avoiding a public-facing navigation structure built around every historical folder.

Decide when a page is better than a document link. A short process explanation may be easier to use as a maintained web page, while an approved template or controlled policy may need its document format. Keep one authoritative source and link to it rather than distributing fresh copies across several areas.

Add ownership and review information where it helps employees judge reliability. Establish what happens when a review date is missed. Automatically hiding content without assessing its importance can create a different problem, so define a practical review and escalation process. Content maintenance should be planned work, not something somebody does when they happen to notice an old page.

How should pages be written and designed?

Lead with what the employee needs to know or do. Use a clear title, a concise explanation and the next useful action. Long introductory statements about a department’s mission usually do less work than a direct answer to the question that brought the employee to the page.

Use headings that describe the content, readable link labels and accessible images where images add meaning. Do not place essential instructions only inside a graphic. Keep page layouts consistent and test them on the devices employees actually use, including smaller screens and any relevant accessibility tools.

Avoid excessive decoration, carousels and competing calls to action. Each element should support a task or provide necessary context. A page can look polished while making it hard to find a phone number or an approved form. Evaluate design through ordinary employee journeys rather than visual preference alone. Make templates available to authors so good practices continue after the project team leaves.

How do we manage permissions and personalised content?

Define who may read, contribute to and administer each area. Use an appropriate group-based model and keep ownership understandable. Editorial access should not automatically imply broad administrative powers. Review external sharing requirements and ensure sensitive working content is not exposed through an overly broad audience.

Audience targeting and personalisation can help employees see relevant content, but they are not substitutes for permissions. If a document must be restricted, enforce that restriction through access control and test it with an identity outside the intended audience. A hidden link does not make an accessible file confidential.

Include Teams-related and department storage in the review. Employees may reach documents through several routes, so the underlying audience matters more than the page from which the link was copied. NetMonkeys’ Microsoft 365 support services can help align intranet administration with the organisation’s broader identity and access processes.

How should forms and workflows fit into the intranet?

An intranet can act as the front door to useful services without containing every business process itself. It may link to a helpdesk, HR application, booking tool or approved document workflow. Make those routes clear and explain what the employee should expect after submitting a request.

Where a form or automation is introduced, define ownership, handling of exceptions and the record of the decision. A polished request page is not enough if submissions arrive in an unmonitored mailbox. Test the full journey from request to acknowledgement, processing and resolution.

Avoid exposing unnecessary personal or confidential information in broad intranet lists. Decide who needs to see each stage of a request and how long the record should be retained. Keep licensing and support dependencies visible when adding new components. NetMonkeys’ Power Automate consultancy is a relevant route for discussing a governed workflow rather than treating an approval email as the whole process.

What should we test before launch?

Test with realistic employee identities and tasks. An administrator’s view can conceal access problems, while a project team member already knows where everything is. Include participants who are unfamiliar with the design and people who work in different conditions.

Record defects with an owner and a launch decision. Distinguish a minor presentation issue from a broken essential support route or an access exposure. The test record should make it clear why the service is ready to launch, rather than simply showing that a workshop took place.

How do we launch without overwhelming employees?

Explain the benefit in terms of the first tasks employees can now complete. Show where to find an approved policy or how to get support, then give people a straightforward way to return. A long announcement listing every feature is less useful than a few relevant examples.

Brief managers and service teams before the wider launch so they can answer questions consistently. Update old shortcuts and communications that would otherwise send staff back to the previous location. Where an old page must remain temporarily, make its status and the new destination clear.

Provide a feedback route with visible ownership. Employees should know whether to report a broken link, ask a content question or request access. Review early feedback quickly and share useful corrections. Launch is a transition into ordinary operation, so the support arrangement should be ready before the announcement is sent.

How should we measure success after launch?

Measure successful task completion as well as visits. A large number of page views can indicate useful content, but it can also reflect people repeatedly searching for something they cannot find. Combine usage information with feedback and short task tests.

Choose a small set of measures tied to the original purpose: fewer repeated policy questions, faster access to support, completion of new-starter tasks or a reduction in outdated document use. Establish a reasonable baseline and explain the limits of the evidence. Avoid attributing every improvement in employee experience to the intranet alone.

Review search terms and content requests to identify gaps, using information responsibly and proportionately. Share findings with content owners and maintain a prioritised improvement list. Success is sustained usefulness, not a single busy week after launch. The intranet should evolve with business priorities while keeping its core routes reliable.

How can we test the value of the first release?

Use the priority task list to create a small baseline before launch. Ask several employees to find the current expenses guidance, locate the IT support route and identify the owner of an important process using the existing tools. Record whether they succeed, where they become uncertain and when they need another person’s help.

After introducing the pilot, repeat comparable tasks with people who did not design the pages. Examine whether the new experience reduces uncertainty and reaches the right destination. A faster journey to an outdated policy is not an improvement, so verify the correctness of the result as well as the time taken.

Use the findings to choose the next release. If employees find policies reliably but still cannot locate the relevant support service, improve that journey before adding another news layout. The example is an evaluation method, not a promised saving. It keeps the improvement programme tied to the problems employees actually encounter.

What should a content operating agreement contain?

Keep a short agreement for each important area: its audience, purpose, owner, deputy, publishing route and review frequency. Explain what constitutes an urgent correction and who can authorise it. A payroll deadline page and a general team introduction may need different review patterns, so avoid applying a single date to every item without considering its purpose.

Agree how content owners receive feedback and how unresolved questions are escalated. If an employee reports an incorrect policy link, there should be a clear route to the person able to verify and fix it. The technical team can repair a broken page but should not have to decide the company’s policy wording.

Include an exit process for content that is no longer needed. Check important inbound links, preserve required records and point employees to a current alternative where one exists. These routine decisions prevent an intranet from accumulating abandoned areas. They also make maintenance a visible business responsibility instead of an informal favour performed by the original project lead.

How can we keep the intranet useful as the company changes?

Make maintenance part of the operating model. Give authors a manageable publishing process, training and time to review their areas. Agree common page patterns so employees do not have to relearn the interface whenever they move between departments.

Review ownership when people change roles. A page assigned to somebody who left six months ago is effectively unowned, even if their name remains in the project spreadsheet. Include new sites, retired teams and major business changes in the governance process. Plan how obsolete content is archived or retired without breaking important journeys.

NetMonkeys can help review the employee tasks, SharePoint design, permissions and support arrangements together. Bring an existing content inventory, common employee questions and the names of likely owners to the discussion. A useful proposal should explain scope, acceptance and ongoing maintenance. The objective is an intranet colleagues trust as part of everyday work, with clear responsibility for keeping that trust.

What should we remove after the launch?

Retire duplicate policy pages and outdated navigation through an agreed content review. Redirect employees to the authoritative source and give document owners responsibility for keeping it current. An intranet becomes easier to trust when staff no longer need to compare several apparently official copies before acting.