Solution · Apps & software
Customer portals and personal accounts
A customer portal gives clients a private area where they can see what they would otherwise ask a manager about: the status of an order or shipment, their documents and invoices, the history of requests, the balance of a contract. Every question answered by the portal is a phone call or a message your team does not have to handle.
[ 01 ]
In short
In short
- 01
A portal is justified when clients ask the same status questions often and the answers already exist in your systems.
- 02
The data comes from where it lives today — CRM, accounting, a warehouse or logistics system — so the portal is mostly an integration project.
- 03
Access control is central: each client sees only their own data, and within a client company, people see what their role allows.
- 04
Start with the two or three most frequent questions; a portal that answers them well is used, one that tries to show everything is not.
- 05
Security, audit logs and personal data handling are part of the design, not an add-on.
[ 02 ]
Scope
What clients typically do in a portal
- Track orders, deliveries, applications or cases, with status history.
- Download documents: contracts, acts, invoices, certificates, policies.
- See balances, payment schedules and outstanding invoices, and pay online.
- Submit requests and see their progress instead of chasing a manager.
- Manage their company's users — add a colleague, change permissions.
- Receive notifications when something changes.
Which of these matter depends on the business. A logistics company's clients want shipment status; an insurance client wants the policy and the claim; a wholesale client wants to reorder and see invoices. See, for example, logistics companies and insurance companies.
Where the data comes from
Most portals do not create new data — they show data that already exists in your CRM, 1C or another accounting system, a warehouse system or a custom database. The portal reads it through APIs or scheduled exchanges, and writes back what clients submit. That makes the integration design the most important part of the project: how fresh the data must be, what happens when the source system is unavailable, and which system is the master for each field.
See CRM integration and 1C integration for how we connect these systems.
Roles and access
Client companies are rarely a single person. A director needs everything, an accountant needs invoices, a logistics manager needs shipments. We design roles and permissions around these real jobs, with an admin role on the client side so their own team can manage access. The principles are in designing roles and permissions.
Security and personal data
A portal holds commercial and often personal data. The basics:
- Strong authentication, with optional two-factor sign-in for sensitive accounts.
- Strict separation between clients at the data level, not only in the interface.
- An audit log of who viewed or changed what.
- Encrypted connections, secure storage of documents, regular backups.
- Compliance with Azerbaijan's personal data law where personal data is processed; see personal data law for websites.
Rollout
Portals succeed when clients actually start using them. We plan the launch with your team: which clients get access first, how they are invited, what managers say when a client calls with a question the portal answers. Usage analytics show which sections are used and which need rethinking.
What we need from you
- The questions clients ask most often, ideally from support or sales records.
- Access to the systems that hold the data, with their API documentation.
- Your rules on who in a client company may see what.
- A group of friendly clients willing to try the first version.
[ 03 ]
FAQ
Frequently asked questions
Can a portal be part of our existing website?
Yes. It usually lives under the same domain, with a sign-in link from the site, but runs as a separate application with its own security settings.
Do we need a mobile app for the portal?
Usually not at first. A responsive web portal works on phones; an app or a progressive web app makes sense when clients use the portal daily or need notifications.
What if our internal systems do not have an API?
There are options: scheduled file exchanges, a database connection, or an intermediate service. We assess what the systems allow before estimating the work.