A client portal is a closed area of your website where a person sees their own orders, documents and balances and handles routine actions without a manager. It takes the repeating “where is my order” and “please send me the closing documents” off your staff and pays off where clients come back: repeat orders, subscriptions, supplies, servicing.
Key takeaways
A portal makes sense when the relationship with a client lasts longer than one purchase and routine piles up in the correspondence. A one-off sale with no follow-up needs no portal: the person simply will not open it a second time.
The easiest way to count the benefit is in requests rather than money: list the questions your managers answer every day and mark the ones a client could answer themselves with access to the data. If that is more than half, the portal pays off. When your clients are companies and dealers, the task is wider — personal prices, credit limits and roles inside the client company — and that is covered in a separate article on a B2B portal for wholesale clients.
There is a counter-signal too. A portal does not solve the problem if the data inside the company is a mess: while order statuses live in managers' correspondence and documents are assembled by hand, there is nothing to show the client. First you put the systems in order, then you build the front end.
The first version takes two or three scenarios that come up most often in correspondence, not the full list of features. A portal that does a bit of everything takes long to launch and still ends up only partly used.
Everything else — requests with attachments, reconciliations by period, exports, notification settings, access for several employees — goes into the second version, once it is clear what people actually use.
The format follows what the client does in the portal and how often. A web portal wins on documents and tables, Telegram wins on short actions, an app wins where offline mode and phone hardware matter.
| Criterion | Web portal | Telegram portal | Mobile app |
|---|---|---|---|
| Documents, reconciliations, long tables | Yes | Limited | Yes |
| Sign-in | Login and password or a one-time code | The client's Telegram account | Install from a store |
| Who will see a notification | Email, SMS, browser with consent | Only those who launched the bot | Push after permission |
| Updates | On the server, for everyone at once | On the server, for everyone at once | A new build and store review |
| Works on a desktop | Yes | Yes | No |
| Entry cost for the client | A link and a password | A link to the bot | An install and space on the phone |
The formats combine: the web portal stays the place for documents, while short actions and notifications move to the messenger. How that works technically is covered in the article on a client portal in Telegram.
A portal keeps no separate copy of your data — it displays what already lives in the CRM, the accounting system and billing. It gets a database of its own only for what no other system holds: users, permissions, notification settings, draft requests.
The key question at the start is who owns each field. If an order status can be edited both in the CRM and in the portal, sooner or later they diverge and the client sees one thing while the manager sees another. How to split the directions of exchange is covered in the article on integrating a CRM with 1C, telephony and messengers.
Permissions are checked on the server on every request, not hidden in the interface. The classic portal mistake is serving someone else's order to whoever swaps the number in the page address: there is no button on the screen, yet the data comes back.
Important Portal pages are kept out of search engines with the noindex rule. According to Google documentation it only works when the page is not blocked in robots.txt: if the crawler cannot load the page, it never sees the rule and the address stays in search results.
Roles, action logs and protecting the database from exports are covered in detail in the article on access rights in a CRM: a portal inherits the same rules because it works with the same database.
A portal processes personal data, so Uzbekistan's law On Personal Data No. ZRU-547 applies to it. Protecting that data by legal, organisational and technical measures is required no matter where the server stands.
A new version has been in force since 27 March 2026: law No. ZRU-1125 of 26 March 2026 left mandatory storage inside Uzbekistan only for biometric and genetic data and for data of telecom operators' users. Other personal data — clients, orders, documents — may be stored abroad if one of the conditions in part three of article 27-1 is met.
The practical minimum for a portal: collect only the data the scenario needs; show the privacy policy at registration; store documents so that a file link does not open for outsiders; and provide a way to delete an account at the client's request.
A working portal does not wait for the client to log in and check — it reports the event itself. Otherwise half the point is lost: a person learns about an issued invoice only when a manager reminds them.
The channels are email, SMS or a messenger, at the client's choice. The rule is simple: a notification is sent on a system event rather than on a marketing schedule, and it carries a link straight to the right portal screen.
The flip side is notification fatigue. If the portal writes about every minor change, people switch the channel off entirely and stop receiving what matters. So the list of events is agreed in advance and the client keeps a choice of what to receive and where.
A launch starts with a review of incoming requests, not with mockups: until you see what the flow of questions is made of, there is nothing to move into an interface.
One thing to agree separately: who answers the requests coming from the portal, and within what time. A portal moves questions out of messengers and into a system, but it does not answer them instead of people.
There is no separate price tag for a portal: the budget is made of the web part, the links to your systems and the number of scenarios. The neighbouring lines on the service pages give a reference point.
Three things push the price up: the number of scenarios, the number of source systems and the requirements around documents and money. A portal with order statuses and a portal with reconciliations, payments and several roles are different projects. The scope of the web part is described on the page for website and platform development.
Syntra Systems starts with a review of incoming requests and finishes not by handing over an interface, but with the first weeks of the portal working for real clients. Only the scenarios that currently eat up managers' time make the first version.
We design the portal as part of the infrastructure: data comes from the CRM and the accounting system, permissions are checked on the server, the exchange is logged. After launch we watch which sections get used and extend the portal from real requests rather than from a feature list.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Size has nothing to do with it — repetition decides. List the questions your managers handle every day and mark the ones a client could answer themselves given access to the data: if that's more than half, a portal will pay off. For one-off sales with no follow-up, it's not needed.
By invitation to an email address or phone number: the first sign-in uses a one-time link or code, after which the client sets their own password. A shared login for the whole client company is bad practice: you cannot tell who did what and cannot revoke access for one person.
Create separate accounts with roles: one person sees only their own orders, another sees documents and balances for the whole company. Inviting new colleagues should be the client's job, otherwise that task comes back to your managers.
They should not. Sections behind authentication are unreachable for a crawler, and service sign-in pages are closed with the noindex rule. File links deserve a check too: documents often sit at direct addresses that open without a password.
It can, but then data has to be entered by hand and the portal quickly drifts away from reality. That option is justified only as a demand test on a single scenario, with a clear plan to connect the systems as the next step.
Documents, reconciliations and long tables work better in a web portal, while short actions and notifications suit Telegram — though only people who've started the bot receive its messages. The two are often combined: documents live on the website, statuses arrive in the messenger.
