“Did you receive the documents?” “What stage is my order at?” “Could you send the invoice again?” If your team regularly answers these questions, there is a reason to consider a customer portal. Recurring questions alone, however, do not justify commissioning software.
A portal is useful when customers return to a task: checking progress, adding information and completing the next step. If they only need to submit an enquiry once, start with a usable form. If they simply need updates about an order, notifications may be enough.
Here is how to distinguish those situations, estimate the workload and choose a first version customers will actually use.
Identify a task customers can complete themselves
Consider a hypothetical equipment installation business. After the initial enquiry, the customer sends photographs of the premises, approves a quotation and chooses an installation date. Documents sit in email threads, the account manager tracks progress and another employee confirms the appointment.
A useful portal answers three questions: what has been received, what is missing and what happens next. For example: “Photographs received. Please add the room dimensions so we can prepare your quotation.” The customer uploads a file and sees confirmation.
A welcome screen with a “Contact your account manager” button changes little. Before discussing design, complete this sentence: “After signing in, customers will be able to…” If you cannot finish it, the benefit of an account is still unclear.
Check where the portal will get the correct status. If the account manager has to phone colleagues to find out, first agree where updates are recorded and who maintains them. A new screen cannot resolve an unclear internal process.
Review enquiries from an ordinary working week
Take a week without an unusual spike in demand. Record what each customer asked, where the answer was stored, how long the response took and whether the customer could have completed the action independently.
Separate “check the status” from “discuss a change to the order”. The first often suits self-service. The second may still require a conversation.
| Recurring request | What to try first |
|---|---|
| Questions before purchasing | Clear service information and a form |
| Requests for status updates | Notifications from the operational system |
| Requests for another invoice copy | Your payment service's portal |
| Additional files, approvals and returning to an order | A portal with history and a next action |
This is a planning aid, not a threshold based on enquiry volume. Even an infrequent process may justify a portal if errors are costly. A large number of simple questions might be addressed by a clearer order confirmation email.
Your existing service may already include a portal
Needing self-service does not automatically mean needing custom software. Check the tools your company already uses.
For example, Stripe Customer Portal lets customers manage billing details and subscriptions and view or download invoices. Available actions depend on configuration and subscription type; the documentation lists limitations. This is an example of an existing capability, not a recommendation to switch payment providers.
For our hypothetical installation company, billing covers only part of the task. It does not replace collecting photographs and arranging installation. Compare options using one complete scenario, including an exception: a customer uploads the wrong file, reschedules or acts on behalf of a company.
Custom development becomes worth considering when a critical process cannot reasonably fit an existing service and workarounds keep returning employees to manual work. Our website or web application guide explains the broader choice.
Estimate available time before calculating payback
Start with the workload:
Monthly enquiries × minutes per enquiry ÷ 60 = working hours.
Suppose our hypothetical company handles 240 recurring enquiries each month, taking five minutes each. That is 20 hours. If a portal removes half of those contacts, it frees ten hours a month. The 50% reduction is an assumption to test in a pilot.
Now include portal administration. If supporting users and keeping information current takes three hours a month, seven hours remain. That is not a promised reduction in payroll: employees may use the time elsewhere while company spending stays unchanged.
For a financial comparison, collect setup or development costs, recurring fees, integrations, support and future changes. Do not calculate payback using all 20 hours: some questions will remain, and the portal creates work of its own.
If the project only makes sense under optimistic assumptions, start smaller. For this company, that could mean a missing-document notification and secure upload before building the full portal.
Make the first version cover one complete task
Customers should be able to sign in and reach a clear result. For the installation example, that means viewing a request, seeing missing materials, uploading a file and receiving confirmation. Provide a way to get help when their situation does not fit.
Ten years of order history, a loyalty programme and a separate chat are not essential simply because other portals offer them. Each feature should address an observed request or an operational requirement.
Access control cannot wait for a second phase. Signing in and being allowed to open a particular document are separate checks. OWASP recommends checking permissions on every request. Ask whether one customer could obtain another customer's file through a forwarded direct link.
Also assign responsibility for granting and revoking access, recovering from failures and helping users who cannot sign in.
Measure completed tasks rather than registrations
Invite a small group of customers to complete a real task. Can they submit the required document, understand the next step and proceed without calling an employee? Account registrations alone do not answer those questions.
Compare repeat contacts per request before and during the pilot. Account for order complexity and include questions about the portal itself. If customers still ask for updates, the cause may be stale information or unclear stage names.
An initial brief needs five points: who the customer is, which task they return to, what they should do independently, where current information lives and how you will judge improvement.
Bring that brief and a few anonymised recurring enquiries to a web application discussion with LindenTech. They provide a concrete basis for comparing an existing service with a custom portal.