A Client Portal Requirements Checklist for Service Businesses

Start with the client journey, not the screens

Before commissioning a client portal, define the client and staff tasks it needs to support, and the information that must pass between them. Map those tasks across the service journey before choosing screens or features. For each requirement, check whether an existing tool or a simpler process would meet the need.

Use this checklist to describe the work as it happens today, then decide what the portal should change:

1. Map the stages. Write down what happens before, during and after an engagement, from an enquiry or booking through delivery, follow-up and any repeat work. Include hand-offs between people or teams, and note where a client may need to wait for a response or provide information again.
2. Record client tasks. At each stage, list what the client needs to do: for example, provide details, choose an appointment, send a file, review an update or request follow-up. Be specific about the information they must supply and what they need to know before they can continue.
3. Record staff tasks and decisions. Note who receives each request, who checks or updates information, and who decides what happens next. Identify what staff need to see to act, such as a client’s submitted details or the latest version of a document. Consider what could go wrong if a task is missed, duplicated or sent to the wrong person.
4. Describe the current process. For each task, note whether it currently happens by email, phone, spreadsheet, shared files or a separate booking or payment tool. State the difficulty you want to address, such as repeated data entry, unclear ownership or clients being unsure about progress. Avoid treating “add a portal” as the problem to solve.
5. Test the need. Ask whether an existing tool already supports the task, or whether a clearer hand-off or simpler process would be enough. If a login would add an extra step without making a useful task easier for clients or staff, leave it out of the initial scope.
6. Turn the map into requirements. For every task, record the people involved, the information exchanged, the system or staff responsibility, and the intended outcome. Label the requirement essential for launch, useful later or out of scope. This gives a supplier a practical starting point without prescribing a screen for every step.

Keep the journey map as a working checklist: it helps distinguish a service need from a preferred feature, and makes gaps in ownership or information visible before they become build decisions.

Define who can use the portal and what they can access

Before listing portal features, decide who will use it and what each person is allowed to see or do. Define access around real working relationships: a client may have several contacts, while your staff may need different levels of access to client records and account settings.

• List every user group. Include clients, their colleagues or other named contacts, and the staff who will manage or deliver the service. Add any other group only if they have a clear role in the client journey.
• Decide how client accounts are organised. Can one account represent an organisation with several contacts, or is each contact treated separately? If contacts share an account, specify whether they all see the same records and can take the same actions.
• Describe permissions in plain language. For each group, note whether they can view or update client details, records, documents, messages, bookings, quotes or payment information. For example, decide whether every contact can change a booking or whether some actions should be limited to a nominated contact. Record any information that should be visible only to particular people.
• Set out the account journey. State who invites or registers a user, what details are collected, how sign-in access is provided, and who can update a person’s details. Explain what should happen when someone forgets how to access their account or reports that their details are wrong.
• Plan for changes in the relationship. If a contact changes role or leaves a client organisation, decide who tells your business, who removes or changes their access, and whether another contact must take over account responsibilities. Include what happens when a client relationship ends.
• Specify staff account-management tasks. Identify which staff can invite users, amend details, change permissions or remove access. Decide who handles access problems and what information they need to resolve them without making an unauthorised change.

For each decision, name the person or role responsible for keeping access accurate. A useful supplier brief describes the outcome rather than prescribing a screen: “Client administrators can invite and remove their organisation’s contacts; our staff can correct account details and manage access when asked.” If you have not decided who should be allowed to see or change something, mark it for internal agreement before build begins.

List the information and actions clients need at each stage

For each stage of the journey, write down what the client needs to see, submit or change, and what staff need to receive, check or record. Treat each feature as a requirement to assess, not a default part of every portal.

• Before work begins: Note whether clients need to provide enquiry details, complete a form, share instructions or upload supporting files. Specify which details staff need to review, where they should be recorded and who follows up if information is missing.
• While work is under way: Decide whether clients need progress updates, service records, instructions or a history of previous work. State who creates or updates each item, what the client should be able to view, and whether they can correct or add information.
• Files and documents: Describe the kinds of files clients may submit and the purpose for each. Record which staff member or role needs to review them, what should happen next, and whether the client must later be able to find or retrieve documents. Consider what happens if a file is incomplete or sent to the wrong job.
• Messages and notifications: Decide which conversations belong in the portal rather than email or phone, and whether clients need an alert when something changes or a reply is ready. Specify how staff will associate a message with the correct client and job, and who is responsible for responding and keeping the conversation record up to date.
• Appointments, where relevant: Choose whether clients can request, confirm, change or cancel an appointment. Set out who manages availability, who confirms requests and how staff handle exceptions, such as a change that cannot be accommodated. If an existing booking tool already supports the required process, note that as an alternative to rebuilding it in the portal.
• Quotes and payments, where relevant: Map what the client sees before accepting a quote or making a payment, what action they take, and what staff need to review or record afterwards. Include the steps for queries or changes, and check whether current tools can cover the process. Mark these requirements out of scope if they do not apply to your service.

For every item, make the hand-off clear: who acts, what information they use, and what outcome the client should see. This gives a supplier a more useful brief than a feature list that assumes every service needs forms, messaging, bookings and payments.

Decide how the portal should work with existing tools

List the tools already involved in serving a client, then specify what each one needs to exchange with the portal. This helps distinguish a necessary connection from a request to connect systems simply because they are in use.

• Inventory the tools. Include systems used for customer records, accounts, bookings, payments, file storage and communication. Note which staff roles use each tool and what client task it supports.
• Trace the information flow. For every connection you think is needed, record what information moves, where it starts, where it goes and when the transfer should happen. For example, decide whether a booking made in the portal should appear in a staff calendar, and whether a change made by staff should then be visible to the client.
• Identify manual handovers. Note where staff copy details between systems, reconcile records or send updates by hand. Describe what can be missed or delayed, and whether fixing that handover matters enough to justify a connection.
• Check simpler options first. Ask whether an existing product has a client-facing option that covers the task, or whether a clearer process using the tools you already have would suffice. If a separate booking, payment or file-sharing tool could meet the need, compare that with building the function into a portal.
• Name the main record. Decide which system should hold the authoritative version of each type of information, such as client contact details, appointment status or payment records. Specify who checks and resolves mismatches, and what staff should do if two systems show different information.
• Record dependencies and responsibilities. Note any access, configuration or information you would need from an existing software supplier, and who in your business will arrange it. Ask what happens to the client or staff task if a connection is unavailable, delayed or changed.

For each proposed connection, write down the business task it supports and who is responsible for the information on either side. If you cannot identify a task or an owner, leave the connection out of the initial brief until its value is clear.

Set expectations for privacy, security and accessibility

Include privacy, security and accessibility requirements in the brief before a supplier proposes a solution. The aim is to describe what the service needs to protect and how you will check that the portal meets those needs, while leaving legal and compliance decisions to appropriately qualified advisers.

• Record the information the service needs. For each item of personal information, note why it is needed for the service, who provides it, who uses it and which staff or client roles should be able to see or change it. If the purpose is unclear, ask whether the information needs to be collected at all.
• Clarify responsibilities. Identify who will decide the purposes and means of handling personal information, and ask whether another organisation has a controller, joint controller or processor role. Ask the relevant advisers to clarify how each organisation’s role affects its responsibilities. Confirm responsibilities with the relevant advisers rather than assuming that a supplier or software provider takes them on.
• Describe practical access controls. Ask how client accounts will be protected, how staff permissions will reflect job responsibilities, and how access to uploaded or shared documents will be limited. Specify who can approve, change and remove access, including when a member of staff or client contact leaves or changes role. Consider what happens if a client reports that they cannot access an account or believes someone else has accessed it.
• Agree operational expectations. Ask what information you will receive about routine operation, who is responsible for monitoring and handling security incidents, and how backups and recovery will be managed. Record which responsibilities sit with your business, the supplier and any other service provider, and how you will keep access and procedures current after launch.
• Build accessibility into the requirements. Consider how clients using different devices and assistive technologies will complete the key tasks, such as finding a document or submitting a request. Ask the supplier which accessibility requirements suit the service, then specify how accessibility will be checked during acceptance, including who will review findings and decide what needs fixing.
• Keep specialist questions with the right advisers. List any detailed questions about legal responsibilities, privacy or payment compliance for the appropriately qualified advisers and relevant service providers. Give the supplier clear operational requirements without asking them to make those decisions for you.

Plan data migration, administration and ongoing support

Plan the transition as well as the finished portal. Before commissioning, decide which records need to move, who will check them, who will run routine administration and what support the business expects after launch.

• List the information to transfer. Identify relevant client details, service records and documents held in spreadsheets, email, shared folders or existing systems. For each source, note who can provide it and whether it is still used. Do not assume that every old file belongs in the portal.
• Choose the starting record set. Decide whether clients need access to historical information or whether the portal can begin with a defined set of current records. If older records remain elsewhere, note where staff will find them and how they will explain that arrangement to clients.
• Assign data checks. Name the person or role responsible for checking accuracy before information is moved. Agree how to handle records that are incomplete, duplicated or inconsistent across sources. For example, decide which source staff should treat as current and who resolves a mismatch rather than leaving the supplier to infer the right answer.
• Define routine administration. Record who will add or remove users, update service details and maintain any client-facing content. Include who handles a client who cannot access an account, and what information staff need to verify before making an account change. Check that the people assigned these tasks have the time and access to do them.
• Set the boundary between self-service and support. List the changes your staff expect to make themselves, such as updating guidance or correcting a client record, and the changes for which you expect help from a supplier or another provider. Clarify who can access the portal's data and relevant accounts, and how your business would obtain access or move to another supplier if arrangements change.
• Plan ongoing support. Decide how staff will report a fault, who will assess its impact on clients and who can approve a change to the portal. Distinguish routine maintenance from new functionality, and record how urgent client-facing problems should be escalated within your business. Confirm what support you expect to arrange and which responsibilities remain with your own staff.

These decisions help a supplier estimate the transition and understand the operating model, not just the build. If you cannot yet name an owner for a task, record that as an open decision rather than treating it as automatic supplier work.

Separate launch essentials from later improvements

Before treating every requested feature as a launch requirement, classify each one as essential for launch, useful later or out of scope. For every essential item, record the client or staff need it addresses. If the need cannot be described in terms of a task or problem, it may not belong in the first version.

Prioritise the smallest complete service journey: what a client must be able to do, and what staff must do to receive, check or act on the result. Use the table to make the decision visible. Replace the examples with stages from your own service.

For each row, ask whether keeping the process as it is would work, whether clearer instructions or a better form would solve the problem, and whether software you already use can be configured to do the job. Then consider a suitable off-the-shelf tool. Several separate tools do not, by themselves, make custom development necessary.

Custom work may be worth exploring when the required journey or connections between systems do not fit available tools. Weigh that against the operational change: would clients have to enter the same information twice, or would staff need to maintain another record? A portal that adds steps without removing a real source of effort may not be the right first investment.

Keep items without a current, evidenced need out of the launch scope, even if they might be useful later. Record the reason for each priority and alternative considered; this gives a supplier a clearer brief and makes trade-offs easier to discuss.

Turn the checklist into tests and a supplier brief

Turn the decisions in your checklist into outcomes that a client or staff member can demonstrate. This gives you and a supplier a shared way to discuss what “done” means, without prescribing screens before the workflow is understood.

• Write observable acceptance criteria. Replace vague aims such as “easy to use” with a result: for example, a client can submit the requested information, sees confirmation, and staff can find the submission against the correct client record.
• Make a test scenario for every launch-essential journey. Describe who starts it, what information they use, what action they take and what should happen next. Include relevant roles, permissions and connected systems. For a document journey, specify which client can find which document, and what a staff member should see after it is shared.
• Test the exceptions as well as the usual path. Note what should happen if information is missing, a client has the wrong access, or a connected system does not contain the expected record. Agree how staff will spot and handle the issue rather than leaving the responsibility implicit.
• Agree how review will work. Name the business users who will check the portal, choose suitable sample content or records, and decide how reviewers will record problems. For each issue, capture the scenario, what happened and what was expected; agree who will decide whether it blocks acceptance.
• Prepare a compact supplier brief. Bring together the journey map, user groups and permissions, prioritised requirements, integration inventory, operational responsibilities and acceptance scenarios. Mark what is out of scope and list unresolved decisions, such as which system should hold a particular record, so assumptions can be discussed before work is agreed.
• Use the brief to compare approaches. For each requirement, note whether an existing tool or a simpler process could meet it, and what gap would remain. That makes it easier to distinguish a genuine need for custom work from a preference for a particular screen or feature.

Once the checklist and scenarios are ready, you can use them to discuss a project with a supplier.