It is not stated where the portal gets its data or how often it is updated
What it leads to. The contractor plans for one way of obtaining data, while the buyer expects another. This comes to light during development: an integration is needed that nobody estimated. Meanwhile the customer sees outdated invoices and request statuses and still calls the operator, so the portal does not do its job.
How to write it right. Add a data sources section to the specification. For each type of information (contracts, invoices, requests, inquiries), state the source system, the transfer method and the acceptable update delay. Describe separately what the portal shows when a source is temporarily unavailable.
Registration and access recovery are not described
What it leads to. This is the most common point of failure in real operation. If it is not defined how a customer first gets into the portal and how they are linked to their contract, the contractor invents the process. At acceptance, the buyer discovers that this process does not suit its customers. A lost password without a clear scenario turns into a flow of support requests.
How to write it right. Describe the scenarios separately: first-time registration and verification of the customer's identity, linking to a contract, password change and recovery, and what happens when the customer loses access to their phone or email. For legal entities, specify separately who gets access on behalf of the organization and how.
There are no requirements for login security
What it leads to. The portal holds customers' contracts and financial data. A wording such as "the system must be secure" cannot be verified, which means it can be neither accepted nor challenged. Contractors plan for different levels of protection, and the bids stop being comparable. The consequences of weak protection reach the buyer only after launch.
How to write it right. Write verifiable requirements: authentication methods and whether a second factor is needed, password rules, behavior after repeated failed logins, session lifetime, and logging of logins. Refer to the regulatory requirements and standards that are actually mandatory for the buyer, and describe how compliance will be checked.
It is not spelled out what the customer can change on their own and what only an operator can
What it leads to. Without a split of permissions, everyone understands "customer portal" in their own way. Some expect customers to file requests and edit their contact details themselves, others assume the portal is read-only. The mismatch surfaces at acceptance, and it is resolved either by extra work at extra cost or by an argument about what was part of the task.
How to write it right. Build a permissions table: for each object (contact details, requests, inquiries, documents), state what the customer can create, edit, only view, and what is possible only through an operator. Add a description of operator roles and the procedure for confirming changes.
Reports for management are forgotten
What it leads to. The specification is written entirely from the customer's point of view, while the buyer has its own questions: how many customers use the portal, which inquiries are the most frequent, where requests pile up. If the document has no reports, they have to be ordered separately after launch. Meanwhile management cannot see whether the system pays off and whether it is being used.
How to write it right. Set aside a section of the specification for analytics and reporting. List which indicators management needs, in what form and how often, who has access to them and whether data can be exported. Even a short list of indicators is better than none.
Acceptance is not tied to usage scenarios
What it leads to. When acceptance criteria are worded in general terms ("the portal works correctly"), either party can interpret them in its own favor. The result: a drawn-out acceptance, returns for rework and mutual dissatisfaction, even though the work is formally done.
How to write it right. Describe acceptance through concrete scenarios: the customer registers, finds a contract, pays or requests an invoice, files a request, sees the history of inquiries, recovers access. For each scenario, record the expected result and the test data, so that acceptance is a check rather than a discussion.