A Customer Portal or Email Threads: When a Portal Reduces Load and When It Is a Shelf

A customer portal sounds like the obvious answer to enquiry load: let the customer log in and see for themselves. In practice, a considerable share of portals built in small businesses go almost unused - customers keep sending email or messages, and now there is also a system to maintain. The difference between the two outcomes is predictable before you build.

What a portal actually solves

Not the need to communicate, but the repetition: the same question, from the same customers, about the same information. Status, documents, balance, history. When that information is available, a share of enquiries disappears.

What it does not solve: questions needing judgement, negotiation, complaints, and anything a customer would rather say to a person. Those keep arriving on the existing channel, so a portal never replaces the channel - it shrinks it.

The deciding variable: frequency

The third row is the common failure. A customer logging in once every three months has forgotten the password, requests a reset, gives up halfway and sends a message - so the portal added a step instead of removing one.

When a portal becomes a shelf

When nothing has to be done in it. A portal that only displays information competes with email, and email wins - it is already open, it has no password, and it is searchable.

So the practical rule is: at least one action of value to the customer exists only there - an approval, downloading an official document, a repeat order, opening a tracked ticket. Without such an action, usage stays low no matter how much internal promotion it gets.

What you can do instead

Proactive updates solve a large share of the problem without a portal: an automatic message on every status change, a document sent when it is ready, and a reminder before a due date. The customer receives exactly what they would have gone looking for, in a channel they are already in.

It is also far cheaper to build and maintain, and the logic of automatic tracking updates is in automatic tracking updates to the customer. In most small businesses that is the real comparison - not portal versus email, but portal versus proactive updates.

What the customer actually wants to see

When you check what customers ask, the answer nearly always narrows to three things: where does this stand, what do I owe, and where is the document. Everything else - history, charts, settings - gets built because it was possible, not because anyone asked.

The practical conclusion is that a minimal portal beats a full one. Three screens answering those three questions deliver nearly all of the drop in enquiries, and are maintained at a tenth of the effort. A richer portal looks more impressive and produces more fields that go stale.

It is also worth noting what not to expose. Internal information - notes, costs, who handled it - does not belong there, not because it is secret but because it invites questions that did not previously exist.

What to check before building

• How many enquiries genuinely repeat the same information, as a number.
• How often a typical customer needs that information.
• Which action will be available only in the portal.
• Who maintains the content, and what happens when it is out of date.
• What happens to a customer who never logs in - they still need service.

The last question is the forgotten one. A portal that becomes the only channel produces customers who fall between the cracks, so it is always in addition to the existing channel rather than instead of it.

What happens to email threads once there is a portal?

They do not disappear, and that is the point most planning misses. Even after a portal goes live, a considerable share of communication keeps flowing through email and messages - and a new state appears: part of the history in the portal and part in a thread, with nobody knowing where something was said.

Two ways to handle it. The first is deciding the portal holds one defined type of information - documents and status, say - and all conversation stays in the channel. The second is routing correspondence into the portal too, which is far more work and only worth it when contact is frequent.

What does not work is leaving it undefined. Businesses that never decided find themselves searching two places every time a customer asks what was agreed, which cancels exactly the saving the portal was meant to produce.

Who maintains the content in the portal

This is the question that decides whether the portal survives a year. Information updated automatically from an existing system stays correct; information somebody has to upload by hand goes stale, and once a customer hits stale information even once they stop trusting the rest.

The practical rule: every field in the portal needs a source. If the source is a person, the field will age - so a portal with three self-updating fields beats one with ten that depend on somebody remembering.

What matters more than the portal itself

The information inside it. A portal showing a status that is not updated in real time is worse than showing nothing - it turns the business into the party that gave wrong information rather than the one that has not answered yet.

So before the portal, the information itself has to be reliable: one source, updated automatically, with statuses reflecting what is actually happening. A business whose statuses are updated by hand is not ready for a portal even when one is technically buildable - and the logic of exposing status outward is in self-service status for customers.

Sources

• Business automation for small businesses in Israel
• Israel Tax Authority - business information