Software buyer preparation
What Should Be in a Client Portal Project Brief?
A client portal brief should explain which customers need access, the task they must complete and the information or actions they are allowed to use. Add source-system owners, exceptions and acceptance examples so a developer can assess a useful first release.
A brief helps a team ask the right questions
A portal brief is an input to discovery and estimation, not a complete technical specification. Its purpose is to make the customer workflow and its boundaries understandable. You do not need to design a database before speaking to a developer.
Start with the task that currently moves through emails, spreadsheets or calls. Identify where the customer waits, repeats information or loses visibility. Explain the first result that would make the portal worth using, rather than listing every feature another portal has.
The client portal service explains the wider offer. If you are still evaluating suitability, use the portal readiness guide before preparing a build brief.
Use this practical briefing checklist
- Problem: the recurring task, current channels and consequence of the friction.
- Audience: customer organisations, contact roles and staff who support them.
- First journey: entry, required action, confirmation and correction.
- Records: what customers may view, create, upload or change.
- Sources: systems holding the information and their business and technical owners.
- Permissions: organisation and record boundaries, invitation and removal rules.
- Exceptions: incomplete requests, stale data, disputes and unavailable systems.
- Acceptance: examples proving success, denied access and recovery.
- Operation: customer support, access administration and release ownership.
- Boundary: exclusions, unresolved assumptions and dependencies affecting an estimate.
Mark unknowns openly and assign someone to answer them. A blank field is not permission for a supplier to assume the easiest interpretation.
Describe organisations, not only user accounts
Say whether a contact belongs to one customer or several, whether customers have branches and whether all contacts can see the same records. Explain delegated administration and what happens when someone leaves. Include internal support access in the same discussion.
Identify documents that contain information about more than one party. A customer-specific screen does not guarantee a safe download if the file contains another organisation's records. See the customer data access guide for a deeper review.
State desired controls as testable outcomes. OWASP ASVS can help a qualified team define web-application security checks; mentioning the standard is not proof that the future portal meets it.
Describe a request from start to finish
Hypothetical brief: invited customers need to request a document for an authorised order. Today they email a shared inbox and staff look up the order manually. The first portal release lets them find the order, request the document and see whether staff have resolved the request.
- Include: customer access, authorised order lookup, a request reference, a staff queue and a resolved state.
- Exclude initially: order amendments and payment collection.
- Investigate: whether the order system permits the required lookup.
- Accept when: the customer can complete the journey and another customer cannot retrieve its records or documents.
- Recover when: the order source is unavailable, with an honest status and owned retry or support path.
This is a planning example, not a recommended scope for every business. Choose the smallest complete journey that addresses your actual problem.
Bring useful samples without sharing secrets
Prepare a sanitised request, sample status list and role list. Remove personal data, confidential documents and credentials from initial material. Agree a controlled channel and authorised recipients before sharing anything sensitive.
Use the integration preparation guide for access and interface questions. Ask the developer which uncertainties must be investigated before an estimate can be meaningful.
Once the first boundary is understood, use the scoping guide to record delivery decisions and the implementation checklist for release evidence. Keep the brief updated when a decision changes the customer promise.
Sources and review date
Primary guidance reviewed on 9 September 2026 is linked beside the claims it supports. Checklists and examples are planning aids, not measured research or client results. Examples are hypothetical. Confirm delivery scope, estimates and any specialist-review needs with the responsible team.
Questions
Frequently asked questions
Do we need a technical specification before contacting a developer?
No. Bring the customer task, people, systems, boundaries and representative sanitised examples. Identify the technical questions that still need investigation.
Should the brief include every future feature?
Record future ideas separately. Define one complete first-release journey and the controls needed to operate it responsibly.
Prepare a useful conversation
Bring the task and the unanswered questions.
Discuss the current workflow, source systems and first useful outcome with LCR Technologies.