Name the customer task and user roles
Choose the recurring task the portal will improve: submitting a request, providing documents, approving work, checking status, downloading records or communicating about an active service. Define customers, customer administrators and internal staff separately.
For each role, list what it can view, create, change, approve and download. Include former customers, substitute contacts and staff who change teams. Permission design cannot be postponed until after screens are built.
- Primary customer task
- External and internal roles
- Organisation and contact relationships
- Access removal and reassignment rules
Define records, status and permitted actions
Identify the authoritative system for customers, projects, requests, documents and status. Decide which data is copied, synchronised or read live. If two systems can edit the same field, define conflict rules and operational ownership.
Write statuses in customer language and state what the customer can do at each stage. Avoid showing internal labels that are ambiguous or expose unnecessary detail. Notifications should point to a meaningful action rather than repeat every background change.
- Source of truth for each record
- Customer-visible status and explanation
- Actions and validation at each stage
- Notification trigger and recipient
Plan identity, privacy and support together
Choose how users are invited, authenticated, verified and removed. Apply the least access needed and test separation between customer organisations. Sensitive documents may require stricter controls, retention rules and logged access.
Give users a visible support route for login, incorrect data and service questions. Define who can correct records and what happens outside support hours. Security claims and legal wording must reflect the actual hosting, providers and processes.
- Invitation and account recovery
- Organisation-level access tests
- Retention and download controls
- Support owner and escalation route
Scope and test a first release
Select the smallest end-to-end customer task and prototype it using representative content. Test on mobile, with long names, missing data, expired links, incorrect permissions and interrupted actions. Include internal administration; every customer-facing state needs an owner.
Set measures before launch: task completion, support contacts, missing documents, response time and use of the old email route. Roll out to a controlled group where practical, correct the flow, then expand based on evidence.
- One complete task for the first release
- Representative data and exception tests
- Operational administrator and support plan
- Baseline, pilot group and review date
Frequently asked questions
Frequently asked questions
Does a customer portal need real-time data?
Only where delay would mislead the customer or block an action. Scheduled synchronisation may be sufficient for slower processes if the update time is stated clearly.
Should customers upload documents by email as a fallback?
A defined fallback can help during transition, but it needs an owner and reconciliation rule. An indefinite parallel process creates duplicate records and uncertainty.
Can the portal use our existing CRM or project system?
Often yes, through supported APIs or controlled synchronisation. Confirm permissions, data ownership, rate limits and failure handling before making the integration central to scope.