Most intranets are a content management system with an org chart bolted on. This one is five business processes, a ledger asset, a shared sheet and a set of catalogues, presented as one employee-facing surface.
So its parts behave like the rest of your company's systems instead of like a website.
The landing page
The screen people open in the morning answers "what do I need to know and what do I need to do", instead of being a second newsroom:
- One featured story, with a way into the newsroom
- Upcoming corporate events
- A featured benefit
- Recently recognised colleagues - who was recognised and why, so the company is visibly celebrating contributions instead of displaying point totals
- Gallery highlights
- A poll
- The employee's own requests - what they are waiting on
News, from an idea on a sheet to a published post
The editorial pipeline starts before a story exists.
Story ideas live as rows on a shared sheet - drafted, triaged, assigned, prioritised, with whatever columns your editorial team actually argues about. It is a spreadsheet, so an editorial meeting is a normal meeting instead of a tool-adoption exercise.
When an idea becomes a story, the row keeps up by itself: the sheet's row reflects what happened to the post it turned into, because both are on the same platform and not in two systems somebody reconciles.
Then the post moves through a publication lifecycle - drafting, review, approval, release - as a real process, with named statuses, permitted transitions and who may perform each one, instead of a "published" checkbox with an honour system around it.
- Nothing appears in the newsroom that has not been through it, which is what makes the newsroom a source, not a noticeboard.
- A cover image is part of the lifecycle, not an upload somebody remembers to do.
- The editorial board itself - the kanban editors work stories on - lives in the administrative application, so the portal never doubles as an editorial console.
The gallery of the company's own life
Company photographs - offices, teams, events - filterable by tag and viewable in several layouts.
Underneath, a photo is a record in a gallery process carrying tagged image attachments, and only published ones are shown. So the gallery has the same moderation story as the newsroom: a picture is in it because somebody released it, not because somebody uploaded it.
The events calendar
Upcoming corporate events on a day-picker strip - range-selectable, with dots on days that have something, a Today button and paged navigation - above a horizontal reel of event cards linked to the strip, so picking a day filters the reel.
The events themselves are a shared process filtered to published, and the administrative side - the events board where they are created and scheduled - is in the administrative application.
The org directory
Who is who, who reports to whom, and which unit somebody belongs to - read from the platform's shared org structure instead of from a copy the portal maintains.
That shared structure is the same one approvals route through, the same one an AI employee is a member of, and the same one price approvals and project roles resolve against. One org, not one per system. See AI organisation.
Rewards: a real programme, not a points widget
It is three things at once.
A catalogue. What can be redeemed, with its cost, its availability and its rules - maintained as ordinary master data by an administrator, not hardcoded.
A ledger. Points are an asset in the platform's ledger, with accounts per employee and double-entry postings - not a number incremented in a table. So:
- A balance has a statement behind it. "Why do I have 340 points" is answerable line by line.
- An award is a posting made by a recognised process, with an actor on it.
- A mistaken award is reversed, not edited away, so the record of what happened survives the correction.
- The totals reconcile. What was awarded across the company and what employees hold are two views of the same postings rather than two counters that drift.
A shop. Browse the catalogue, build a cart, submit a redemption request, see your own balance and your own request history - all against real data, not an illustrative screen.
And a redemption is a process: the request is submitted, approved, and fulfilled, with each step recorded. Granting points, approving a redemption and fulfilling it are administrative surfaces in the administrative application; the employee sees the shop.
Requests go somewhere
A request raised on the portal lands in the service desk - triaged, routed by category and tracked against an SLA, with replies reaching people in Telegram or email.
Employee surfaces and admin surfaces are separate applications
A deliberate rule, not an accident of layout: an authoring or administration surface belongs in its own application, reached through the switcher in the navbar.
So the editorial kanban, idea-board analytics, the events board, and the whole benefits administration - catalogue, grants, redemption approval and fulfilment - are their own application. The portal provides the shared processes and the shared sheet; the administrative application consumes them.
The result is a portal that stays a portal, and an admin console that does not have to pretend to be one.
What it is made of
| Part | Built as |
|---|---|
| News | A publication process, plus a shared sheet of story ideas |
| Gallery | A process whose records carry tagged image attachments |
| Events | A shared process, employee view filtered to published |
| Benefits | A ledger asset, a catalogue, and a redemption process |
| Requests | A service-request process, consumed by the service desk |
| Pages | The platform's own widget catalogue and theme |
Every one of those is an artifact you can open and change - see Applications. The portal is a starting point that happens to work, not a fixed product.