How to use it
- 01
List what customers ask for
Begin with the questions your team answers every week. Each recurring question is a candidate for something the portal should show, and together they tell you what the first version must contain.
- 02
Decide access before features
Work out who is allowed in and how users inside one customer company relate to each other. Portals that skip this end up with shared passwords, which defeats most of the benefit.
- 03
Mark see and do separately
Showing information is cheaper than letting customers act on it. Give each line its level, and expect the need column for actions to be shorter than the one for information.
- 04
Name the source systems
For everything marked need, write down where that information lives today. A line with no clear source is a project inside the project, and better known now than later.
What a portal requirements list should answer
Whether you build a portal or configure a product, the same questions come up. Answering them in advance turns a vague wish for a portal into something that can be scoped and priced.
| Part | What it settles | Why it matters |
|---|---|---|
| Audience | Which customers and how many users | Sets the scale and the level of support needed |
| Access | How accounts are created and protected | Security and administration effort both follow from it |
| Information | What customers can see | Each item needs a reliable source behind it |
| Actions | What customers can do themselves | Actions write back to your systems, which adds risk and work |
| Sources | Where the information lives today | Integration is usually the largest part of a portal project |
| Operation | Who runs it, in which languages, by when | A portal nobody administers decays within a season |
A worked example
A testing laboratory answering the same four questions
The example is an invented environmental laboratory. Load it to see the full checklist. Its customers ask four things again and again, and the list follows from them.
- SeeSample status, reports and invoices are marked need. They answer three of the four recurring questions without a phone call.
- DoBooking a collection, uploading site documents and updating details are needed now. Paying invoices online can wait until the first version has proved itself.
- SourcesResults sit in the laboratory system, invoices in accounting, reports in folders. Three sources, which is the honest measure of the project's size.
The first version is small: invited users, three kinds of information and three actions. It would still remove most of the calls the customer service lead takes each week.
What this tool does not do
The checklist makes sure the main decisions are not forgotten. It does not make them for you.
- It does not tell you whether to build a portal or buy one. That depends on your systems and your customers.
- It does not check whether your systems can supply the data. That is established with the people who run them.
- It carries no estimate, because integration effort cannot be judged from a list.
- Nothing leaves your device. The list exists only in this browser until you export it.
What to do with the finished document
Review the list with someone from customer service and someone from IT, since they see different halves of it. If you want our reading of it, send it over and we will reply with a suggested first release. Send it through the contact page or book a 30-minute call and bring it along.
Common questions
What is the difference between a client portal and a customer account area?
Mostly depth. An account area on a shop lets a customer see their orders. A client portal usually serves business customers with several users per company, shows documents and status from your internal systems and lets them act on it. If your needs stop at order history, the account features of your ecommerce platform may be enough.
Should we build a portal or use a ready-made product?
Ready-made portal products and the portal features of CRM and support tools suit many companies. Building makes sense when the information comes from several internal systems, when your workflow is unusual or when the portal is part of what you sell. Our comparison of a custom portal and SharePoint works through one common version of this choice.
Why does the checklist separate seeing from doing?
Because the two differ in cost and risk. Showing a customer the status of an order means reading from a system. Letting them change the order means writing to it, with validation, permissions and an audit trail. Many successful portals begin by showing information well and add actions one at a time.
How many items should be marked need?
Fewer than feels natural. A first version that shows the three things customers ask about most and allows one or two actions will be used and will teach you what to add. A portal that tries to cover everything at launch takes longer, and tends to be right about less of it.