Customer portal: what it should contain and when it pays off

"What is happening with my ticket?" is the question a help centre cannot answer. The help centre knows what applies to all customers; it knows nothing about this customer's ticket, order or invoice. That is the gap a customer portal fills. This article covers what a customer portal is, when it pays off, what it should contain, how login should work and what the customer should not see.

What is a customer portal, and how does it differ from the help centre?

A customer portal is the logged-in part of self-service, where the customer sees and does what concerns them: their tickets, their conversation with you, their orders, invoices or agreements. The help centre is the open part, with answers that apply to everyone. The two complement each other: the help centre answers "how do I make a return?", the portal answers "where is my return?".

Many companies call it "My account" or "My pages". The name matters less than the content. What matters is that after logging in the customer gets answers about their own details without asking a person, and that what the customer sees is the same thing customer service sees, minus the internal parts.

When does a customer portal pay off?

When customers return and a large share of the questions concern the customer's own details rather than how something works. That applies to subscriptions, B2B customers with recurring orders, services that run over time and online stores with many repeat buyers. A shop that sells one item once to a customer gains little from a portal; a company with a hundred recurring customers who each call about the invoice gains a lot.

The demand exists. According to McKinsey, roughly a third of B2B buyers want digital self-service at every stage of the purchase, a third want in-person contact and a third want remote contact. That does not mean everyone wants a portal, but that a third of customers prefer to resolve their matter themselves when they can. Salesforce reports that 61 per cent of customers prefer self-service for simple issues, and that 80 per cent of the best-performing service organisations offer self-service, against 56 per cent of the worst-performing.

Three signs in your own inbox tell you it is time:

1. A large share of the questions are status questions about the customer's own ticket, order or invoice.
2. The same customer asks several times about the same thing, because nothing shows that anything is happening.
3. Customer service spends time resending invoices, confirmations and details the customer has already received.

If so, the portal is not a convenience but the thing that removes a ticket type. How to measure self-service in general is covered in the article on why the help centre goes unused.

What should the customer portal contain?

What the customer asks about, in the order the customer asks. Start with the tickets; they are the one thing almost every company has and almost every customer wonders about.

The tickets and the conversation are the core, and they must be the same tickets customer service works with in its ticketing system, not a copy that is updated now and then. Orders and invoices require connections to the business system and the payment provider; how the question "where is my order?" is built away with such connections is covered in the article on order status questions. What the customer does in the portal, such as creating a new ticket or replying in an ongoing one, should land with the same agent an email would have.

How should login work?

Easy enough for the customer to bother, secure enough for the personal data to be protected. The two requirements do not conflict if you avoid passwords.

Swedish customers are used to identifying themselves digitally. According to Internetstiftelsen's Svenskarna och internet 2025, 95 per cent of Swedes use an e-identification, in practice mobile BankID, and 76 per cent use a digital mailbox. What the customer is not used to is yet another password for yet another portal. Passwords are forgotten, reset and reused, and "I can't log in" becomes a new ticket type the portal was meant to remove.

Two routes work. A one-time link to the customer's email address, which logs them in directly and expires after a short time, suits most companies: the customer has already shown they own the address, and there is no password to leak. BankID, the Swedish e-identification, suits cases where the data is sensitive or the customer should be able to do binding things, such as cancel an agreement.

Security should be in proportion to the data. The Swedish Authority for Privacy Protection, IMY, states that username and password are often not sufficient protection, that further factors should be added when the data requires it, and that both successful and failed logins should be logged. Short sessions, login links that expire and a log of who logged in are the minimum.

What should the customer not see?

Everything that is internal: notes between colleagues, AI drafts that were never sent, and raw data from your integrations. The portal shows the customer's side of the ticket, and the boundary must be technical, not an instruction to staff not to write anything unsuitable.

It is also a data protection question. Every detail shown in the portal is a detail that can leak if the login is abused, so show what the customer needs and no more: the order number and status, not the whole customer record from the business system. A customer who wants everything you hold about them should go through a subject access request, as described in the article on GDPR requests, not through a portal that happens to show too much.

Supportifier's customer portal is built on that principle: the customer logs in with a one-time link and no password, sees their tickets with status and the whole conversation, and never sees internal comments, reply drafts or customer data from integrations. The tickets are the same ones the team works with in the inbox.

How do you measure that the portal relieves the team?

Measure the share of status questions in the inbox before and after, the share of customers who log in instead of asking, and how many tickets are created through the portal instead of by email. Those three show whether the portal is used and whether it removes what it was meant to.

• Share of status questions. "What is happening with my ticket?", "have you received my return?", "can you resend the invoice?" as a share of all tickets. It should fall month by month.
• Logins per open ticket. If customers log in to follow the ticket, they stop asking. If nobody logs in, the portal is hard to find, hard to log in to or empty of what the customer wants to know.
• Tickets via the portal. A ticket created while logged in arrives with the customer's identity and history from the start, and saves one round trip per ticket.

Also compare resolution time for tickets started in the portal with those that arrived by email. If the portal's are faster, you have an argument for steering more customers there.

What to do

1. Count the status questions in the inbox for a week: ticket, order, invoice, details. That is the portal's table of contents, in priority order.
2. Start with the tickets. Status, next step and the whole conversation, connected to the same tickets customer service works in.
3. Choose login without passwords: a one-time link for most, BankID if the data is sensitive.
4. Draw the boundary technically for what the customer sees. Internal notes and raw integration data must not be shown by mistake.
5. Link the portal where the question arises: in the ticket confirmation, in every reply from customer service and in the help centre.
6. Add orders and invoices once the tickets work, one connection at a time.
7. Follow the share of status questions every month. In Supportifier the customer portal is part of the same ticketing system as the inbox, so the customer follows the same ticket the agent sees.

Common questions

Does a small company need a customer portal?

Only if customers return and ask about their own details. An online store with one-off buyers gains more from good notifications and a help centre. A company with subscriptions, recurring orders or ongoing services benefits from a portal already at a few hundred customers, because the status questions otherwise grow with the customer base.

Should the customer log in with a password or BankID?

Preferably neither for ordinary tickets. A one-time link to the customer's email address removes the passwords and the questions about them. BankID is right when the data is sensitive or the customer is doing something binding, such as cancelling an agreement or changing payment details. Passwords are the worst option: forgotten, reused and a source of tickets of their own.

Can the customer see internal comments in the portal?

Not if the portal is built correctly. Internal notes, AI drafts and data from integrations should be technically separated from what the customer sees, not merely hidden by a routine. Check it before you switch the portal on by logging in as a test customer and trying to find what should not be visible.

Does the customer portal replace the help centre?

No, they answer different questions. The help centre answers what applies to all customers and should be open to everyone, including search engines. The portal answers what applies to one customer and sits behind a login. Link between them: from the ticket in the portal to the article that explains, and from the article to the portal when the question concerns the customer's own ticket.

Sources

• The new B2B growth equation — McKinsey, read 2026
• Latest Customer Service Statistics To Move Your Business Forward — Salesforce, read 2026
• Användning av internet och e-tjänster, Svenskarna och internet 2025 — Internetstiftelsen, 2025
• Autentisering — Swedish Authority for Privacy Protection, read 2026