Nonprofit member portal requirements: what to agree before building

A useful nonprofit member portal starts with three things: the work members need to complete, the records staff maintain, and the rules that determine who can see or change each record. Agree on these before choosing a platform or requesting a fixed-price build.

A list such as “search, groups and events” leaves too much open. Can a guest find a closed group’s resource? What happens while membership is awaiting approval? Who updates an event when its organizer leaves? These decisions affect implementation, cost and daily administration.

The illustrative acceptance checks below cover workflows such as those in our Healthy Aging CORE project. Adapt them to the access rules and operating needs of your own portal.

Start with the people and their tasks

Describe a normal day for a visitor, a member, a group coordinator and a staff editor. For each, write the starting point, the action, the expected result and the person who helps if something goes wrong.

For example: a member signs in, finds a regional event, registers and receives a confirmation. A staff editor changes the event time and checks what happens to existing registrations. The second journey reveals work that a visitor-facing feature list can miss.

Keep the first release narrow enough for your team to operate. A searchable resource library and a clear membership process may be more useful initially than introducing discussions, messaging and several integrations at once.

Specify access as a matrix

Use roles and record states together. “Members can see resources” is incomplete if some resources belong to closed groups, are unpublished or contain staff-only information.

Person and situation	Illustrative expected behaviour	What to check
Guest searches for a public resource	The published resource can be found and opened	Search results and direct URL
Guest searches for a closed-group resource	Restricted material is not exposed	Title, snippet, attachment and direct URL
Member has requested group access	A pending state explains the next step	No access before approval
Approved group member opens a resource	Permitted content is available	Correct group and publication state
Member loses group access	Restricted access ends as agreed	Previously saved links and downloads
Editor previews an unpublished item	Authorized editors can review it	Public search and feeds still exclude it

Access controls cannot recover a file someone already downloaded. Agree whether a document should be downloadable and how exported copies are handled before treating revocation as complete removal.

Give search a clear job

Decide which content types should appear, which filters people actually need and what a zero-result page should suggest. A portal may contain resources, events, funding opportunities and discussions, each with a different useful date or owner.

Test familiar terminology as well as the titles your staff use internally. Ask a small group of intended users to find specific items without instructions. Record whether they succeed, where they get stuck and whether the obstacle is the content, navigation or search behaviour. Use the findings to improve the journeys and test them again.

Treat publishing and events as operational workflows

Name the person who owns each content type. Decide who can draft, approve, publish, correct and archive it. Include a handover path for staff and volunteer turnover.

For events, agree the event’s time zone, the editor’s input convention and the visitor’s display. Include an example across regions and a daylight-saving boundary. Registration limits, cancellation, waitlists and reminder behaviour should be explicit if they belong in scope.

For multilingual content, decide who translates updates and what a visitor sees when a translation is missing. Include content, forms, confirmation messages and support in the language plan.

Plan migration before committing to a launch date

Take an approved sample of existing records and inspect it with the delivery team. Look for duplicates, missing owners, inconsistent categories, broken attachments and unclear access rules. Estimate cleanup separately from the technical import.

Keep a record of source counts, imported counts, exceptions and spot checks. Agree which old public URLs should continue to work and how valid replacements will redirect. Decide who can approve the final import and what happens if reconciliation fails.

Compare buying, configuring and building

Ask suppliers to demonstrate the same journeys using representative, non-sensitive sample data. Record which requirements work out of the box, need configuration, require an integration or need custom development.

Compare total ownership: licences, implementation, migration, staff administration, support and exit/export options. A custom build is useful when essential workflows cannot be served well by available products; it should still have a maintainable scope and an accountable owner.

Make handover part of acceptance

Your organization should know who controls the domain, hosting, application accounts and source repository where applicable. Agree backup and recovery responsibilities, update arrangements, staff training and the process for reporting a failure.

Set accessibility requirements and the testing method during discovery. Test key journeys with keyboard navigation and assistive technology appropriate to your audience, and record unresolved issues and responsibility for fixes.

Before launch, have staff complete the agreed journeys using their intended permissions. This gives staff a chance to practise the work and identify training or configuration gaps.

Bring this checklist to discovery

Download the member portal acceptance checklist (.txt). It gives you space to record each journey, role, expected result, evidence and decision owner. Start with the five journeys your organization most needs to get right.

Discuss your member platform with RapidIteration, or use our software budget guide to compare supplier proposals against the same scope.