Refspan
Menu
All project guides

Refspan project guide

How to plan a client portal: requirements checklist

A client portal brief should define who signs in, what each person can see and which task the portal helps them complete. Begin with the existing process and its problems. Then agree a first release with explicit permissions, data requirements and acceptance checks before choosing a technology stack.

Describe the process you want to improve

Write down the current workflow from start to finish. Who requests information, who responds and where are files or decisions stored? Identify the step that causes confusion or repeated manual work.

For a hypothetical project approval portal, the first release might let a client view a deliverable, leave feedback and approve a version. Billing, chat and reporting could be separate later features. The example is a planning exercise, not a Refspan client result.

  • Current process and the people involved.
  • Problem: repeated emails, missing files or unclear approval status.
  • Main task a user should complete inside the portal.
  • A measurable success criterion, such as fewer manual status checks.

Make permissions explicit

List the user roles and what each may view, create, edit or delete. Include the relationship between accounts: can two contacts from the same company see the same records? Who can invite another user or remove access?

Plan common exceptions, such as a contact leaving a client business, a forgotten password or a user opening a link to another client’s record. Permission checks belong in the application, not only in hidden interface controls.

  • Client user: own records, files and agreed actions.
  • Staff user: assigned clients and internal actions.
  • Administrator: account and permission management.
  • Account lifecycle: invitations, sign-in, recovery and removal.
  • Record access: ownership rules and checks for every action.

Map data and integrations

Identify which information the portal stores and which system is its source of truth. If a CRM already holds client details, decide how updates move between it and the portal. Explain what should happen when an external system is unavailable.

For uploads, define permitted file types, sizes, access rules and the process for replacing or removing a file. Establish data handling requirements with the people responsible for the business before development.

  • Records, fields and relationships the first release needs.
  • Source of truth for each shared field.
  • Integration direction, triggers and failure handling.
  • File upload limits, ownership and access.
  • Operational needs: backups, logs and support access.

Scope a first release that can be tested

Choose one complete workflow rather than a long list of disconnected features. Describe the journey from invitation to completing the main task, including the messages users receive along the way.

Write acceptance checks for the normal path and important exceptions. For example: a client can review their own deliverable, an approval records the correct version, and another client cannot access that record by changing the URL. Use these checks to assess whether the first release is ready.

  • Must-have workflow and explicit exclusions.
  • User roles and example records for testing.
  • Email notifications and where they lead.
  • Expected behaviour for invalid input and unavailable integrations.
  • Who approves the release and provides feedback.

Decide whether a custom build is justified

Compare the requirements with an existing portal product before commissioning custom development. Check whether the standard product handles your permissions, workflow and integrations without creating difficult workarounds.

A custom application can make sense when the business rules are central to the product. It also needs an owner for ongoing maintenance and future changes. Refspan reviews the workflow and first-release requirements before recommending an approach.

  • What can an existing product already handle?
  • Which requirement cannot be met comfortably?
  • Who will own accounts, code and hosting?
  • Who will maintain the application and integrations?
  • What information can wait until a later release?

From brief to build

Tell us what you need built.

Send your brief, designs, or existing website. We’ll discuss the scope and the next step.

Discuss your project

A short brief is enough. We’ll clarify the requirements before agreeing the scope.