Customer self-service portals and apps
Consumption, transactions, invoices and application status that customers can check themselves, at an hour that suits them — which makes it the cheapest support channel you will ever build.
What a self-service portal has to cover
Customer portals and mobile apps
One account across web and mobile, with the same data and the same permissions, rather than an app that shows a subset of what the portal does.
Consumption and transaction history
Usage, purchases and payments presented in the customer's terms, with enough detail to answer the question that would otherwise become a phone call.
Invoice and document access
Invoices, contracts and statements downloadable without a support request, with the archive going back far enough to be useful.
Application and case status
Where an application, claim or request currently sits and what happens next — the single most common reason customers call.
Identity and authentication
National eID, bank authentication, SSO or passwordless, chosen for the market rather than for what is quickest to implement.
Accessibility and mobile-first design
Built to WCAG from the start, because a self-service channel that excludes part of your customers has not replaced anything.
Don’t see your challenge here? Talk to us about your project
Self-service only counts when the call stops happening
A portal that shows everything except the thing people ring about has not reduced support load. We start from the actual contact reasons — the top ten by volume — and design the portal to answer those first.
The same applies to the awkward cases: a failed payment, a disputed line, a change of ownership. Those are the ones customers most want to handle themselves and the ones portals most often omit.
- Driven by call reasons
- Scoped from real contact volumes, not from a feature list.
- Self-serve changes
- Not just viewing — changing details, plans and payment.
- Status transparency
- Where a case sits and what is expected next.
- Strong identity
- eID, bank login or SSO suited to the market.
- Accessible
- WCAG conformance designed in, not retrofitted.
- Measured
- Deflection tracked against the call reasons it targeted.
Web-based tools that moved applications out of the inbox
For KredEx we built web-based tools around application handling, where the value came less from the form itself than from applicants and officials seeing the same status. Once the state of a case is visible to both sides, a large share of the correspondence about it simply stops.
Common questions
Portal, mobile app, or both?
It depends on how often customers come back. Monthly or less, a responsive portal is usually enough. Weekly use, notifications or offline needs make an app worth its ongoing cost — and we would rather say so before it is built.
Can customers log in with a national eID?
Yes. We work with Estonian ID-card and Mobile-ID, Smart-ID, bank authentication and standard SSO and OIDC providers, and pick per market rather than imposing one.
How do you keep portal data in step with the back office?
The portal reads from the systems that own the data rather than holding its own copy wherever performance allows. Where caching is necessary we make the staleness visible instead of pretending it is live.
Let's talk about your customer platform
Tell us where your customer data sits today and which question you cannot currently answer about it. We will come back with an honest read on the model, the integration work involved, and what a realistic first phase looks like.
