Web Apps & SaaS
Authenticated products, dashboards and subscription platforms.
Web Apps & SaaS
Portals that answer the questions your team fields.
Many customer questions are simple lookups: where is my order, what am I paying for, when is my appointment. A portal answers them at any hour, without a person.
What is a customer portal?
A customer portal is a signed-in area where customers see and act on their own information: orders, bookings, documents, invoices and requests. It replaces emails and calls that only pass on what a system already holds. Each customer sees only their own records.
01/WHAT YOU GET
What you get.
- A signed-in area for records, documents and requests
- Sign-in with recovery and optional two-factor
- Access rules so customers see only their data
- Dashboards built around real questions
- An admin view of what customers see
- Usage analytics showing how the portal is used
A good fit for
- Service businesses relaying status updates by phone and email
- Companies emailing the same documents and invoices repeatedly
- Teams building the same report by hand every week
02/HOW IT WORKS
How the work runs.
Understand
We start with the questions your team answers, using tickets, the shared inbox and phone logs.
Architect
We decide who sees which records and how that is checked, then what data to show.
Design
Screens follow tasks, with empty, single-item, long-list and failed states designed in advance.
Build
Access checks are in from the first release, and real data sources are connected.
Validate
We try to cross access limits, then check keyboard use, screen readers, contrast and motion settings.
Launch
We set up accounts, a team view of what customers see, and monitoring before inviting customers.
Improve
Usage shows which screens work and which questions still arrive by email, guiding the next release.
03/PROBLEMS
What we fix.
Problem
Your team spends hours answering lookups
What we do
Customers check status, documents and history for themselves, at any hour.
Problem
Documents are lost in email threads
What we do
Invoices, reports and contracts stay in the account of each customer, with access checked on every file.
Problem
The weekly report is built by hand
What we do
A dashboard reads live data, so the numbers are current and the same for everyone.
04/COMPARISON
What changes when customers can self-serve.
| Task | Without a portal | With a portal |
|---|---|---|
| Checking status | An email or call, answered by staff in working hours. | The customer looks it up, at any hour, without asking. |
| Getting a document again | A request, then someone searches their sent items. | It is in the account, permanently, with a history. |
| Rescheduling | A phone call, then a manual calendar change. | Done by the customer inside the rules you set. |
| Reporting | Assembled by hand, weekly, from more than one system. | A live view, the same for everyone who opens it. |
05/QUESTIONS
Frequently asked questions
What is the difference between a customer portal and a dashboard?
A portal is the signed-in area itself: records, documents, requests and account details for one customer. A dashboard is a view inside it that summarizes data to answer a specific question. Most portals contain one or two dashboards; a dashboard on its own, with nothing to act on, is a report with a chart.
Can a portal connect to the systems we already use?
Usually, provided they expose an API, a webhook, a database connection or a scheduled export. What matters as much as the connection is behavior when the other system is slow or unavailable, which we specify rather than leave to fail silently. Integration scope is agreed and quoted rather than assumed.
Will customers actually use a portal?
They use it when it is faster than asking. That means answering the questions they actually ask, requiring no training, working properly on a phone, and being reachable in one step from where they already are. Portals that fail are usually portals that added work rather than removed it.
Should portal pages appear in Google?
No. Authenticated areas are kept out of the search index deliberately, because indexing them exposes structure without value and can leak information. The public pages in front of the portal — what it does, who it is for, how to get access — stay server-rendered and indexable, because those are what people search for.
Can you build a portal on top of an existing website?
Yes. The portal is an authenticated application that can sit alongside your current site, keeping the public pages and their rankings as they are. Whether it shares the same codebase or runs as a separate application is a technical decision we make on the state of the existing site, not a matter of preference.
06/THE FULL DETAIL
The full detail.
Short answers are above. Open a panel below for the specifics: how we decide, what is included and the deeper questions.
What should a customer portal actually contain?
Whatever your team currently relays by hand. The scope comes from support tickets, the shared inbox and the phone log rather than from a feature list, because those records show which questions arrive repeatedly — and a portal that answers the top three removes the repeat work behind them.
The common failure is building everything a portal could contain. A first release covering status, documents and one action is used; a release covering fourteen screens is explored once and abandoned. What gets added next should come from usage data and from the questions still arriving by email.
- Their own records, current and historical, with dates and status.
- Documents issued to them, available permanently rather than on request.
- The actions they are allowed to take, with your rules enforced.
- A request history, so nobody has to find an old email thread.
- Account details they can maintain themselves.
What makes a dashboard useful rather than decorative?
One question per view, and a decision attached to it. A useful dashboard answers something a person acts on — is the backlog growing, which jobs are overdue, what is waiting on us — and states its source and period, so the number can be trusted enough to act on.
Charts that exist because a dashboard looks empty without them are worse than no chart: they add reading effort and imply meaning that is not there. Where a number is the answer, a number is the right display; a chart earns its space when the shape over time is the point.
Are charts accessible to screen readers?
They have to be. On the work we build, the values behind a chart are available as real text — a table or a labeled list — and meaning is never carried by color alone, so a chart is not the only route to the information.
Should a dashboard update in real time?
Rarely. Live updating adds cost and complexity, and most operational decisions are made on today or this week. We state the period and the refresh interval on the view, which is more useful than a number that moves while you read it.
How is access to a customer portal secured?
Every request is authorized on the server against the signed-in account, so a customer can reach only their own records regardless of what they type into the address bar. Credentials are hashed, sessions are handled server-side, two-factor authentication is available, and sensitive actions are logged.
Document delivery deserves specific mention because it is where portals are most often weak: a file behind a guessable or shareable URL is not protected. Access is checked at the point the file is served, not only at the point the link is displayed. Portals are designed with appropriate security practices, and no supplier should promise you more than that.
Everything included
- Customer portals
- Customer dashboards
- Self-service account areas
- Data dashboards and reporting views
- Document and record access
Why it matters
Support volume drops at the routine end
The questions that exist only to relay information stop arriving, which leaves your team with the conversations that actually need a person.
Customers get answers immediately
Status, documents and history are available at any hour without a request, which removes the wait that makes a business feel slow.
One version of the record
The customer sees the same data your team sees. Disputes about what was agreed or sent become a lookup rather than a search through email.
Reporting stops being manual
A dashboard reading live data replaces the spreadsheet assembled by hand, so the numbers are current and consistent between people.
Where it applies
A client portal for a professional firm
Clients see matters in progress, documents issued, invoices and what is waiting on them — instead of emailing to ask where something is.
A booking and appointment portal
Customers see upcoming appointments, reschedule within your rules, and receive reminders. Rescheduling stops being a phone call.
An internal operations dashboard
A team view of what is outstanding, what is overdue and what is moving, so the daily question about current state is answered by data.
What a dashboard is actually for.
A dashboard is worth building when it answers a question someone acts on. The chart below shows the shape of a typical operational view — open requests by week, so a manager can see whether a backlog is growing or clearing — and the same values are available as a table beneath it.
See the sample values as a table
| Period | Open requests |
|---|---|
| Wk 1 | 42 |
| Wk 2 | 38 |
| Wk 3 | 47 |
| Wk 4 | 31 |
| Wk 5 | 26 |
| Wk 6 | 29 |
| Wk 7 | 18 |
| Wk 8 | 14 |
Technology and approach
- Access enforced on the server for every request, scoped to the signed-in account, and never filtered only in the interface.
- Document and file access checked at the point of delivery, so a URL alone is not a permission.
- Designed with appropriate security practices — hashed credentials, server-side sessions, optional two-factor authentication, logging on sensitive actions.
- Dashboards built from live data, with the source and the period stated on each view so a number can be trusted.
- Charts readable without color alone, with the underlying values available as text for screen readers and for anyone who wants the actual number.
- Authenticated routes excluded from indexing, while the public pages in front of the portal stay server-rendered and indexable.
07/RELATED
Related services
Talk to us about Customer Portals & Dashboards.
Tell us what you need and when you need it. We reply with a clear scope and the next steps.