Customers keep asking for status, files, and invoices. Do we need a portal?

The question isn't really "portal or no portal." It's "why can't the customer get this without asking us?" Answer that first and the software choice usually makes itself.

Here's what I'd do first. I'd pull the last twenty or thirty customer requests and sort them into three piles: the answer already existed and they couldn't find it, the answer existed but lived in a tool they can't see, and the answer didn't exist yet because nobody had updated it. Each pile points to a different fix, and only one of them is a portal.

Sort the requests before you pick the software

"What's happening with our project?" "Which file is the latest?" "Can you resend the invoice?" These messages are your best evidence. Each one tells you where a customer couldn't finish a task on their own.

For each request I write down four things: what the customer was trying to do, where the answer already lived, why they couldn't reach it, and what a staff member did to help. That takes about an hour for a month of requests, and it usually settles the argument.

If the invoice was already sitting behind a working payment link, the fix is a clearer email, not a login. If the status was stale because nobody updated it, a portal would just show stale information faster. If the customer needed a file from one tool and an approval from another, the missing piece is a connection between tools, and maybe a single place to start.

Walk through the customer's afternoon

Picture a customer with five minutes between meetings. They want to check where things stand, grab a file, pay an invoice, or approve a change. They are not there to admire your dashboard.

I built the worksheet below so you can pick the tasks your process handles badly and see what each one demands behind the screen. A status needs someone whose job is to keep it current. A file needs an account relationship and a version. An approval needs the right decision-maker and a record of exactly what they approved.

Try leaving only billing unresolved. The recommendation points at your existing billing platform's portal, because that's usually the right answer. Then add approvals for a customer team where not everyone can sign off. The scope changes, because now you're dealing with identity, authority, and workflow, not a prettier screen. Finally, remove the operations owner and watch the recommendation stop. A customer-facing screen with nobody behind it goes stale in a month.

The three honest answers

Improve the path you already have. The capability works, but customers can't find or trust it. I fix the confirmation email, make one reliable project link, name files so the current one is obvious, and tell the customer what happens next. This is the cheapest fix and, more often than people expect, the right one.

Connect the tools you already pay for. Each task has a reasonable home, but the handoffs are bad. Payments stay in the billing platform, files stay in the document system, and I give the customer one clear starting point with consistent accounts across them. The important decision is which system owns each fact, so the connection doesn't create two versions of the truth.

Build a tailored portal. The customer task and your operating process can't be served well by anything on the market. Approvals tied to a specific version, entitlements that differ by account, roles that change mid-project, or a process that crosses systems in a way the customer should never have to understand. This is where custom work earns its cost.

These aren't stages every business grows through. Keeping a good existing tool can be the permanent answer. When I recommend a build, it's because the evidence from your requests points there, not because building is what I sell.

Stripe's customer portal is a good example of the middle option. It handles payment details, invoices, and subscription changes within its configuration limits, so I don't rebuild billing screens. It does not hold your project files, delivery status, or bespoke approvals, and I don't pretend it does. Stripe's customer portal documentation

Design the staff view at the same time

Every portal has two experiences. The customer wants to finish a task. Your team wants the information to stay correct and the exceptions to get handled. Design only the first and the second gets painful fast.

Take project status. The customer sees "Waiting for your approval," the item that needs a decision, and the next step. Your team needs to see who requested the approval, which version is waiting, who's allowed to approve, and what happens if nobody responds by Friday.

For files, the customer needs to recognize the current document. Your team needs to replace a file without breaking the link, keep the right history, and fix an upload that went to the wrong account. For invoices, the customer needs a trustworthy amount and status, which means the portal reads from the actual billing record instead of a "paid" badge someone updates by hand. That badge turns into a second accounting system faster than anyone expects.

My rule: write one exception beside every main task before we design a screen. The exception is where the real work lives.

Make access part of the task

A portal has to answer who can see which account's information and who can take each consequential action. One customer might have an owner, a billing contact, and a team member who can look at files but can't approve spending.

I document invitation, acceptance, role changes, switching between accounts, removal, and recovery. What happens when their employee leaves? When a shared inbox changes hands? When someone loses access on a Friday afternoon? Your staff need a safe way to help without exposing another customer's records.

Hiding a button isn't security. The server has to check permission every time information is requested or changed. Before launch I test with separate fictional accounts and roles, including a direct request for something that belongs to a different customer. The expected result is nothing.

The worksheet above doesn't enforce any of this and doesn't touch customer data. It helps you name the rules a real build has to prove.

Prove one complete slice first

Pick a task with a clear finish. "A customer can see their latest approved file and download it" is testable. "A customer dashboard" isn't.

I build that one slice with realistic content: a long file name, an older version, a customer with no files yet, a person who can view but not approve. I test it on a phone, then I test the staff side: upload, replace, remove someone's access, fix a mistaken assignment. Then I hand both sides to someone who didn't design it and watch where they hesitate. Those hesitations get fixed before we add a second module.

A portal that makes one important task reliable is worth more than an attractive collection of half-finished features. It also gives whoever signs off something concrete to judge before approving the rest.

For planning, a focused improvement like clearer emails or a connected billing link sits in my $1,000–$3,000 range. A custom portal with accounts, files, approvals and a staff side is a system, and my systems range is $8,000–$20,000+. Those are planning ranges, not a quote; the scope sets the price. Pricing