Client portal: what it is, what to include and what it costs

A client portal is a private, logged-in area where each of your customers sees their own information: the status of their orders, jobs or cases, the documents you share with them, their invoices and payments, and a way to ask questions or approve things. It replaces the status emails and phone calls your team answers by hand. A useful first version has five or six features, takes two to four months to build, and is worth building only when clients ask about status often enough that answering them is a real cost.

We build portals as part of our client portals and internal tools work. This guide covers what a portal is for, what to include first, how to keep clients' data apart, and what it costs as of October 2026.

What problem does a client portal actually solve?

Four kinds of work that otherwise land on your staff:

• Status questions. "Where is my order?" "Has the report been filed?" "When does the crew arrive?" Each one interrupts someone who has to look the answer up in an internal system and type it into an email.
• Documents lost in email. Contracts, certificates, drawings, reports and statements live in long threads. Clients lose them and ask again.
• Invoices and payments. What is outstanding, a copy of last quarter's invoice, a way to pay without phoning accounts.
• Approvals. Signing off a quote, a design or a change, with a record of who approved what and when.

The businesses that gain most have repeat clients and long-running work: logistics, manufacturing, professional services, construction and interiors, agencies and B2B distributors.

A portal is not worth building when most customers buy once, when you have a handful of clients who are happy with a phone call, or when your clients will not log in to anything. In that last case, send automatic status updates by email or WhatsApp from your system instead. It is cheaper and they will read it.

What should version one include?

The pattern: show clients what you already know, in one place, and tell them when it changes. Interactive features come after you see how they use it.

Should you buy a portal product or build one?

Buy if what clients need is already inside a tool you pay for. Accounting software such as Zoho Books includes a customer portal for invoices and payments. Helpdesk tools include ticket portals. If invoices or tickets are the whole need, switch that feature on and stop there.

Build when the status clients care about lives in your own systems or across several of them, when the portal needs your process (approvals, site visits, batches, case stages), or when it is a visible part of your service and has to look like it. The broader trade-off is in custom software vs off-the-shelf. Most portals we build read from an existing CRM, ERP or job system through its API rather than replacing it; API integration explained shows how that connection works.

How do you keep each client's data separate?

This is the part that matters most, and the part cheap builds get wrong. Broken access control is first in the OWASP Top 10:2025, the standard list of web application security risks.

The common mistakes:

• Checking that someone is logged in, but not that the record belongs to their company.
• Sequential IDs in URLs, so changing /invoices/1043 to /invoices/1044 shows someone else's invoice.
• File links that work for anyone who has the URL, forever.
• Exports and search results that skip the filters the screens apply.

What we do instead: every request is checked on the server against the client the user belongs to, with access denied unless explicitly allowed. Files sit in private storage and are served through links that expire. Staff and client roles are separate, and staff sign in with two-factor authentication. Every view and download is logged. Before launch, we test with two client accounts side by side and try to reach one from the other. Roles and permissions goes into the access design in more depth.

What does a client portal cost, and how long does it take?

Where the data comes from decides most of the cost.

In money, as of October 2026, a first-version portal falls in the same band as other focused custom tools: ₹4,00,000 to ₹25,00,000 or $10,000 to $60,000, with integrations deciding where in that range. A portal that grows into a full product is a different budget, covered in how much does a web app cost. Running costs are hosting, email and WhatsApp message fees, and maintenance at roughly 15 to 20 percent of the build cost a year.

Set that against the time your team spends answering. If staff field 40 status questions a week at six minutes each, that is four hours a week before anyone does real work. The automation hours-saved calculator turns that into a yearly figure.

How do you get clients to actually use it?

Launching the portal is the easy half. Getting clients to open it takes a few deliberate habits:

• Link to it from every update. Each status email or WhatsApp message points to the exact page in the portal, not the login screen.
• Make signing in nearly free. Invitations and one-time sign-in links beat passwords for people who log in once a month.
• Put the answer on the first screen. The open orders or active jobs, with their status, before any menu.
• Answer consistently. For the first months, staff reply to status emails with the answer and the portal link, every time.
• Watch who never logs in, and call them. Usually there is one simple reason.

Before commissioning anything, count status questions for two weeks: how many, from how many clients, and how long each takes to answer. If the total is under an hour a week, automatic status emails will do. If it is a day a week or more, a portal is likely to pay for itself.