Customer portal walkthrough
A customer portal, from the customer's point of view.
Explore the design decisions behind project information, shared documents and support requests. Follow the journey from account access to a resolved request.
Illustration: four numbered frames of an example walkthrough: the invitation, the customer home, a request with its reference and an expired link with a support route.
Step through the portal as a customer.
Four steps follow an example customer from the invitation to a resolved request: joining the right account, seeing what was shared, raising a request and meeting an exception.
Walkthrough step
View as
Step 1: Invitation
Customer user
Invitation to the customer portal
- From Example Supply Co., for account A-1047.
- Access offered: approved documents, project decisions and requests.
- An expiry date is set, and the invitation can be withdrawn.
- Confirm to continue; permissions are checked again at sign-in.
Customer admin
Invitation sent to the customer user
- Pending until the customer user confirms it.
- It can be withdrawn before it is used.
Staff
Invitation pending for the customer user
- Account permissions are checked on the server at sign-in, not taken from the email domain.
Step 2: Customer admin view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
Contacts on the account
- Customer admin (You)Active
- Customer userActiveAccess revoked
Shows the records shared with the account, and its contacts.
Step 2: Customer user view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
Shows only the records shared with this contact.
Step 2: Staff view
- Quotation Q-2041Approved document
- Packaging changeProject decision
- Order 5521Order status from the CRMUpdated 09:14Delayed, last updated 09:14
- Delivery addressesAccount record from the CRMUpdated 09:14Delayed, last updated 09:14
- Draft invoice INV-0318Internal until approvedStaff only
- Account noteStaff noteStaff only
Contacts on the account
- Customer adminActive
- Customer userActiveAccess revoked
Shows the shared records and the internal items marked staff only.
Step 3: Request REQ-1048
Damaged carton in the last delivery
- 1ReceivedReference REQ-1048 returned
- 2AssignedWith the support desk
- 3Resolved
Replacement confirmed
Staff only
Internal: the order history for 5521 is attached for the support desk.
Step 4: Access revoked
Customer user
Session ended
Access to account A-1047 was revoked. Ask the account administrator if this looks wrong.
Customer admin and Staff
The customer user’s access is revoked. Their open session has ended.
Step 4: CRM unavailable
The CRM is unavailable.
Account details were last updated at 09:14 and may be out of date.
Invite the right contact into the right account.
A portal begins with an approved relationship between a person and an organization. An invitation needs a clear recipient, an expiry and a route to withdraw access. A similar email domain is not proof that two people belong to the same account. The customer sees what access is being offered and can complete a confirmation step; the system still checks account permissions on the server when they sign in.
Recipient
One named person, invited to one approved account.
Expiry
An unused invitation expires.
Withdrawal
Access can be withdrawn before or after the invitation is accepted.
Confirmation
The customer sees the access being offered and confirms it.
Server check
Account permissions are checked on the server when the customer signs in.
Turn a request into a traceable task.
A customer describes the issue in the context of a project or account. The portal returns a reference and distinguishes receipt from assignment and resolution. The customer can see the appropriate progress without exposing the internal team's entire workflow. Staff have the context needed to act and a route to ask for missing information. A notification failure should not erase the request or create a duplicate.
Described
The customer describes the issue in the context of a project or account.
Received
The portal returns a reference.
Assigned
Staff take the request on, with the context they need to act.
Resolved
The customer sees the outcome, without the internal team’s entire workflow.
When information is missing, staff ask for it on the request itself, and a failed notification leaves the request in place without creating a duplicate.
Design the exceptions before invitation.
Expired links, an email change, a moved contact and an unavailable CRM are ordinary conditions. Access revocation should take effect even if a session remains open. A customer who cannot sign in needs a safe support route, while the system must not reveal another organization's records to be helpful. These boundaries are tested against the actual identity and data systems before inviting real customers.
Example
| Condition | What the portal does | What the customer sees |
|---|---|---|
| Expired link | Refuses the link and keeps the account closed | A route to ask for a new invitation |
| Email address changes | Keeps access tied to the approved person until the change is confirmed | A confirmation step for the new address |
| Contact moves to another company | Follows the approved relationship between person and account, not the email domain | Only the records of the account they now belong to |
| Access revoked during a session | Applies the revocation even though the session is still open | No further access to the account |
| Customer cannot sign in | Offers a safe support route and reveals no other organization’s records | How to reach support |
| CRM unavailable | Keeps the request and shows that data is delayed | A notice that information may be out of date |
Turn this journey into your own scope.
This is an example walkthrough of the product decisions a portal needs. A first release can focus on one high-value task and add other views only after access and support are dependable.
Your portal scope
Account model
Approved records
Integration behavior
Operating owner
First task
Acceptance checks
Who authorizes customer invitations
Customer portal development
Customer portals that show each account only what it should see.
View Customer portal development
Questions about this walkthrough.
Does sign-in automatically grant access to every record in an account?
No. The application needs server-side checks against the approved person, account and record relationship. Some information may require a separate publication decision even for an authorized customer.
Is this a live customer portal?
No. A real portal is built around your own systems, access rules and data, and is accepted against agreed checks before customers are invited.
Continue exploring
Continue exploring
Turn this walkthrough into your portal’s first release.
Tell us which customers you serve and what they ask for most. We can define the account model, the first task and the checks to pass before the first invitation.