Community management software selection by member journeys

Community management software selection should start by defining what members and operators must do. A long feature inventory hides the difficult questions: who can enter, which conversations belong there, how decisions are recorded and whether the organisation can leave with usable information.

A candidate list could include Discourse, Hivebrite and Higher Logic. Treat these as examples to assess, not endorsements or a like-for-like comparison: ask each supplier to demonstrate the same journeys, disclose limitations and quote against the same scope.

What to take away

Write journeys before requirements

For each case, describe the successful outcome, people involved, visibility, record and time constraint. Convert these into requirements that can be demonstrated. "Good moderation" is vague; "a moderator can find the original report, action, rule and appeal status" is testable.

Worked example: in a hypothetical local volunteering community, a new member follows an invitation, registers, finds the welcome information, posts a question, receives a reply notification and later leaves. Turn this into a testable requirement: the member must be able to complete each step using relevant assistive technology, while the operator can verify permissions, moderation records and the export or deletion outcome. Run the same script on each shortlisted platform and record failures and manual work.

Separate essential from optional

Mark requirements as mandatory, valuable or experimental. A mandatory item should connect to a member need, operating duty or accepted risk control. If nobody can explain the consequence of absence, move it out of the gate.

Avoid giving every stakeholder an unlimited list. Competing needs require a decision owner. Public discovery may conflict with confidential participation, while deep customisation may conflict with a small team's ability to maintain it.

Assess access and inclusion

Test registration, navigation, contribution, notifications, reporting and departure using the devices and assistive technologies relevant to the audience. A vendor accessibility statement is useful evidence about its approach, not proof that the buyer's chosen theme, integration and content work together.

The Web Content Accessibility Guidelines are published by W3C and provide an international technical standard. In England, assess duties under the Equality Act 2010; where applicable to a public-sector body, also check The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Include conformance evidence and practical user testing in procurement.

Map information and responsibility

List profile fields, content, messages, event records, analytics, moderation notes and integrations. Decide purpose, access and retention before enabling collection. Apply the UK GDPR and Data Protection Act 2018, and use the Information Commissioner's Office's data protection by design guidance to consider privacy during design rather than after deployment.

Confirm controller and processor roles, sub-processors, transfers, rights assistance, breach routes and deletion evidence with the exact supplier arrangement. Ask for a data processing agreement (DPA), a current sub-processor list, any applicable transfer mechanism, a retention schedule and an exit plan. A security questionnaire cannot answer privacy-purpose questions on its own.

Evaluate operation and security

Ask who performs upgrades, backups, monitoring and recovery. Review authentication, administrative privilege, logs, vulnerability handling and support escalation. The National Cyber Security Centre's cloud security principles can structure supplier questions but do not certify any named product.

Have the intended operator complete routine work in the trial: admit a member, limit a permission, review a report, restore content where appropriate and export a record. Note hidden manual steps.

Prove integration and exit

Use test data to connect identity, customer-support, analytics or event systems. If your organisation uses them, examples to test could include sign-in with Microsoft Entra ID or Google Workspace, support with Zendesk, analytics with Google Analytics, or event registration with Eventbrite; do not assume a platform supports them. Check direction, frequency, error handling and deletion across copies. A logo in an integration catalogue does not prove the configured data flow.

Export members, posts, files, relationships, permissions and moderation history. Open the result independently and estimate reconstruction work. Record which items cannot leave and how members would be informed.

Review commercial and service evidence

Normalise charges across the same member numbers, administrators, storage, support and contract period. Add implementation, migration, internal operation and termination. Request written, itemised quotations from each shortlisted supplier for the same scope and contract period. A low initial subscription may sit beside usage charges or manual work that only appears in the configured scenario.

Read support definitions closely. Identify severity, response measurement, available hours, maintenance, escalation and remedy. The promise that a service is available continuously does not mean a person will answer an administrator or safety concern at any time.

Check the contracting entity and renewal mechanism. Assign internal owners to notice dates, supplier reviews and product changes so the evaluation continues after the project team leaves.

Decide from evidence

Score the demonstrated journeys, unresolved risks, internal work and full cost over an agreed period. Keep supplier claims, test observations and contractual commitments in separate columns. The selected product should remain on editorial and procurement hold until the accountable reviewers can trace every mandatory requirement to current evidence.

Before you act

Common questions

Why is a long feature list a poor starting point for choosing community software?

The article says a long feature inventory hides difficult questions. These include who can enter, which conversations belong there, how decisions are recorded and whether the organisation can leave with usable information. Defining member and operator journeys first surfaces those questions before requirements are written.

How should a buyer test accessibility during procurement?

Test the six core tasks — registration, navigation, contribution, notifications, reporting and departure — on the devices and assistive technologies your audience uses. A vendor statement is evidence of approach, not proof, so check legal duties in England and require conformance evidence plus practical user testing.

What should be checked before trusting an integration or export claim?

Use test data to connect identity, customer-support, analytics or event systems. Check direction, frequency, error handling and deletion across copies, because a logo in an integration catalogue does not prove the configured data flow. Export members, posts, files, relationships, permissions and moderation history, then open the result independently.