The two paths you're given
If you run an intranet on SharePoint, you know the shape of the problem. The built-in web parts cover the basics well. Then a page needs something slightly beyond them — tabbed content, an org chart from your own data, a calendar that overlays more than one list — and the ground drops away. On one side: workarounds. Hand-written JSON view formatting, calculated columns, stacked sections standing in for real navigation. They take real skill to build, they're invisible to whoever inherits the site, and they break when Microsoft updates something. On the other side: custom development. An SPFx project, an agency engagement, or a full intranet platform — each a commitment of budget, timeline, and lock-in far out of proportion to "I need tabs on this page."
Zenpo Intranet Suite for SharePoint is the third option: eighteen production components that are already built, already tested, and drop into the pages you already have. It is SPFx — but SPFx we solved, so you don't have to.
Your content never leaves your tenant, and nothing asks permission
Every component runs entirely inside your SharePoint tenant, and no list data, document, or Graph API data ever leaves it. There is no backend database, no Microsoft Graph dependency, no admin consent grant, and no content telemetry. The web parts read SharePoint data and write nothing. The one thing that crosses the wire is licensing: your domain and the product owner's email, sent once for registration and terms acceptance — never your content.
That single architectural decision pre-answers most of a security review before it starts. It's also why our government-cloud story is unusually clean: not "we support GCC," but no feature exclusions in any cloud. Features built on Graph tend to disappear in restricted environments. Ours can't — we never depended on Graph in the first place.
The lists you already have
The loudest recurring frustration among SharePoint practitioners is making list data look decent: hand-writing JSON formatting, watching it break, writing it again. Our components are the productized answer. Each one uses schema-agnostic field mapping — you point it at a list and map its columns, whatever they're actually called. No mandated column names, no provisioning scripts, no content types, no migration. Your data stays your data, structured the way you structured it.
Additive, not a replacement
Intranet platforms ask you to replace your intranet. We ask you to improve one page. Adopt one component on one page; keep every built-in web part, and keep your existing vendor if you have one. Nothing is ripped out and nothing is migrated — and if you ever remove Zenpo, your content is exactly where it always was: in your lists and libraries. Because the suite honors SharePoint permissions and needs no central rollout, any authorized team site can improve its own pages without asking an intranet authority or a specialist author for permission.
Things SharePoint genuinely cannot do
Most of the suite makes SharePoint better. A few components make it do things it currently cannot:
An org chart from a list. Microsoft's own documentation says the built-in chart "only supports displaying the organizational relationship of a specific user," that it "cannot export," and that "External users cannot be added." It stops working entirely where Entra manager data is missing — and Microsoft has advised a customer in writing to use "a third-party solution that supports more complex organizational structures." Our Org Chart draws the whole tree from a SharePoint list you control.
A multi-list calendar overlay with per-source colour. Classic SharePoint did this. Modern SharePoint does not. Full Calendar brings it back.
Correct recurring-date logic for birthdays and work anniversaries — the thing practitioners demonstrably struggle to build with calculated columns and formatting rules.
We absorb Microsoft's churn
Microsoft changes SharePoint's interface regularly and without warning, and those changes can break carefully built pages — sometimes in ways the page owner can't even see from their own account. Customizations that hook into page markup or CSS are living on borrowed time; Microsoft explicitly states that surface is unsupported and subject to change.
We build to Microsoft's supported surface only, and never take a dependency on page DOM or CSS shape. When SharePoint shifts underneath, keeping our components working is our job, not yours. To be precise about the promise: we absorb churn on our surface area — we don't prevent Microsoft from changing SharePoint. That discipline, sustained release after release, is the thing you actually renew.
How we write about SharePoint
You will never see us tell you not to use the built-in web parts. Our guides teach the native way first, honestly and well — including when the native web part is the right answer and we're not needed. Where the native approach has a ceiling, the guide names it plainly, and you can decide for yourself whether you've hit it. We think that's what being a practitioner-grade vendor means: helpful first, product second.
This isn't a promise for later — the library already exists. Our SharePoint how-to guides cover the out-of-the-box web parts today, and we keep them current as Microsoft updates the platform.
Browse the SharePoint how-to guides →Curious what the eighteen components are? See the full suite — or read about the two already on the Microsoft Marketplace.