Decide what the portal is for
Portals fail in two opposite ways. Some are a login page in front of a few documents, visited once and forgotten. Others try to expose the entire business and are never finished. Both come from starting with features instead of a purpose.
Start with your own inbox and phone log. For a fortnight, note what clients ask for: a copy of an invoice, the status of an order, a document, a booking, a change to their details. The requests that are frequent, repetitive and answerable from data you already hold are the portal's first features. Requests that need judgement or a conversation should stay with people, and the portal should make reaching those people easier.
Features, grouped by the job they do
| Job | Typical features | Depends on |
|---|---|---|
| See where things stand | Order, project, case or shipment status with history | Status kept current in your internal system |
| Get documents | Invoices, statements, reports, certificates, contracts | Documents stored in a structured way, tagged per client |
| Ask for something | Service requests, quotes, changes, with tracking | A team and a process that answers within a stated time |
| Pay | Outstanding invoices, online payment, receipts | Accounting data and a payment provider |
| Approve | Quotes, designs, timesheets, change requests | A clear record of who approved what and when |
| Book | Appointments, deliveries, resources | Real availability from your scheduling |
| Manage their own account | Users, addresses, contacts, preferences | Rules about who at the client may change what |
| Find answers | Guides, frequently asked questions, announcements | Someone who keeps the content current |
A first release with two or three of these, done properly, is worth more than all eight done thinly. Our client portal requirements checklist helps you choose and records the result.
Accounts, roles and what each person sees
In business portals, the client is a company and the users are people. Getting that structure right early avoids the most painful rework.
- 01
How do people get an account?
Why it mattersBy invitation from your staff, by invitation from an administrator at the client, or by self-registration that you approve. Open registration is rarely right for business data.
- 02
Can one client have several users with different rights?
Why it mattersA finance contact who sees invoices, a site manager who sees only their site, an administrator who manages the others.
- 03
Can one person act for several clients?
Why it mattersConsultants, brokers and group companies often need to switch between accounts.
- 04
Who removes a user who has left the client?
Why it mattersIf the answer is nobody, former employees keep access. Give the client's administrator the means and the responsibility.
- 05
How do people sign in?
Why it mattersEmail and password with a second step, a one-time link, or the client's own corporate sign-in for larger customers.
- 06
What do your own staff see and do?
Why it mattersSupport staff often need to view the portal as a given client does, with that access recorded.
The portal is a window onto your systems
Almost nothing in a portal originates there. Statuses come from an operations system, invoices from accounting, documents from a file store. The portal's quality is therefore the quality of those sources, put in front of every client. An order status that staff update late is merely untidy internally. In a portal, it generates the phone calls the portal was meant to remove.
- 01
List each item shown and its source
For every field on every screen, name the system it comes from and who keeps it accurate.
- 02
Decide how fresh it must be
Some data can be copied on a schedule. Balances and availability usually need to be read at the moment of asking.
- 03
Decide what clients may change
A change of delivery address is simple to offer and has consequences downstream. Define which changes apply at once and which become requests for staff to confirm.
- 04
Translate internal language
Internal status codes mean nothing to clients. Agree a short set of client-facing statuses and map the internal ones onto them.
- 05
Plan for a source being unavailable
The portal should say plainly that information is temporarily unavailable, and not show stale data as current.
A worked example
A portal for a testing laboratory
This example is invented to show how purpose shapes scope. A materials testing laboratory answers calls all day from construction clients asking whether results are ready.
- PurposeA two-week log shows that 7 in 10 calls ask for sample status or a copy of a certificate. Those two become the first release.
- FeaturesA list of samples with status, downloadable certificates, and a notification by email when a result is issued. Online payment and sample booking are noted for later.
- AccessEach client company has an administrator who invites colleagues and may restrict a user to particular projects. Laboratory staff can view any client's portal, and each such view is logged.
- SourcesStatus and certificates come from the laboratory system. The nine internal statuses are mapped to four that clients see: received, in testing, under review, issued.
- AdoptionEvery certificate email now carries a link to the portal. Reception staff are asked to offer an invitation to each caller.
Status calls fall as clients learn that the portal answers faster than the phone. The laboratory discovers that the under review step was the real delay, and addresses it, which no portal feature could have done.
Security, privacy and adoption
A portal puts client data on the internet behind a login. The essential safeguard is that every request is checked on the server against what that user is allowed to see, so that changing a number in an address can never reveal another client's record. Ask for this to be tested deliberately, along with protection of sign-in, session time limits, a record of who viewed and changed what, and encrypted storage of documents.
A portal clients adopt
- It answers their most frequent question at once
- They are invited personally, with a reason to sign in
- It works well on a phone
- Notifications bring them back when something changes
- Staff use it too, and refer clients to it
A portal that stays empty
- Launched with an announcement and nothing else
- Shows less than a phone call would reveal
- Data is often out of date
- Sign-in is laborious or frequently fails
- Staff keep sending the same information by email
Requirements checklist
Client portal requirements checklist
0 of 11 checkedWhat to do next
Begin the request log tomorrow. It costs nothing, it settles arguments about scope and it gives you a baseline against which to judge the portal later. If you are weighing a ready-made product, our comparison of a custom portal and SharePoint may help.
Our client portal development page shows how we build portals, and the solution pages for a tenant service portal and a manufacturing dealer portal show two worked through in detail. Tell us what clients ask you for most.
Common questions
What is the difference between a client portal and a website?
A website shows the same public information to everyone. A portal shows each signed-in client their own data and lets them act on it: see an order, download an invoice, raise a request. The two often share a design and a domain, and a portal usually sits behind a login link on the main website.
Should we build a custom portal or use a ready-made product?
Ready-made portal features in help desk, accounting or document tools work well when your needs match what they offer. A custom portal is justified when information comes from several internal systems, when access rules are specific to your business or when the experience is part of your service. Check first what your existing software already provides.
How do we get clients to use the portal?
Give them a reason at the moment they need something. Put portal links in the emails you already send, invite each client personally, make sure the first sign-in is easy and have staff answer requests by pointing to the portal. Usage follows usefulness, so the first release must answer a question clients really ask.
Is a client portal secure enough for confidential documents?
It can be, when built with care: access checked on the server for every request, strong sign-in with a second step, encrypted storage and transport, time-limited sessions and a log of activity. Have the access controls tested by someone independent before launch. A portal is generally safer than sending the same documents as email attachments.
Do we need a mobile app for the portal?
Usually a well-made responsive web portal is sufficient and far cheaper to maintain. Consider an app if clients use the portal daily, need notifications on their phones, work without a connection or use the camera heavily. Many businesses launch on the web, watch how clients use it and decide on an app with evidence.