Give customers a login, not another email address

Every business has a number it never measures: how much of the working week is spent answering questions customers could have answered themselves.

It does not look like a cost, because it arrives as email. Nobody schedules it. It just sits in the middle of the day, in ten and fifteen minute pieces, being handled by whoever is nearest — and in most small businesses that means somebody senior, because the answer usually requires looking in two systems.

That is the case for giving customers a login. Not because portals are modern, but because an inbox is a queue, and a queue has a person standing in it.

What the inbox is actually costing

Count it properly and the number is uncomfortable. Take a business with 300 active customers where each one asks something roughly twice a month. That is 600 enquiries.

Most are not hard. "Where is my order." "What did we agree the price was." "Can you send that certificate again." "When are you next in." But each one takes a person out of what they were doing, into a system, sometimes into two, back into email, and then out again.

Eight minutes each including the interruption is generous rather than pessimistic. That is 80 hours a month, or roughly half a full-time person, at an internal cost of £45 an hour:

Run your own version of that with your own numbers before you go any further. If the answer is small, stop reading — a portal is not your problem. The rest of this is for businesses where the number is large and invisible.

Why most portals go unused

Plenty of businesses have built one, and a lot of those portals are dead. The pattern is consistent, and it is the same one that kills dashboards: the thing was designed around what was easy to display rather than what someone actually needed.

A portal fails when it shows a summary the customer did not ask for, when the information behind it is a week old, when getting in requires a password nobody can find, or when the answer to the customer's real question is still "email us". Any one of those and they go back to email, permanently. You do not get a second first impression on a login screen.

The successful ones are narrow and boring. They answer four questions completely rather than twenty partially, they are current to the minute, and they never bounce the customer back into a contact form.

Start with the inbox, not the design

Here is the whole of version one, and it starts with evidence rather than opinion.

Export your last two hundred inbound customer emails. Sort them by what was really being asked, not by subject line. Count each group. In almost every business four or five groups account for more than half the volume, and they are the same four or five you would have guessed — but now you know the order, and the order is what you build in.

Then, for each question, write down the honest answer to two things: which system holds the answer, and how current it is. That second column is where portal projects die. A status that updates when someone remembers to change it is not a status; publishing it to a customer just moves your internal data quality problem somewhere far more visible.

What version one should contain

For most businesses, four things:

• Current status of anything live. Order, job, case, application — whatever your unit of work is, with the actual stage and the date it changed. This alone typically removes the largest single category of email.
• Documents. Invoices, statements, certificates, reports, signed agreements. Self-service on documents is the cheapest win available, because re-sending a document is pure cost with no judgement in it.
• The money position. What is owed, what has been paid, what is due next. Read-only is fine to begin with; taking payment can come later and is a separate decision.
• History. What has been ordered, done or agreed before. Customers ask this more than businesses expect, and the answer is usually a database query rather than a person searching their sent items.

What version one should not contain: a dashboard of charts, a messaging system that duplicates email, a knowledge base nobody will read, or any screen whose purpose is to demonstrate that the portal exists.

The integration is the project

The screens are not the hard part. The hard part is that the four answers above usually live in three or four different systems, and the portal has to read all of them without anyone typing anything twice.

So the feasibility check happens before the design, not after it. For each system holding an answer, establish three things: is there an API, is it read-capable for the data you need, and how fresh can the portal's copy be. A system that only produces a nightly export is not disqualifying, but it does change what you can promise — "as at close of business yesterday" is an honest label and a live-looking screen showing yesterday's data is not.

This is also where a portal quietly improves the rest of the business. Nothing exposes weak internal data like showing it to the customer who is described by it. Statuses that were approximately maintained become properly maintained within a fortnight, because now somebody outside the building can see them. Our note on why integrations break covers the failure modes worth designing for before this goes live.

Login is a design decision, not a technicality

More portals are killed by the front door than by anything behind it. Passwords that people forget, invitation emails that go to spam, an account someone set up two years ago in a name they no longer use.

The lowest-friction pattern for a small business is usually a magic link: the customer enters their email, gets a one-time link, and is in. No password to store, none to reset, and the identity check is the same address you already invoice. Where a shared inbox is involved — which is normal for business customers — allow more than one person per account rather than forcing them to share one login, because a shared login is how access outlives the person who left.

And meet them where they already are. A link in the invoice email, a link in the order confirmation, a link in the appointment reminder. Nobody bookmarks a portal.

How to tell whether it worked

One measure, and it is the same one that justified the build: inbound enquiry volume in the categories the portal covers. Count it for a month before launch and the same month after. If those categories have not fallen, the portal has not answered the question the customer was actually asking, and the fix is content rather than design.

Two supporting numbers are worth watching. Repeat logins tell you whether it became a habit or a novelty — first-time use is easy to buy with an announcement email, second use has to be earned. And the proportion of active customers who have ever logged in tells you whether the front door works, because a portal used by 15% of customers is not a portal, it is a pilot.

Expect the enquiry volume to fall in steps rather than smoothly, and expect a category you did not build for to become the new largest one. That is the portal working. Add it in version two.

When not to build one

Three cases where the answer is no, and they are worth saying plainly.

If your enquiry volume is genuinely low, the arithmetic at the top of this article does not clear the cost of building and maintaining another system. If your underlying data is not reliable enough to show anybody, fix that first — publishing bad data to customers is worse than answering the phone. And if a portal already exists inside a system you pay for and it covers your main questions, turn it on. Buying beats building whenever one system already holds all the answers; building earns its place when the answers are spread across several, which is exactly the case no vendor's own portal can solve. That trade-off is the subject of whether custom software is worth it at your size.

Common questions