Your client has made time for the programme. They should not have to search an old email thread to work out what happens next. When the meeting link, preparation sheet and support route live in different places, even a carefully delivered service can feel harder to use than it needs to.
For your Bristol coaching practice, start with one simple question: what should this person be able to do when they return? Usually that means checking the next session, finding the relevant preparation material and asking for help when something has changed. Put those jobs ahead of a dashboard full of information.
Gbeya’s client portal brings sessions, courses, documents, orders and support into a signed-in workspace. Use the portal as an operational home, then agree what belongs there. A client-facing document area is not automatically a confidential coaching notebook, and an employer paying for the programme does not automatically gain access to the client’s private context.
Can your client complete the next three tasks?
Use a test account representing a real programme arrangement. Give the person the tasks, not a tour.
- Find the next session and explain its status, time and timezone.
- Open the intended preparation document and identify what to do with it.
- Find the route for a practical question and recognise whether it was saved.
- Explain how a session can be changed and what happens inside the cutoff.
- Identify which resources remain available when the programme ends.
If a task needs a separate message from you to explain the screen, improve the label, instruction or workflow before adding more features.
This checks usability and operational clarity. It does not certify confidentiality, legal terms or all access controls.
Step 1
Return
Open the private workspace with the right client access.
Step 2
Next session
Check the scheduled session and any confirmed change.
Step 3
Preparation
Find the relevant document or learning task.
Step 4
Help
Use a clear support route when something prevents progress.
Rehearse access separately as client, coach, assistant and sponsor. A booking change and delivery of its email notification are different checks.
1. Design the first return visit, not just the welcome email
Imagine the client returning on a busy Tuesday, several days after joining. They need to recognise the practice, understand which programme or session they are looking at and find the next action without remembering your onboarding explanation.
Use the same plain labels in your welcome message and the portal. If the navigation says My sessions, call it My sessions in the instructions. A familiar destination is easier to recognise than an inventive name that requires a translation.
- Why this matters
- A consistent label connects the instruction the client received with the control they can see. Familiar hierarchy helps users locate actions without first learning a new interface vocabulary.
- Work through the example
- In your welcome message, explain that My sessions holds booking details and Documents holds the preparation sheet. Ask a test client to find both from a fresh login, without a coach narrating the clicks.
- When the approach changes
- A client with only a one-off appointment may not need a long portal orientation. Give them the shortest relevant route rather than asking them to explore features they will not use.
- Your decision
- Choose the two or three return tasks that matter for this programme and test those paths before adding more instructions.
2. Make the next session specific enough to trust
A session card needs more than a date. The client should be able to recognise the service, distinguish a pending request from a confirmed booking and understand the displayed timezone. If the programme includes online sessions, the meeting destination should be checked in the actual booking record.
Agree what happens when the client needs a different time. Gbeya’s current online change flow uses a twenty-four-hour cutoff for an existing booking. A client inside that window needs a clear route to contact the practice rather than a button that implies an unavailable change can be completed.
- Why this matters
- Booking status describes the state of the appointment; the calendar display describes when it occurs. A request, a saved change and an email notification are separate events.
- Work through the example
- For a Wednesday morning session, rehearse a change comfortably outside the cutoff and another inside it using test bookings. Confirm the saved appointment after a successful change. Check an emailed calendar update separately instead of assuming that a success message proves its delivery.
- When the approach changes
- An employer-sponsored programme may require an administrator to coordinate changes. Document that route rather than promising self-service for every arrangement.
- Your decision
- Verify status, timezone and change rules together. A saved booking change does not guarantee that an emailed update arrived or another calendar changed.
3. Give every preparation document a clear purpose
A growing document list can become another inbox. Name the document for the task it supports and tell the client when to use it. “Prepare for session two” is more useful than a file name that only makes sense to the person who uploaded it.
Keep operational material separate from sensitive coaching reflections. Professional coaching standards address the confidentiality and handling of records. Apply that boundary to the workflow: decide what the client, coach, assistant and sponsor should be able to see, then verify those permissions rather than inferring them from a portal label.
- Why this matters
- Purpose, timing and visibility make a document usable. A file being downloadable does not establish that it is the right version or that every person who can access it should do so.
- Work through the example
- For a six-session programme, identify one preparation sheet for session two and make its title and version clear. Check that the intended client can open it and an unrelated test account cannot. Keep sponsor reporting material separate from private reflection content.
- When the approach changes
- If a document is a general public resource, forcing a login may add little value. Use protected access where the relationship, entitlement or confidentiality requires it.
- Your decision
- Before publishing a document into the client journey, confirm the intended reader, current version, next action and access boundary.
4. Make asking for help a complete interaction
Clients should not have to guess whether a request disappeared. Explain where to raise a practical issue, what information helps you investigate it and what response expectations you actually offer. Avoid asking for passwords, sensitive session details or unnecessary personal information in an ordinary support request.
Gbeya provides a signed-in support conversation. Treat the submitted request, its saved appearance and a later reply as separate stages. An automated triage process is not a promise of an instant human answer or a guaranteed resolution time.
- Why this matters
- A clear success message lets the client know the request was saved; a useful error message explains how to recover. The support route also needs an agreed operating process behind the screen.
- Work through the example
- Ask a test client to describe a missing preparation document with its title and the page they were using. Confirm that the request appears in their own conversation and that a failure leaves a comprehensible recovery path.
- When the approach changes
- Urgent wellbeing, safeguarding or emergency needs require an appropriate agreed route. A general software support thread should not be presented as an emergency service.
- Your decision
- State the support purpose and actual response expectations. Verify the saved request before treating the interaction as complete.
5. Plan the end of the programme as carefully as the start
A client who finishes the programme may still need an order record or an agreed resource. Decide what remains available, what ends and what happens if the engagement changes. Put those terms in the appropriate agreement and check that the actual access behaviour matches them.
Keep cancellation, refund and access decisions separate. A changed booking does not automatically answer what should happen to every document, course or payment. If your offer needs a particular expiry or handover rule, make that a specific configuration or build requirement before promising it.
- Why this matters
- Access is a continuing relationship between the person, the resource and the entitlement. A commercial status change can affect that relationship, but it needs an explicit rule rather than an assumption.
- Work through the example
- At the end of the six-session programme, give the client a clear summary of any resources they may continue to use and the support route for an account question. Rehearse the agreed expiry or continued-access rule with test accounts.
- When the approach changes
- A programme with lifetime resource access has a different end state from a time-limited engagement. Do not borrow another offer’s wording simply because the portal looks the same.
- Your decision
- Write the end-state promise first, verify it against the actual controls, and preserve the client’s ability to understand what changed.
The portal should reduce uncertainty, not relocate it
Accessibility guidance favours familiar hierarchy and recognisable controls. For a coaching portal, the practical application is to make the next task easy to locate and name consistently. A polished screen still needs a coherent journey behind it.
Coaching standards bring a different concern: the handling of records and the boundaries of the relationship. The sponsor, client and support assistant may have different legitimate roles. A shared platform should not erase those distinctions.
The counter-case is a programme so simple that a large portal creates more work than it removes. You do not need to fill every section. Begin with the session, the preparation material and a usable help route, then add capability when the engagement calls for it.
Judge the portal by whether the client can complete the agreed task and understand the result. A login count or a colourful dashboard is not evidence that they found the document, attended the session or achieved the coaching goal.
High confidence in clear task labels, explicit status and deliberate access boundaries. The right amount of portal structure depends on the engagement.
Rehearse the journey for your actual client arrangements, including document access, booking changes and programme-end resources. A navigation label alone does not establish that those arrangements work.
Budget a short client-journey rehearsal
Test three tasks in two viewing contexts
Suppose you allocate five minutes to each of three tasks: finding a session, opening preparation material and locating help. Repeat the tasks on a desktop and a phone, then allow ten minutes to compare what was confusing.
3 tasks × 2 viewing contexts × 5 minutes + 10 minutes = 40 minutes of planned rehearsal.
These are planning assumptions, not a usability benchmark. Assistive-technology checks, access problems or more complex engagements require additional time.
Use the rehearsal to expose uncertainty, not to prove that every client will finish within the same number of minutes.
Assumptions worth checking
A portal is complete when the client can log in.
Login is the entry point. The client still needs to find the correct resource, understand status and recover when a task fails.
An experienced client will work out unfamiliar labels.
Experience with other systems can make inconsistent labels more confusing, not less. Use recognisable names and check the actual task.
A successful booking change proves every calendar updated.
The saved booking and the delivery of an external calendar notification are separate. Verify both before making that claim.
Your next 30 days
Days 1–7
Choose the return tasks
Map the first session, preparation document and support route for one programme. Agree the roles and confidentiality boundaries.
Ready for the next step: Each task has a clear destination and responsible operator.
Days 8–14
Rehearse ordinary visits
Run the three-task example on desktop and phone with test accounts. Check status, labels and document versions.
Ready for the next step: A person can complete the tasks without a narrated tour.
Days 15–21
Rehearse changes and failures
Check the booking cutoff, failed requests, account recovery and unrelated-account access. Record controls that need implementation.
Ready for the next step: The client receives an honest result and a practical next step.
Days 22–30
Check the programme end state
Verify continued or expired access against the actual offer. Publish concise client instructions using the portal’s own labels.
Ready for the next step: The beginning, normal use and end of the engagement tell the same story.
Questions before you proceed
What should a coaching client portal contain?
Start with the tasks your programme requires: sessions, relevant resources, order information and a clear support route. Add other sections when they help the client act.
Can clients change their own sessions?
Gbeya has an online change flow with a twenty-four-hour cutoff for the existing booking. Verify the actual service arrangement, availability and saved result before promising self-service in every case.
Does a portal replace confidential coaching notes?
Not automatically. Decide which material belongs in the client-facing operational area and verify permissions for any sensitive records.
Will an employer sponsor see the client’s information?
Do not assume that payment grants visibility. Agree the reporting boundary and test the intended access model for the sponsor, client and coach.
Is a support request an instant chat with the coach?
A saved support conversation is not a guarantee of an instant personal response. State the real purpose and response expectations of the service you provide.
What happens after the programme ends?
That depends on your agreed offer and verified access rules. Describe continued resources, expiry and account support explicitly rather than assuming cancellation changes everything.
Sources and further reading
Prepared by Gbeya · Sources reviewed 30 October 2026.