Before you build a customer portal: five questions to answer first
Theoretical Enterprises · October 9, 2026 · 6 min read
Customers call to ask where their order is, whether an invoice was paid, and when the crew is coming. A portal is supposed to answer those questions so your staff do not have to. Whether it actually does depends on five decisions that are usually made too late, after the screens are designed.
What will customers stop calling about?
The job of a portal is defined by the calls and emails it removes, not by the features it has. Before anything is designed, list the ten reasons customers contact you in a normal week and count them. Order status, a copy of an invoice, a document they signed, a reschedule, a balance. The top three on that list are the first screen. Everything else waits.
If the list is short and the counts are small, you may not need a portal at all. An automatic status email at the right moment often removes the same calls at a fraction of the cost.
Where does the data live, and who owns it?
A portal shows customers your data. If the order system and the ledger disagree about a balance, the portal shows the disagreement to the customer, in writing. That is why the real work of a portal is usually the integration behind it, not the screens in front.
Decide which system owns each fact the portal displays. Orders live in the order system, invoices and balances in the ledger, documents in one store. The portal reads from the owner and never keeps its own copy that can drift.
What can a customer change, and what happens when they do?
Reading is easy. Actions are where portals get expensive, because every action needs a path into your systems and a person who finds out.
- Uploading a document: where does it go, who is told, what happens if it is the wrong one?
- Rescheduling: does it move the appointment in your scheduling system, or create a request someone has to act on?
- Paying: which invoice is it applied to, and how does the payment reach the ledger with the right reference?
- Approving a quote or a change: what record proves they approved it, and when does work start?
How will customers sign in?
Passwords are the fastest way to generate support calls. A link or a one-time code sent to the email address already on the customer record is simpler for them and removes a database of secrets from your side. Tie the login to the customer record itself, so one customer with three contacts sees one account, and give staff a way to see what a customer sees when they call for help.
Who will keep it alive?
A portal is a product your customers use every week, which means someone has to own it. Before building, decide who can change the text, who is told when an integration fails, who adds a new document type, and what the first month of changes will probably be. Then build small: one audience, the three jobs from the first question, and a plan for the rest.
A portal that answers one question well beats one that does twelve things badly.