A web part is not automatically useful because it makes a SharePoint page look busier. It earns its place when it removes a real piece of friction: helping somebody find the right policy, recognise a colleague, understand who does what, or see the news that matters to them. For organisations already paying for Microsoft 365, that is the standard worth applying.
Too many intranet projects lose sight of it. A team starts with a homepage redesign, adds a collection of attractive components, and then discovers that staff still search through old folders, ask the same questions in Teams, or simply stop visiting the site. The problem was never a lack of page furniture. It was that the intranet did not make everyday work easier.
What is a SharePoint web part?
A SharePoint web part is a component placed on a modern SharePoint page to present information or provide a focused function. Standard web parts cover useful basics: text, images, quick links, document libraries, events and news. They are a sensible starting point, particularly when the need is straightforward.
The limitation appears when the requirement is more specific. You might need an employee directory that is genuinely easy to filter, an organisation chart people can navigate, a branded welcome area that feels like your organisation rather than a default template, or a news display with more editorial control. Those are not unusual requests. They are simply beyond what the standard components were designed to do neatly.
A well-made third-party web part fills that gap without turning a small intranet improvement into a software project. It should install into the existing Microsoft 365 tenant, work with the information and permissions already there, and be configurable by the people responsible for the intranet.
Start with the job, not the component
The most reliable way to choose a web part is to describe the operational problem first. “We need a carousel” is not a useful requirement. “Our internal news is being missed because the homepage gives every item equal weight” is. The second statement gives you something to test: can the component promote priority stories, display them clearly on mobile, and be maintained without calling a developer?
The same applies across a typical intranet. An employee directory is valuable where people waste time asking who owns a service or supports a region. A peer-recognition feature has a place where good work goes unnoticed outside immediate teams. A poll is useful when internal communications need a quick response rather than a long survey. A personalised calendar or email view can reduce the number of places employees need to check before starting their day.
None of these components is essential in every organisation. A small business with one office may have little use for an elaborate organisation chart. A distributed company with frequent onboarding may find it one of the most valuable pages on the site. The right choice depends on the behaviour you want to improve, the content you can keep current, and how much administration the team can realistically sustain.
Where standard SharePoint web parts are enough
There is no prize for buying a component that SharePoint already handles well. Standard web parts are often the right answer for a simple policy page, a basic document area, an events listing or a set of links to commonly used systems. They are included, familiar, and have the advantage of requiring no additional procurement.
Use them where their design and configuration meet the need without workarounds. The warning sign is not that a standard web part looks plain. It is that users cannot complete the task they came to do, or content owners have to create awkward manual processes to keep the page useful.
For example, manually building a staff directory from text blocks may work briefly. It becomes unreliable once people change roles, join or leave. Creating a polished news feature through a sequence of custom page layouts may be possible, but it can make publishing slower and put too much pressure on the person maintaining the intranet.
A component should reduce that overhead, not relocate it.
When buying a web part makes commercial sense
Custom SPFx development has a place when a requirement is unique to the business or needs to connect to a specialist system. But it is often an expensive answer to a common intranet problem.
If the requirement is a branded banner, staff directory, recognition feed, enhanced search experience or news carousel, the business should ask a blunt question: are we paying to invent something that already exists? A custom build for a relatively focused component can readily cost £8,000 or more once design, development, testing, deployment and future changes are included. It will also need an owner when Microsoft 365 changes or the original requirements move on.
A production-ready web part licensed from £249 per year is a different proposition. The initial outlay is lower, the deployment is measured in minutes or days rather than months, and the feature has already been shaped around a familiar use case. That does not make bought software automatically better. It makes it the sensible default when the functionality is proven, the fit is good, and the supplier can show how it works before you commit.
ThePoint’s SharePoint Experience Pack takes this product-first approach across 18 web parts for communication, people, engagement, navigation and productivity. Each is available with a free trial and runs natively in Microsoft 365, with no external hosting or information leaving the tenant. Organisations can license an individual app from £249 per year, choose the five-app Starter Bundle from £999, or cover all 18 through the Complete Bundle at £2,499 per year for up to 500 users.
That pricing matters because it lets intranet owners make a proper buy-versus-build decision. It replaces a vague budget conversation with a clear comparison between a known annual cost and a bespoke development estimate.
What to check before you install
The visual demonstration is only the first test. Before selecting a web part, check where it runs, what data it accesses, who can configure it, and what happens when the organisation changes its branding or structure. A component that needs a separate environment, duplicate data or a specialist developer for every adjustment creates a cost that may not appear in the licence price.
For most Microsoft 365 organisations, native operation inside the tenant is a practical advantage. It keeps information within the existing security boundary and means users remain in the place where they already work. It also makes governance easier to explain. The question is not whether a feature is clever; it is whether IT can approve, support and maintain it without introducing another platform.
Look closely at branding too. Intranet owners should be able to make components feel part of one coherent site, rather than a collection of add-ons from different suppliers. Inheriting the tenant theme will not solve every design decision, but it prevents an avoidable mismatch and speeds up deployment.
Finally, test the editor experience as well as the employee view. Communications teams need to know whether they can publish a story, update a banner or manage recognition without creating a support ticket. If a web part is intended to save time, the day-to-day owner should be able to use it confidently after a short handover.
Avoid the feature catalogue trap
It is easy to approach an intranet refresh as a shopping list. A directory, polls, news, a welcome banner, search and recognition can all sound useful in isolation. Adding them all at once, however, can blur the purpose of the homepage and make launch harder to manage.
A better approach is to start with two or three visible problems. Perhaps employees cannot find key content, internal news has poor reach, and new starters struggle to understand the organisation. Choose components that directly address those points, launch them on pages people already visit, and watch what changes. Are search queries falling? Are more people reading priority updates? Are common onboarding questions reducing?
This also gives the organisation a cleaner case for the next improvement. Real usage and feedback are more useful than a long wish list, particularly when the intranet has previously been underused.
The web part is only one part of the answer
Even the best component cannot compensate for out-of-date documents, unclear ownership or a homepage with no editorial discipline. The technology should make good practices easier, while the organisation sets the rules for content, permissions and review.
That is where experienced SharePoint support can matter more than another design workshop. A senior specialist can identify whether the real issue is navigation, document governance, page structure or a missing feature, then recommend the smallest change that produces a useful result. Sometimes that will be a web part. Sometimes it will be a better content model or a simple workflow.
Choose components that solve a clear problem, fit the tenant you already have, and can be maintained by the people who own the intranet. The result is not a more decorated SharePoint site. It is a place employees have a reason to return to tomorrow.