Most member portals are built by asking the wrong question. The question asked is "what do we have?", and the answer is everything, so everything goes in. The question that produces a useful member portal is "what does a member need in one place, that they cannot easily get anywhere else?"
That question has a much shorter answer, and the shortness is the point. A member portal containing six things people use weekly is a functioning one. A portal containing sixty things people use annually is a document repository with a friendly name.
The four things that always belong
Every member portal, regardless of the type of organisation, needs these four. If you build nothing else, build these.
Who is who, and who decides what
The single most common question in any organisation of more than thirty people is some version of "who do I talk to about this?" It is asked constantly, answered informally, and answered inconsistently.
A member portal should answer it directly: the roles that exist, who currently holds them, and what each role is entitled to decide without asking anyone. That last element is the one most directories omit and the one that saves the most time, because a list of names tells you who to ask while a list of decision rights tells you whether you needed to ask at all.
What is currently open for input
The live items. Proposals awaiting consent, roles seeking candidates, polls closing this week, questions the organisation has genuinely not answered yet.
This is the section that determines whether anyone returns. It is also the hardest to sustain, because it requires the organisation to actually be doing its decision-making in the open rather than deciding privately and publishing afterwards.
What was decided, and why
The decision record, readable by anyone. Not just the outcome but the reasoning, the alternatives, and the person or role that held the authority.
Members ask "why is it like this?" far more often than they ask "what is the policy?", and a portal that answers only the second question sends them to a colleague for the first. A visible decision log is what lets an organisation explain itself without a meeting.
The rules that currently apply
Policies, processes and the governance handbook, with two pieces of metadata that most handbooks lack: who owns this, and when was it last confirmed as still true.
An unowned, undated policy is indistinguishable from an abandoned one, and members treat it accordingly. Attaching an owner and a review date converts a document from folklore into something with standing.
The four things that usually should not be there
Just as important, and less often discussed.
Everything you have ever written. The instinct to migrate the whole shared drive is strong and should be resisted. A portal's value comes from what it excludes. Move the twenty documents people actually use and leave the rest where it is.
Anything already delivered better elsewhere. If payroll is in a payroll system and it works, do not rebuild a worse version. A portal that duplicates a specialist tool inherits the maintenance burden without the functionality.
Real-time conversation. Chat belongs in chat. A portal that tries to be a discussion forum acquires the worst properties of both: the noise of a chat tool without its immediacy, and the permanence of a record without its structure.
Personal or sensitive individual data. Salary details, performance notes, health information and anything else that belongs between an individual and a specific other person. Portals are shared spaces and their access controls are usually simpler than people assume.
A quick way to audit an existing member portal. For each section, ask when it was last updated and how many members opened it in the past month. Anything that scores badly on both is not underperforming, it is finished. Archive it. A smaller portal that is entirely current beats a comprehensive one that is mostly stale, because staleness is contagious: once members find two out-of-date pages they stop trusting all of them.
What changes by organisation type
The core four are universal. What sits alongside them varies considerably.
Organisation type | Add | Because |
|---|---|---|
Worker co-operative | Membership register, general meeting papers, member proposal route, surplus distribution decisions | Members have constitutional rights that need a route to exercise |
Employee ownership trust | Trustee board decisions, the trust deed, the route to raise something with trustees | Employees own the business but rarely know how to reach the trust |
Scaling company | Role directory with decision rights, onboarding path, current initiatives | Growth outpaces informal knowledge transfer around fifty people |
Enterprise transformation | Pilot scope, programme decisions, the metrics being reported upward | The programme has to demonstrate itself to a board |
Volunteer-led organisation | Shift or rota signup, expenses process, the very short version of everything | Volunteers have limited time and no institutional context |
The structural question underneath all of this
The reason a member portal accumulates junk is that it is usually built as a place to put things. Once that is the mental model, every unhoused document has a claim to a place, and the portal becomes a landfill by a series of individually sensible decisions.
The better model is that a member portal is a view. It does not store the organisation's information, it shows the parts of it that a member needs, drawn from wherever those things actually live. Roles come from the role structure. Open items come from live decision processes. Decisions come from the decision log. Policies come from the knowledge repository.
Built that way, a portal cannot go stale, because it is not a copy. It also cannot become bloated, because you are choosing what to surface rather than what to store, and those are very different decisions with very different failure modes.
This is how Autono's Hub is put together, in three parts. Mission control shows what the team is building, deciding and shipping. The membership portal holds roles, responsibilities, skills and interests, so finding the right person is a lookup rather than an enquiry. The team calendar handles coordination without the calendar tennis. All three are views onto the organisation rather than separate stores of information, which is why the Hub stays current without anybody being assigned to maintain it.
Build the smallest version first
If you are starting, resist the comprehensive launch. Build the four essentials, put them in front of twenty members, and watch what they actually reach for.
You will be wrong about at least two things, which is normal and much cheaper to discover at four sections than at forty. You will also find that the section you expected to be most valuable is not, and that something you nearly left out is the reason people return.
Once the core four are working, the question of what to add answers itself, because members will tell you. Until then, every addition is a guess, and guesses accumulate faster than they get removed.
The organisations we work with are trying to give every member genuine access to how their organisation runs, not merely to its documents. That takes a portal built as a view onto live decisions rather than a store of static files. If that is what you are building, Get started with Autono, or request a demo if you would rather be shown what it looks like in practice.
For the wider question of why member participation is thin in the first place, see how to increase member engagement with a member portal. For how work itself gets organised once members are involved, see bottom-up project management.
