Customer Portals: When Your Business Needs One and What to Budget For

What a customer portal really means for your budget

A regular website is a shop window: you present information, a visitor reads it and sends an enquiry. A portal is a service. Every user has their own state, their own data, their own permissions. Suddenly you need sign-up, login, password recovery and storage of personal data.

That's why a portal costs several times more than a Services page of the same size. It isn't the design - visually a portal can be plain. The expensive part is the logic: who sees what, what happens when something fails, what happens when someone loses access to their email.

So the first question isn't what it will look like. It's what work it takes off your people.

When a portal is genuinely worth it

There's one reliable signal: you get the same requests over and over, and a member of staff manually digs out data the customer could have looked up themselves.

Count how many times last week someone on your team answered "where's my order", "send me the statement", "how many sessions do I have left", "can you repeat that same order". If it's dozens of requests a week and they eat hours, a portal pays for itself. If it's five and they all come from one client, it's cheaper to hire an assistant or build a decent documents page.

The second case is when the service simply doesn't work without one. Online courses, subscriptions, B2B ordering at negotiated prices, a service with a history of tickets. Here the portal isn't an improvement, it is the product.

• Customers come back regularly rather than buying once in a lifetime.
• Different customers have different prices, terms or paperwork.
• Data accumulates: order history, payments, balances, progress.
• Staff manually forward the same files and status updates again and again.

When you don't need one and should save the money

If the purchase is a one-off - a home renovation, new windows, a wedding shoot - a portal is almost never worth it. Nobody signs up for a single transaction, and you end up with a database of dead accounts plus the obligation to protect personal data.

Another common situation: few customers, but each one large. Five corporate clients are perfectly well served over messaging and email, and a real account manager matters more to them than an interface. Here a Telegram bot or automated status updates solve the problem faster and cheaper: the bot messages the client directly, no sign-up needed.

One more motive worth checking: "our competitor has one". Go and look at what's actually inside their portal. If it's an empty page with the customer's name and a Change password button, you're copying somebody else's bad spend.

What to settle before the quote

Most disputes over portals aren't caused by code. They're caused by work nobody discussed. Go through this list with your developer and ask for each point to appear as its own line in the quote.

Ask about roles separately and in detail. "Customer and admin" is two roles. "Customer, customer's employee, account manager, accountant, admin" is five, and the effort multiplies, because for each role someone has to decide what it sees and what it can change.

• Roles and permissions: who sees which data, who can edit, who can delete.
• Login: email and password, a code by SMS, sign-in through a messenger - each method is a separate piece of work.
• Access recovery: what a customer does when they lose their password, and what your staff do when the email is gone too.
• Notifications: which events trigger an email or message, and to whom - the customer, the manager, both.
• Admin tools: how you create a customer, block access and fix data yourself without pinging the developer.
• Action logs: who changed an order or an amount, and when. Without this you can't investigate a dispute.
• Personal data: where it's stored, who has access, how consent and your privacy policy are handled.
• What happens when things fail: a payment declines, a file won't upload, an integration is down.

Integrations - where quotes usually tear

A portal almost always has to pull data from somewhere: stock levels from your accounting or ERP system, payments from a payment gateway, deals from your CRM. This is where timelines and budgets slip most often.

Before anyone estimates, ask the owner of that system whether there's a working API and documentation. If data has to be exported as scheduled files, that's a different architecture and a different price. And if staff end up entering data by hand in two places, the portal won't save time, it will add work.

A useful trick: ask the developer to describe, in one paragraph, where every number the customer sees on screen comes from. If there's no answer for one of them, you've found a future problem before paying for it.

How to order one without overpaying

Start with the single scenario that saves the most. Usually that's order status and history plus document downloads. That alone removes the bulk of the calls.

Ask for the quote as a list of screens and features, not one line reading "customer portal". One line with a big number isn't a quote, it's a number. With a list, you can cross out yourself whatever you won't use in the first year.

And agree on support up front. A portal is a living system: certificates expire, partner APIs change, new data requirements arrive. A brochure site can sit untouched for years. A portal can't.

• Collect the actual customer requests from a two-week period - that's your brief.
• Define the roles before the design, not after.
• Split the work into stages: launch with one scenario, then extend based on real usage.
• Check who will hold access to the server, the database and the code. "The developer" is not an acceptable answer.