Having a customer portal developed: roles, documents, data protection and rollout

A customer writes for the third time this week to ask how far along her order is. The answer is somewhere: in a colleague’s inbox, in a folder on the file server, in a note after a phone call. Nobody is negligent, but nobody can answer the question in thirty seconds. This picture is the most common reason to think about a customer portal.

Suppose a company with around twenty employees handles ongoing orders for business customers: consulting, planning, support, billing. For each customer there are quotes, contracts, reports, invoices and many small agreements. Documents travel back and forth as attachments, and some confidential file goes to a larger distribution list because that is faster than finding the right contact.

A portal answers two questions at once: where is the current status, and who may see it? It is less a technology project than a decision about what collaboration with customers should look like in the future. The software merely reflects that decision. Anyone who treats the project as a pure programming task ends up delivering a pretty login that nobody uses.

A small thought experiment is useful: if the main contact at a customer asks tomorrow which documents from last quarter are on file, how long does your team need for a reliable answer? If it is minutes, you probably don’t need a portal. If it is half a day and three internal follow-up questions, you have a structural problem that more discipline alone won’t solve, because discipline doesn’t scale across twenty people and hundreds of cases.

The technical risks are real but manageable: login, permissions, file storage, notifications. Portals more often fail because of people and processes. Customers register once, forget the password and then write an email again. Employees don’t maintain the status because in practice nobody cares until it is suddenly wrong. A portal with outdated information is worse than none at all.

Then there is the trust problem. As soon as customers have their own accounts, a document must never show up at the wrong customer. A single such incident damages the relationship for good and may have to be reported. This requirement is inconspicuous in the requirements specification and enormous in the architecture, because it affects every query, every file and every notification.

A third point is scope. Once you start, you collect wishes: view time tracking, accept quotes online, pay invoices, chat, calendar, knowledge base. Each wish is reasonable on its own, but together they make a product that takes a year and whose benefit only becomes visible at the end. The real challenge is to deliver the first benefit early and align the rest with real usage.

A typical failure pattern shows up after a few weeks: the status still says “in progress” although the order has long been waiting because the customer owes a document. The customer sees the wrong status, calls, and feels confirmed that the portal is pointless. What helps is status changes that arise as a by-product of the work, for example when uploading a report or requesting a document, instead of as an additional maintenance task.

Before features are set, it is worth taking a sober look at the inquiries of recent months. Sort incoming customer emails and calls by reason: where is my order, where is the invoice, which documents are still missing, who is my contact, can I submit something later. Usually a large share falls on a few recurring questions, and exactly these justify a portal.

This analysis yields a weighting of features that can differ markedly from the wish list. Documents and status are often at the top because they are needed daily. Messages are important, but they compete with the email that everyone has open anyway. Approvals and signatures bring great benefit but raise legal questions and belong more in a second stage.

At the same time, you need to look at the employees’ side. Who handles incoming portal messages, who uploads documents, who covers during vacations? A portal shifts work; it doesn’t eliminate it. When a rollout fails, it is often because this shift was not discussed honestly. We therefore suggest analyzing both sides at the same time and clarifying the processes before the software.

A custom portal is not automatically the right choice. For many businesses a ready-made solution is enough: a document room from an established provider, a ticket system with customer access or the portal function of existing industry software. They are quickly set up, maintained by the vendor and solve security questions you would otherwise have to answer yourself. The price is compromises: foreign terminology, fixed processes, per-user license costs and often an appearance that doesn’t fit the brand.

An intermediate solution is builders and low-code platforms. They allow custom interfaces and processes but tie you to the platform, its pricing structure and its limits on permissions and data model. Tenant separation in particular can sometimes be controlled only to a limited extent there. Before deciding, check where the data is stored, whether permissions can be modeled per customer and per role, and what a switch would look like.

Custom development pays off where the process with customers is part of the service promise and standard products would bend it out of shape. Typical examples are specialist processes with several participants, special roles or integration with internal systems. The price is responsibility: you own the software and have to operate and update it. We therefore advise starting with a minimal scope that can be extended later rather than a complete platform on the first attempt.

Another consideration is dependence on the vendor. With a third-party product your customer data sits in its system, and a switch depends on whether documents and histories can be fully exported. Ask about this specifically before signing the contract, with a test export. With custom development the problem is reversed: you are independent of the vendor but dependent on those who understand the code. Documentation and a clearly regulated operation are then not optional extras.

The honest order of questions is therefore: is a standard product enough if we adapt the process slightly? If not, what exactly is missing? Only the answer to that justifies custom development, and it also defines what the first release must contain.

At the center is the question of who may see what. We distinguish two levels. The tenant is the customer company whose data is strictly separated from all others. The role describes what a person may do within their tenant. Both levels are modeled separately because they change in different ways: new roles come rarely, new tenants constantly.

On the customer side a few roles are usually enough: a main contact who may invite people and assign rights, employees with read access to orders and documents, and possibly a finance role that sees only invoices. On the provider side come account managers who handle the customers assigned to them, and administrators. The fewer roles, the easier maintenance stays to understand, and the less often exceptions arise.

Permissions should not hang on individuals but on roles and assignments. If an account manager leaves the company, their assignment is reassigned without touching individual documents. It is also crucial that the check happens centrally in the backend. Hiding a button protects nothing as long as the underlying query answers every logged-in user.

There are several ways to build tenant separation. All customers in a shared database with a consistent tenant identifier is the leanest variant and appropriate for most service providers, but it demands discipline in every query. Separate schemas or dedicated databases per customer isolate more strongly but cost operations and update effort. We would start with the shared database and additionally secure the separation at database level, for example with row-level security rules, so that a forgotten filter in the code is not enough to mix data.

The permissions concept belongs, before programming, in a table that domain experts can read: rows are roles, columns are actions such as view, upload, delete, invite. This simple document prevents most later misunderstandings and later serves as the basis for tests.

For login, invitation has proven its worth with business customers: an account manager invites a person by email, they set their own password and confirm the address. Open self-registration is convenient but opens the door to strangers. A second confirmation via authenticator app or one-time code significantly increases protection but requires some patience from customers. We would provide and offer it for sensitive documents, not enforce it where the effort doesn’t match the need for protection.

Documents do not belong in the database itself but in object storage, with metadata in the database: owner tenant, order, version, checksum, timestamp. They are retrieved only via short-lived, signed links that are issued after the permission check. That way there is no permanently public address that can be passed on. On upload, file type and size are checked, and if needed a virus scan runs before the file becomes visible.

The interplay can be tested with a simple test: two test customers, each with their own documents and users, and a script that uses one’s access to systematically call the other’s addresses. Every hit is an error. This test should run automatically with every change, not just once before launch, because separation is usually lost in later extensions.

The status of an order should not be freely writable but consist of a few clearly named stages, for example received, in progress, waiting for customer, completed. The change generates an event. History, notification and log are fed from this event, so there is only one source. Free text remains for explanations so that the stages stay comparable.

Notifications are where portals become annoying. One email per event leads to customers muting them. We would bundle events, report immediately only where action is really needed, and send no confidential content in the email itself, only the notice and the link to the portal. Whoever sees the matter after logging in also has the rights to it.

Real customer relationships rarely fit into a clean role scheme. A customer’s tax advisor needs access to individual documents for three weeks, then no longer. A customer’s employee leaves the company but keeps their credentials. An account manager is on vacation and inquiries pile up. Such cases should be in the concept before they occur, because otherwise they end up as emergency fixes with special rights.

For time-limited access, expiry dates on assignments help, so the access ends by itself. For departing staff a simple rule helps: the customer’s main contact can block accounts, and the provider reminds them at regular intervals to review the user list. Accounts are deactivated instead of deleted so that history and logs are preserved and assignments to documents don’t point to nothing.

Data protection raises further questions. Customers may request access to their data, and after the end of the contract the question of deletion arises, while statutory retention periods for invoices and contracts may limit deletions. The portal therefore needs deletion concepts per document type, not across the board. Which periods apply to you is clarified by your data protection officer or legal adviser. The software must then be able to implement the decision technically, for example through blocking flags and deadline-driven deletion.

Logs are a tool here, but also a data protection question. Recording who opened which document and when creates traceability and at the same time data about people. We therefore keep the log concise: sufficient for investigating incidents, with a limited retention period and a clear purpose. This is guidance, not legal advice. The specific design should be agreed with your data protection office.

A portal should reduce follow-up questions, make documents findable and keep the status transparent. Whether that succeeds can be measured, in your own business rather than against industry figures. Before the portal starts, you should record how many status inquiries arrive by email and phone per week and how much time searching for documents costs in daily work. A rough tally over four weeks is enough for this.

After launch, three figures are meaningful: the share of active customers who log in within a month, the number of remaining status inquiries outside the portal, and the time to answer inquiries. Added to this is a qualitative judgment from the account managers on whether the work has become more plannable. A portal with many registrations but few returning users is not accepted, no matter how good the technology is.

Certain effects cannot be promised. How quickly customers adopt the offer depends on their habits, on contacts and on the rollout. A time saving only materializes if the old routes actually decline and the team works consistently in the portal. Anyone who also answers every inquiry by email in parallel has double the work and no result.

A realistic period is several months until habits have shifted. In that time expect rework: texts that customers misunderstand, roles that were cut too narrow or too wide, notifications that arrive too often. That is not failure but the normal case of a rollout, and the concept should allow time for this adjustment.

The best way to win customers is a small circle of pilot customers who use the portal before the general launch. Choose customers with close contact and regular exchange, not the loudest critics. Their feedback shows the hurdles in real use: incomprehensible invitation emails, a document that can’t be found, a status whose wording is understood differently than intended.

After that, a clear line on the switchover helps. From a cut-off date, new documents go only through the portal; by email there is at most a notice with a link. If employees make exceptions when needed, customers quickly learn that the old habit still works. Friendliness and consistency are not mutually exclusive if the portal is really simpler than what it replaces.

In operation the inconspicuous things count: security updates, backups with verified restoration, monitoring of errors and storage space, a contact person for customers with login problems. Password resets are the most common support case after launch and should be self-service. Also plan a fixed date each quarter at which user lists, roles and deletion periods are reviewed.

A frequently underestimated part is the texts. Invitation, error message and status label speak to people who only occasionally open the portal. Terms from internal jargon confuse them. Test texts with someone who doesn’t know your processes, and keep the paths short: a customer who needs three minutes after the invitation to reach the first document comes back; one who searches for fifteen minutes writes an email.

Finally, it is part of this to let the scope grow deliberately. If usage shows that customers mainly need documents and status, a chat would be superfluous. If they constantly ask about invoices, the invoice view moves to the front. Usage data steers the roadmap, not the original wish list.

A customer portal is worthwhile when the same questions and documents keep traveling between the same parties and you want to create a reliable address for them. It is less worthwhile if there is only a feeling that a service provider has to have one. The yardstick is relief in everyday work, not the impression of being modern.

Technically, care matters in one place: tenant separation, permissions and logs belong in the foundation. Organizationally, the rollout matters, one that brings customers along and doesn’t leave employees alone. Anyone who takes both seriously needs surprisingly little functionality for the first release.

Three principles follow from this that carry beyond the individual project. First, a portal begins with customers’ inquiries, not with a feature list. Second, a status is only as good as the process that produces it. Third, trust remains the real capital: it comes from correct separation, traceable logs and an operating concept that still holds in two years.

The next step is small: for four weeks, count which inquiries from your customers recur, and write down who in your company answers them. If you send us that picture, we will honestly assess whether a standard product is enough or a custom portal makes sense, and give a range for scope and effort before you commit.