Client Portal and Communities

The client portal is the logged-in side of the build. Where funnels and the website are what strangers see, the portal is what a customer sees once they have a relationship: the courses they have access to, their upcoming bookings, their invoices and payment history, their documents, and (where it is enabled) a community space to talk to the business and to each other.

The mental model is one login, several rooms. The login belongs to the contact. What they find behind it is assembled from what they hold: offers grant course access, their appointments appear because they are theirs, their invoices because they are the payer, community groups because they were added to them. Nothing in the portal is a separate database; it is a view of the contact's own record.

A community adds something the rest of the platform does not have: member-to-member visibility. That is a genuine shift in what the client is running. Spaces, posts, comments and notifications need moderation, rules and a reason for people to come back, and a community nobody tends is a visibly empty room rather than a quietly unused feature.

Access and identity

• The portal domain or subdomain, so members log in on the client's own brand rather than a generic address
• Login methods: password, password reset, and magic-link style access where offered
• Which contacts have portal access, granted manually or by workflow
• What each member sees, determined by the offers, groups and records they hold
• Branding: logo, colors, fonts, welcome message and navigation labels

What a member can see and do

• Their courses and memberships, with progress carried over from the learning module
• Their upcoming and past appointments, with reschedule and cancel where permitted
• A booking route for a new appointment, using the relevant calendar
• Invoices, payment history, receipts and an outstanding balance, with the ability to pay
• Documents shared with them, and uploads back to the business where that is enabled
• Their own contact details, with control over what they may edit themselves
• A way to start a conversation that lands in the shared inbox rather than a personal mailbox

Community spaces

• Groups or spaces, each with its own membership and purpose
• Public, private and hidden spaces, and whether joining is open or by invitation
• Posts, comments, reactions, and attachments within a space
• Pinned or announcement posts for things everyone must see
• Member profiles, with control over what is visible to other members
• Notification settings per member, and digest frequency where offered
• Linking a space to an offer, so a course purchase includes the cohort discussion

Moderation and governance

• Moderator roles, and what a moderator may remove, edit or hide
• Community guidelines published where members will actually read them
• Reporting or flagging, and the queue a moderator works
• Removal of a member, and whether that also revokes their course access
• Retention and deletion of posts, which matters more than clients expect

Automation

• Workflow triggers on portal access granted, member joined a space, post created, document uploaded and invoice paid
• Welcome sequences that explain what the portal is for and how to log in
• Re-engagement sequences for members who have not logged in for a period
• Internal notifications when a member posts something that needs a reply

1. Decide what the portal is for before you build it, in one sentence the client would say out loud. A portal that exists because the feature exists gets one login per member and then nothing.
2. List what a member will find behind the login and in what order of importance. Bookings and invoices usually matter more to a client's customers than discussion does.
3. Set up the portal domain or subdomain and confirm the certificate, so the login page is on the client's brand. Members who are bounced to an unfamiliar domain assume it is a phishing attempt.
4. Brand the portal before anyone is invited: logo, colors, navigation labels in the client's own language, and a welcome message that explains what this is.
5. Decide how access is granted (automatically on purchase, on first appointment, or manually) and build the workflow that does it rather than relying on someone remembering.
6. Configure what a member may edit about themselves. Letting people correct their own phone number is good; letting them change a field a workflow depends on is not.
7. Wire the modules that supply the content: course offers, the relevant calendars, invoices from payments, and the documents area. Check each appears correctly for a test member who holds only some of them.
8. Create a real test contact with the minimum entitlements and log in as them. The commonest defect is a portal that looks complete to an administrator and nearly empty to a customer.
9. Only add a community if the client has committed to tending it. Agree who posts, how often, and who answers members, before a single space is created.
10. Design the spaces around purposes rather than topics: a cohort for a course, a space for announcements, a space for questions. Three well-used spaces beat ten quiet ones.
11. Write the community guidelines with the client, publish them as a pinned post, and name the moderators in them.
12. Set notification defaults sensibly. A member who receives an email for every comment will mute everything within a week, and then hears nothing at all.
13. Seed the community before inviting everyone: an introduction post, a few genuine questions, and the client's own voice present. Nobody posts into an empty room.
14. Build the welcome sequence that teaches members how to log in and what to do first, and test that the password or access email arrives and is not caught by spam filters.
15. Add the re-engagement sequence for members who have not logged in for a while, and an internal notification when a member posts a question nobody has answered.
16. Agree the moderation routine: who checks the flag queue, how quickly, and what gets removed. Then agree what happens when a member is removed: does their course access go too?
17. Test on mobile, where most members will use it, including login, document download and posting.
18. Review login and participation figures monthly. A portal with falling logins is telling you the content behind it is not worth the password.

The portal is a surface rather than a source. Memberships supply the courses, calendars supply the appointments, payments supply the invoices, workflows grant and revoke the access, and the conversations inbox receives whatever a member sends. Its value is that a customer has one place to go instead of searching their email for a link somebody sent them in March.

Program delivery with a cohort space

Buying the program grants the course offer and adds the member to that cohort's space. The portal shows their lessons, their next coaching call booked from the program calendar, and the discussion where the group and the coach talk between sessions. Completion triggers a certificate and an invitation to the alumni space.

Ongoing service client self-service

A retained client logs in to see their next appointment, reschedule it without emailing anyone, download the documents the business has shared, and settle an outstanding invoice. A message started from the portal lands in the shared inbox with the client's record beside it, so whoever is on duty can answer properly.

Membership community as the product

The subscription itself is access: spaces, a resource library and a monthly live session booked through a class calendar. A failed payment starts a dunning sequence and eventually removes both the library access and the community membership, so the subscription means something. Re-engagement sequences chase members who have stopped logging in before they cancel.

• An empty community is worse than no community. A member who logs in to three posts from two months ago concludes the business is abandoned. Do not launch a space without someone committed to posting in it.
• Moderation is a staffing decision, not a setting. Member-to-member visibility means the client is now responsible for what people say to each other on their brand, including complaints aired in public and advice given by strangers.
• Login friction is the main cause of failure. Access emails caught in spam, unexplained password rules and a login page on an unfamiliar domain lose members before they ever see the content.
• The portal only shows what the modules behind it hold. If appointments are kept in an external calendar or invoices are raised outside the platform, the portal looks broken to the member even though it is working exactly as built.
• Visibility mistakes are serious. A document or post placed in the wrong space can expose one client's information to another. Check what a plain member actually sees, as that member.
• Removing someone from a community may not remove their other access, and revoking a course offer may not remove them from the space. Decide and configure both directions.
• Member-editable fields can break automation. A member who changes their own email or phone can orphan threads, duplicate records and silently opt themselves out of reminders.
• Uploads bring obligations. Documents members upload may be sensitive, consume storage, and need a retention and deletion policy the client has probably not thought about.
• Notifications are either too many or none. Default settings that email every comment train members to mute, after which announcements go unseen. Digests are usually the right compromise.
• Deleted posts are not always fully gone, and members expect that removing something removes it everywhere. Understand the behavior before promising anything.
• The portal is not a substitute for being contactable. Clients who hide behind a portal to avoid phone calls generate complaints rather than efficiency.
• It is not a document management system or a help desk. If the client needs versioning, approvals, signatures or ticket SLAs, be clear about the ceiling now rather than after launch.
• Community content is unsearchable by the business at scale. Valuable answers given in a space do not become knowledge the AI agents or the website can use unless somebody deliberately moves them.
• Mobile is the real interface. If posting, downloading or logging in is awkward on a phone, participation will be near zero whatever the desktop experience is like.
• Portals create an expectation of permanence. Members assume their documents, invoices and course history stay available. Removing access at the end of a relationship needs to be a deliberate, communicated decision.