Count what actually arrives
We go through a real month of your enquiries and group them. The top few categories almost always account for most of the volume, and those become version one.
Your website talks to strangers. A portal talks to the people who already chose you.
Behind a login, each customer sees their own orders, invoices, documents and requests — read live from the systems you already run. Built well, it removes whole categories of enquiry rather than individual messages. Built carelessly, it is a security incident with a login page.
Their records, not your pages
Answers at any hour
Permissions before features
Read from your own systems
THE SITUATION
Your team is a search function with a salary.
Where is my order. Can you resend last month's invoice. What time is the technician coming. Each one takes two or three minutes — read it, find the record, write a reply, send it. None of it is difficult, and none of it needed a person's judgement.
It never arrives as a project, which is why it never gets fixed. It arrives as a hundred small interruptions a week, spread across whoever is nearest the inbox, and it quietly sets a ceiling on how many customers you can serve without hiring someone.
SYMPTOMS WE HEAR MOST
The same four questions arrive every single week Customers wait until Monday for something they needed on Saturday Two people give the same customer two different answers Nobody can say how many hours a week this actually takesHOW THE WORK RUNS
Start with the four questions you answer most.
Portals fail when they try to expose everything. The ones that work start narrow and earn their way wider.
Decide who sees what
Which customer sees which record, what a head office user sees versus a site contact, and what nobody outside should ever see. Permissions are designed before anything is built.
Build it against your real data
Authentication, the views customers need, downloads and requests — reading live from the systems you already run, so the portal never disagrees with your own records.
Watch what still arrives
The messages that keep coming tell you what version two should hold. Portals should grow from evidence, not from a wish list agreed in month one.
WHERE A PORTAL SITS
Three layers, and the portal is the middle one.
Almost every argument about whether something is a website or a portal disappears once you see which layer it belongs to.
PUBLIC INTERNET
Business website
Who are we?
Anybody. Mostly people who have never met you.
Awareness, credibility, enquiries.
LOOKS LIKE
About · Services · Projects · Contact · Request a quote
AUTHENTICATED
Portal
What can I access because of my relationship with you?
Known customers, staff, suppliers, partners or members.
Access, manage, transact, self-serve.
LOOKS LIKE
Dashboard · Orders · Invoices · Documents · Cases · Users
INTERNAL SYSTEMS
Your business systems
Where does the work actually live?
Your team, and the software they already run.
Run the business.
LOOKS LIKE
CRM · ERP · Billing · Documents · Support · Project systems
The portal is the window your customers look through. It shows them their own corner of systems they should never touch directly.
This is why a portal is rarely a design exercise. Most of the work is identity, permissions and integration behind the glass.
CONTENT OR CONTEXT
A website publishes. A portal answers about you specifically.
A business website asks what information should we publish. A portal asks who is this person, what are they allowed to see, and what are they allowed to do. Same company, same product, completely different question.
ON THE WEBSITE
Download our product catalogue 2026
One file. Everyone who visits gets exactly the same one, whether they bought from you last week or have never heard of you.
IN THE PORTAL
Your products
Serial no. 839202
Warranty expires 14 Nov 2027
Download your certificate
Request service
None of that exists as a page. It only exists in the context of one customer's relationship with you.
A BUSINESS WEBSITE
A CUSTOMER PORTAL
Who it is for
The general public
Identified customers, staff, suppliers or partners
Login
Usually none
Fundamental — nothing works without it
What each person sees
The same as everyone else
Only their own records, shaped by their role
Where content comes from
A CMS, written once
Several business systems, read live
What people do there
Read, then enquire
Check, download, submit, approve, pay
Permissions
Minimal
Role and organisation based
Search engines
Critical
Irrelevant past the login
Security work
Standard
Significantly higher
Navigation looks like
About · Services · Contact
Dashboard · Orders · Documents · Cases
Measured by
Visits, enquiries, conversions
Tasks completed, adoption, requests avoided
WHY THE WORD MATTERS COMMERCIALLY
Calling a portal a website understates the work by a wide margin.
Authorisation, not just login
Authentication asks who you are. Authorisation decides what you may see and do. Company A must never see Company B's invoices — and inside Company A, finance, engineering and a read-only viewer each need something different. That model is designed before any feature is built.
It has to be right
A brochure page can be approximately true. A balance, a delivery date or a warranty expiry cannot. The portal is only as trustworthy as the systems behind it, which is why we look at those first.
It has to be up
Nobody escalates because your About page is slow. They do escalate when they cannot reach an invoice at month end. Monitoring, backups and a failure plan are part of the build, not an afterthought.
It has to be owned
Someone internally approves access, answers questions about it and keeps the underlying records clean. A portal with no owner degrades faster than anything else we build.
None of this is a reason to avoid one. It is the reason we would rather talk you out of a portal you do not need than sell you one you cannot carry.
NOT ONLY CUSTOMERS
The same pattern, pointed at different people.
Known user, controlled access, relevant information, ability to act. Change who logs in and the name changes, but the build does not.
Customer portal
Orders, invoices, documents, support cases.
The most common, and usually the fastest to pay back.
Employee portal
Leave, payslips, policies, internal systems.
Often called an intranet. Same architecture.
Supplier portal
Purchase orders, invoices, deliveries, agreements.
Removes an enormous amount of procurement email.
Partner portal
Leads, deals, pricing, marketing assets.
For distributors and resellers.
Member portal
Membership status, events, certificates, renewals.
Associations, clubs and professional bodies.
Student portal
Courses, fees, results, schedules.
Education and training providers.
Patient portal
Appointments, reports, secure messages.
Highest bar for privacy and consent.
Citizen or business portal
Applications, payments, licences, submissions.
The audit trail is frequently the whole point.
Admin portal
Users, configuration, oversight, reporting.
The staff side of every portal above.
Buyer type matters less than most people expect. B2B pays back fastest because those customers ask the most lookup questions; B2C is worth it when people come back; B2G is often mandated by procurement.
IS IT ACTUALLY A PORTAL
A login is not a portal. Tick what yours would really do.
Plenty of sites have accounts. That does not make them portals, and the difference decides the budget, the timeline and the security work. Tick every line that would genuinely be true.
NOT A PORTAL
That is a website with accounts.
Nothing here needs a portal. A login that only manages a password is a feature of a website, not a different kind of product. Build the website properly and add accounts if you ever need them.
See website design and buildBORDERLINE
A logged-in area, not yet a portal.
There is real value here, but it is still one or two views rather than a place customers manage their relationship with you. This can often be added to your existing site rather than built as a separate product.
Talk through the smaller optionYES
That is a portal.
Identity, personal records, permissions and things customers can actually do. This is a distinct product with its own security model — and the reason it removes so much work is that it removes whole categories of message, not individual ones.
Talk to SuperchargeYES — AND AN INTEGRATION PROJECT
A portal, and most of the work is behind the glass.
Roles within customer organisations and data drawn from several systems put this firmly in integration territory. The interface is the small part. Identity, permissions and keeping several systems agreeing with each other is the real build, and pricing it as a website would be badly wrong.
Scope it properly with usIf only the first line is true, you do not have a portal — and you probably do not need one.
WHAT YOU ACTUALLY GET
A portal your customers can actually use.
- Enquiry audit — what arrives and how often
- Authentication and account management
- Role and permission model, documented
- Self-service views built on your live data
- Document and invoice downloads
- Requests, approvals and rescheduling
- Notifications and email or WhatsApp alerts
- Full activity log for every action taken
- Integration with your existing systems
- Staff admin view and handover training
HONEST SCOPE
Is this the right thing to buy?
GOOD FIT WHEN
The same lookup questions arrive every week Customers have records with you they cannot see You serve customers across time zones or outside office hoursWAIT, OR DO SOMETHING ELSE FIRST
A handful of customers you speak to constantly anyway — the relationship is the service The data lives in someone's head or a spreadsheet nobody trusts yet Nothing changes between orders, so there is nothing to look upCOMMON QUESTIONS
The things people ask first.
Is this not the same as customer support automation?
They solve the same problem from opposite ends. Support automation answers the question when it arrives. A portal means the question never gets asked, because the customer can already see the answer. Most businesses want both, and a portal usually pays back faster because the volume it removes is predictable.
Do customers actually log in?
They do when logging in is faster than messaging you. If the portal shows less than an email would tell them, they will email. That is why we start with the questions they actually ask rather than a general account area.
Where does the data come from?
Your existing systems, read live. The portal is a view, not a second database. If it held its own copy it would eventually disagree with your records, and the first time it does, customers stop trusting it.
What about security?
Customers see only their own records, enforced on the server rather than by hiding things in the interface. Sessions expire, every action is logged, and permissions are designed before the build rather than added after.
How small can we start?
One capability is a legitimate first version. If order status alone accounts for a third of your inbox, build that, launch it, and let what still arrives decide the rest.
Will our team still be able to help people?
More than before. Removing lookup work does not remove your team from the relationship — it gives them back the hours currently spent copying reference numbers into replies.
Tell us the four questions you answer every week.
That is usually enough for us to tell you whether you need a portal at all, what a first version should hold, and what it would take to build properly.