Customer access with roles
Every login is tied to an entry in the customer record; roles govern which cases and documents a person can see.
Blueprint 05
Customer Operations Portal
one access point where customers see their own cases, documents and messages
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.
Part of
Custom Business SoftwareStarting point
The problem.
Customer enquiries arrive by phone, email, post and web form, and end up in different mailboxes and systems. The case status sits in the ERP, the documents in the DMS, the correspondence in a mail client — and the customer sees none of it. So they ask, and someone on your team assembles the answer from several windows.
Before · After
The same process, twice.
On the left, the process as it typically runs today. On the right, the same process once an application takes over the repetitive steps.
Today
How the process runs if nobody changes anything.
- 01Enquiry by phone or emailHuman
- 02Automatic acknowledgement of receiptSystem
- 03Routing to the right mailboxHuman
- 04Looking up the customer recordHuman
- 05Checking case status in ERPHuman
- 06Fetching the document from DMSHuman
- 07Writing and sending the replyHuman
- 08Adding a note to CRMHuman
- 09Customer asks again laterHuman
With NeXsoft
The same process, with the decision at one clear point.
- 01Customer opens the portalSystem
- 02Enquiry is sorted automaticallySystem
- 03Case and documents visibleSystem
- 04Self-service for standard requestsSystem
- 05Complex cases reach a caseworkerHuman
- 06Approval before anything is sentHuman
- 07Reply appears in the portalSystem
The label Human marks the points where a person decides or enters something. System marks the steps the application takes over. The human approval deliberately stays in place — it is not optimised away.
Interactive
The process, station by station.
The walkthrough stops at the point where a person decides. It continues only once you approve.
Flow
Step 1 of 7
- Intakerunning
- Identitywaiting
- Triagewaiting
- Casewaiting
- Self-servicewaiting
- Approvalwaiting
- Syncwaiting
Enquiries from the portal, email and telephone come together in one place and receive a case number.
The visualisation runs in your browser along a fixed sequence — nothing is uploaded, nothing is sent and no language model is called.
- Enquiries from the portal, email and telephone come together in one place and receive a case number.
- Access is tied to the customer record, so each person sees only their own cases.
- A language model proposes category, urgency and the responsible team, but decides nothing on its own.
- The case shows its current status, deadlines, ownership and all related documents in one view.
- Recurring requests such as an address change or a copy of a document are handled by the customer without asking.
- Before a reply or a document goes out, a responsible person confirms the proposal.
- The outcome and the history are written back to CRM and ERP, so the leading data still lives there.
Features
What the system would need to do.
Every line is a commitment about future work — not a description of something that already exists.
Case overview with status
Each case shows its progress, the next step, the responsible person and the deadline, so nobody has to ask for it.
Documents on the case
Contracts, receipts and certificates sit on the case instead of in mail attachments, with version state and an access log.
Messages in one thread
Correspondence runs in the portal on the case, and incoming emails are matched to the same thread.
Guided self-service forms
Address changes, document copies or appointment requests run as a guided form without involving a caseworker.
AI triage with approval
A model proposes category, urgency and a draft reply; the decision stays with a person.
A record of every change
Status changes, access and approvals are recorded, so it stays traceable later who initiated what.
Integration
What a system like this typically connects to.
Categories rather than vendor names — which product you run is decided by the system landscape you already have.
CRM — customer records, contacts, ownership
ERP or inventory management — orders, deliveries, invoice status
DMS — filing, version state, retention rules
Email and calendar, for example Microsoft 365
Telephone system via a CTI interface for call notes
Central user directory for single sign-on
Architecture
How this would be built.
One example structure in layers. Not the only one possible — but one we can justify.
Access and interface
- Customer portal as a responsive web application
- Internal caseworker view for your team
- Sign-in with a second factor
- Role and permission model
Case logic
- Case model with defined status transitions
- Rule set for deadlines and escalation
- Approval workflow with a dual-control option
- Event log per case
AI layer
- Classification of incoming enquiries
- Field extraction from documents
- Draft replies with a reference to the source
- Confidence threshold that hands over to a person
Data and integration
- Connectors to CRM, ERP and DMS
- Encrypted document store
- Event queue for asynchronous synchronisation
- Operation in European data centres
Metrics
How success would be measured.
These are the figures that would be measured during a project. Deliberately no values are shown — there is no measurement they could come from.
Share of enquiries closed without a callback
would be taken as the ratio of cases closed in the portal to all incoming enquiries
Time to first response
would be measured from the arrival of an enquiry to the first reaction on the case
Share of pure status enquiries
would be taken from the category assigned during triage
Accuracy of the triage proposals
would be measured as the share of proposals that stay unchanged at approval
Filing quality of documents
would be measured through later reassignments of documents between cases
Expansion
Start small, then grow.
A project of this kind does not begin with the full build. It begins with the part that carries its weight soonest.
First — visibility
Access, case overview and document filing for one clearly bounded case type, connected to CRM and ERP.
Next — self-service
Guided forms for recurring day-to-day requests, messages on the case and notifications on status changes.
Later — triage and coverage
Classification and draft replies with approval, further case types and connections to additional line-of-business systems.
Do you recognise your own process?
If you would like to see how this shape would work for your own case types, we can go through it in a first conversation.
Solution blueprint: a fully worked example system, not a delivered client project. The processes, architectures and metrics show how we would build such a system — they are not measurements.