Customer portal requirements should cover both the customer's workspace and the internal team that fulfils each request. A portal is useful when users can submit something, understand its status and complete the next step without reconstructing an email chain. Start with that shared journey, then define records, access and handover responsibilities around it.
Choose one request that deserves a shared workspace
Take a recurring journey such as submitting project materials for review. The customer needs to know which files are required, what has been received and whether anything needs correction. Internally, staff need an owner, due date, review decision and way to ask for missing information.
Write the complete journey before listing features. Include saving a draft, submitting, returning for changes, resubmitting and closing the request. Decide what happens when the customer leaves the page halfway through or a staff member changes responsibility. A login screen and upload button do not answer those operational questions.
Separate customer-visible status from internal working detail. A customer may need “awaiting your revised drawing”, while staff need the reviewer, specific reason and internal assignment. Keep both connected to the same case so the public status cannot drift away from the work being done.
Model organisations, people and requests explicitly
A customer organisation may have several users. Some submit requests, some review them and others only view progress. A person may also work with more than one organisation. Define the relationships rather than using an email domain as the sole basis for deciding who belongs to an account.
Give each request an organisation, requester, internal owner and version history. Attach messages and documents to the request they concern. A file should have an identifiable version and review state, so replacing it does not erase evidence of what staff previously checked.
Specify how invitations, membership changes and departures are handled. Identify who can invite another user and whether an internal person must review the request. Keep ownership transfer separate from access removal: a departing customer contact may leave open work that someone else must inherit.
Write access requirements as actions on records
OWASP's Authorization Cheat Sheet recommends denying access by default and checking permissions on every request. Apply that principle to viewing, downloading, editing and approving each record. A hidden button does not replace the server's access decision.
Prepare a small access matrix for customer users, customer administrators, assigned staff and internal administrators. State which organisations and requests each can access. Include attachments and exports in the matrix, not just the main pages. Record exceptional access as an explicit requirement rather than assuming administrators always need every operation.
Test with two fictional customer organisations. Attempt to open the second organisation's request and attachment while signed in as the first. Repeat using a direct link rather than the navigation. The expected result is an access denial without returning the other customer's content.
Define the staff side of every customer action
When a customer submits material, who receives it and how do they acknowledge responsibility? If the request is returned, what must the customer change? When it is resubmitted, should it return to the previous reviewer or a team queue? These decisions shape the portal more than decorative dashboard cards.
Notifications should point to the current case and explain the required action. Avoid making an email the only record of a decision. Users who miss a notification should still find the request and its next step after signing in.
Agree how the portal connects to the CRM or delivery system. Keep a stable relationship between records and make sync delays visible where they affect the user. A customer should not be told that a request is accepted when only the initial transfer has completed.
Requirements checklist for the first release
- One complete request journey works for customer and staff roles.
- Drafts, submitted versions and later revisions are distinguishable.
- Every customer-visible status has a clear operational meaning.
- Messages and attachments remain connected to the relevant case.
- Account membership and invitation responsibilities are explicit.
- Missing information creates an owned action rather than a vague stalled state.
- Users can recover from interrupted submissions without duplicate cases.
Rehearse a revision across a staff handover
In a fictional project portal, customer Lee uploads a drawing and submits a request. Reviewer Ana returns it for a missing dimension. Lee uploads a corrected version while Ana's work is reassigned to Ravi. The new reviewer should see both document versions, Ana's reason and the current customer submission.
Have Lee refresh the submission page after a simulated connection interruption. Expect one request revision, not a second case. Confirm that the old drawing remains identifiable and that the customer-facing status reflects the new review stage.
Then remove Lee's organisation membership and transfer the request to another authorised customer contact. Verify that Lee can no longer access it and the new contact can continue the journey. This tests continuity alongside the access boundary.
For deciding whether a portal needs a new application or an extension to existing software, read automation versus custom application. Discuss a focused portal through Visuosofts application development and contact the team with a real request and its review loop.