Byline: Fluw editorial team
Published September 6, 2026
Teams often start a customer portal with a sign-in screen, a navigation bar, and a set of dashboard cards. Those elements may be useful, but they are not the product. A customer needs to check a request, download a document, send missing information, or understand what happens next without searching through email.
Before creating the first version, describe those actions and the rules behind them. This gives the team something concrete to review in a browser. It also exposes decisions that are easy to hide behind a polished mockup. This guide covers what an owner, sales lead, or operations team should prepare before starting a portal for customers or partners.
Start with user jobs
Write down five to seven situations in which a customer or partner contacts your team today. Use verbs instead of section names:
- check whether a request was received;
- download an invoice, agreement, or technical document;
- send missing information;
- see available products or commercial terms;
- request a change to an order;
- find the person responsible for the next step.
A useful job ends with an observable result. “Improve communication” is too broad. “A customer can see who accepted the request and what to send next” can become a screen, a status, and a rule.
Keep different audiences separate. A buyer may care about an order, a dealer about price lists and documents, and a service customer about the history of a case. This distinction helps you choose a small first scope. If you are still deciding between a website, catalogue, portal, or internal tool, see “Website, catalogue, portal, or internal tool: choosing the right format”.
Define roles and access boundaries
A role is more than a label in a menu. It answers what a person can see and what they can do.
Start with a simple table:
| Role | Can see | Can do |
|---|---|---|
| Customer | their requests and documents | create a request, upload a file |
| Partner | their orders and approved prices | request a quote, download a price list |
| Manager | requests assigned to their team | change status, add a note |
| Administrator | settings and all working records | manage access and reference data |
Do not add roles “just in case.” If a permission cannot be explained in one sentence, it may not belong in the first version. Mark which data is shared and which belongs to a specific company, contract, or person.
Map the request lifecycle
Statuses let a portal answer the question “what is happening now?” Start with the real process, not a generic set such as “new, in progress, done.”
For a request for quotation, the lifecycle might be:
- Received — the team can see the request.
- Needs information — the customer must provide a document or parameter.
- Under review — a manager is checking the terms.
- Quote ready — the document is available in the portal.
- Closed — the request is finished or cancelled.
For every status, name the owner, the allowed next action, and the exit condition. If a customer can close a request, write that down. If only a manager can change the status, make that an explicit rule rather than an assumption shared in chat.
Do not promise instant updates until you know the source and exchange frequency. If a portal receives status changes from a CRM on a schedule, describe that limitation plainly. The guide “When a website needs a connection to an accounting system or CRM” explains the same preparation for integrations.
Gather documents and document rules
Make a list of documents by user job, not just a list of files in a shared drive. For each document, answer:
- who uploads it and who can download it;
- which request, order, or contract it belongs to;
- whether it needs a version and effective date;
- whether it can be replaced after submission;
- what happens when validation fails;
- how long it needs to remain available for the process.
For example, a customer attaches company details to a request, a manager reviews them, and then publishes a signed agreement. The portal can show one clear chain with meaningful labels instead of three unrelated areas called “Files,” “Documents,” and “Attachments.”
Do not move every company archive into the first release. Start with documents required by the selected jobs and supported by a team that can maintain them. If retention or deletion rules are not approved yet, mark them as decisions required before launch; do not hide the gap behind a generic security statement.
Assign sources of truth and owners
A portal should not become a second database where people manually correct the same information. For every important field, name the source of truth and the owner:
| Data | Source | Owner |
|---|---|---|
| Company name | CRM or accounting system | sales team |
| Request status | request-management service | assigned manager |
| Document | portal and project storage | request owner |
| Catalogue and prices | approved product source | commercial team |
If the source is currently a spreadsheet, that is workable. The important part is deciding who updates it and how changes reach the portal. For catalogue work, check products, prices, and stock before design; the catalogue preparation checklist covers the same questions.
Also define what happens when the source is unavailable. Does the portal show the last confirmed value, ask the user to retry, or disable a particular action? That is a business rule, not a cosmetic detail.
Set security boundaries before the visual design
For an initial review, concrete boundaries are more useful than a list of certificates:
- which data is personal or commercially sensitive;
- who grants access and how access is revoked;
- which files must not be uploaded;
- which actions must appear in the activity history;
- who is notified about a suspicious or mistaken action;
- how you verify that a user sees only their own records.
Separate required controls from future improvements. Project-owner checks for APIs, server-side session handling, private repositories, and network restrictions may be part of implementation, but they do not replace a clear description of business roles and process ownership. Fluw’s security page describes the controls that can be stated as verified facts.
Prepare acceptance checks
An acceptance check describes what must happen in a specific situation. For example:
A customer opens their request, sees “Needs information,” uploads a PDF, and can see the date of the latest action after submitting it.
Add negative scenarios:
- a manager cannot see another team’s requests;
- an unsupported file type is rejected with a useful explanation;
- an expired link does not expose a document;
- submitting twice does not create a duplicate request;
- a disabled user cannot regain access through an old link.
Use realistic but anonymised data. Invite someone from each role: the person creating a request and the person processing it will notice different problems.
Checklist before you start
- Five to seven user jobs are written as observable outcomes.
- Roles and visibility boundaries are listed.
- Every status has an owner and a next action.
- Documents are tied to a request, order, or contract.
- Key fields have a source and an owner.
- Behaviour during source-system downtime is defined.
- Access, revocation, and activity-history rules are agreed.
- Acceptance checks include negative scenarios.
- Examples use anonymised data.
Common causes of rework
Starting with navigation. The result is a set of empty sections that does not answer the user’s main question. Describe actions first, then group them into navigation.
Copying an email process. Ownership and status changes remain implicit. Map one real path from request to completion before expanding it.
Treating one system as the source for everything. A CRM may own a customer record but not a signed document. A spreadsheet may contain a price but not the permission to show it. Assign sources by data type.
Promising an integration before reviewing access. You need to understand APIs, fields, limits, and update frequency first. Confirm the connector’s actual scope before making a launch promise.
Testing only the happy path. Access errors, missing files, and duplicate requests appear as soon as real users arrive. Include them in acceptance.
Frequently asked questions
Do we need a CRM before creating a portal?
No. You can start with a file or another agreed source. You still need an owner for the data and a rule for how updates reach the portal.
Can one portal serve several companies?
Yes, if the data boundary is explicit. A user might see their own company, several related organisations, or only assigned requests. That must be an access rule, not an accidental default.
Do we need a native mobile app immediately?
Not necessarily. If people work in a browser, start with a responsive web portal and validate the jobs. Evaluate a native app after device-specific requirements are understood.
Who should accept the first version?
The process owner, a representative of each role, and the person responsible for the source data. Together they can check usefulness, permissions, and accuracy.
Start with one working path
A good first portal does not replace every company process. Choose one repeated path—for example, a partner request, document review, and a clear next step. Prepare its roles, statuses, data, and acceptance checks, then start with a task in Fluw. You can review the result in a browser, select a concrete element, and describe what to change next.
If you are not sure whether your problem calls for a portal, catalogue, or internal tool, start with how Fluw works and compare the format with the team’s actual job.