What belongs in the scope of a customer portal?

A portal can look simple from the outside: a sign-in page, a dashboard and a few forms. Its scope depends on what those screens let people do and what happens to the information afterwards.

To define a new portal, work through the customer journey and the staff responsibilities behind it. Screen counts alone miss much of the actual application.

Start with the customer's reason to return

A useful portal has a repeated purpose. A customer might check a request, retrieve a document or complete a required action. Decide which purpose matters first.

Then identify the record that carries that purpose. If the portal is about service requests, define the request and its states. A dashboard becomes easier to design once you know which records it should explain.

Separate the roles

A customer may need to see their own records. A staff member may need to see assigned work. An administrator may control users and configuration. Those are different responsibilities, not simply different menu labels.

The scope needs to establish access rules and how accounts become authorised. Consider whether an account represents a person, a company or a group with several users. That decision can change how records and permissions are organised.

For the first version, include the roles that are necessary. Do not add an elaborate permissions editor unless someone has a defined reason to use it.

Follow one record through the whole process

Take an illustrative service request. The customer creates it, staff review it, missing information is requested and a decision or completion status is recorded.

At each step, ask who can act, which information is required and what the next person sees. Can a request be edited after submission? Can it be withdrawn? Does a reviewer need a reason for rejection?

These questions belong in the scope because they change the application behaviour. They should not be treated as small visual details to resolve after development.

Decide how updates are communicated

A status change may appear on the dashboard, trigger an email or require an action from the customer. Those are distinct features. A notification needs a defined event, recipient and message, as well as a decision about what information should not appear in it.

You can keep the initial notification design limited. A clear in-application status and one necessary email may be more suitable than promising notifications for every change. The appropriate choice depends on the workflow.

Treat documents as a workflow of their own

An upload button raises questions about file types, size, ownership, visibility, review and removal. If a document needs approval, the file and the decision need a relationship the user can understand.

Start with the documents the main workflow actually requires. Public sharing, electronic signing and complex document versioning are separate requirements, not automatic consequences of adding uploads.

Be precise about other systems

A connection to billing, a CRM or another application needs a defined record and update rule. Is the portal displaying information, creating it or changing it? How current does it need to be?

A first version can use an agreed manual process where appropriate. The important thing is to make that choice visible rather than describing the portal as fully integrated when a step still depends on a person.

Describe the acceptance test

For a basic request workflow, a test might verify that a customer can create a request, cannot access another customer's record, sees a staff update and receives the agreed notification. Staff must be able to handle incomplete information without losing the record.

This example does not prescribe every portal's functionality. It shows how a complete workflow can be checked from both sides.

What tends to expand the project?

More user types, multiple organisations per account, payments, real-time messaging, two-way integrations and complex reporting introduce additional decisions. Each may be justified, but each needs its own role in the brief.

The most useful budget conversation starts with the first complete workflow and the dependencies it genuinely needs. An attractive list of features is not yet a delivery scope.

Explore custom web application development or discuss your portal.