Personal Government Companion: a state that talks to a person at the right time

Where it differs from a personal cabinet

The current personal cabinet on the government portal is a form of access. The citizen logs in, finds the service they need, starts the process. The cabinet is reactive — it answers a request, it does not anticipate.

Personal Government Companion is a different class of product. An interface that knows the user’s context and starts the conversation itself. Knows your renewal is due. Knows you moved. Knows you had a child. Knows the law affecting your business has changed.

The Companion does not wait for you to open the portal. The Companion opens the channel itself — a short message: “your passport expires in 30 days, tap to renew in 2 minutes”, “you have a new regulatory obligation for your business from the 15th, here is the action checklist”.

It is a shift from “the portal you go to” to “the assistant that comes to you”.

What goes into the Personal Companion

Several structural components.

User context. The Companion knows who you are — citizen, sole proprietor, company director, parent, property owner, foreigner on a work visa. Each role has its own set of obligations and opportunities. The context updates automatically through events (you registered a business — the entrepreneur role is added).

Obligations calendar. What needs to be done and when. Taxes, renewals, reporting, medical obligations, child obligations. The calendar is visible in advance, not appearing on the deadline day.

A notification channel with prioritisation. Not one generic stream, but a structured flow — critical (action within 24 hours), urgent (within a week), informational (for awareness). The citizen can configure which channel handles which class (push/SMS/email).

One-click actions. The Companion does not redirect to a form on the portal — it contains the action itself. “Renew” — one click, biometrics, confirmation. No transitions between services.

Interaction history. What you did with the state, what the state did for you. Not as a compliance audit log, but as a journal that helps you understand your own path.

Decision explanations. If something is refused or approved with conditions, the Companion explains in plain language: what it means, what to do next.

Where this often fails

A Companion as a rebranded old portal. The UX is updated but the logic is the same — the citizen initiates, the portal responds. That is not a Companion, it is a repainted cabinet.

A Companion without cross-agency context. If the Companion only knows part of your obligations (one agency yes, another no), it creates a false sense of control. The citizen thinks they will see everything — and some obligations arrive with a fine because the Companion did not know about them.

Too many notifications. Without prioritisation the Companion turns into spam. The citizen disables push and the Companion becomes useless.

Notification fatigue in the first 6 months. Most notifications are irrelevant because segmentation is weak. The citizen learns to ignore.

A Companion that does not allow one-click action. The notification arrives but the click leads to a 7-step portal form. Worse than no notification at all — irritating.

A Companion that is the same for everyone. The context of a sole proprietor and the context of a pensioner are different. One interface for all — overwhelm for some, irrelevance for others.

What the launch requires

Government Memory Layer. For the Companion to know context, the state must have a shared memory layer about the citizen. Not “each agency its own”, but a consolidated view with consent.

Event Graph. For the Companion to react in time, events have to flow in real time. Child registration → event → parent’s Companion updates. Law change → event → affected citizens’ Companions update.

Notification Fabric. A notification management layer with prioritisation, frequency caps, suppression rules. Without it the Companion becomes a spam machine.

Consent Wallet. The citizen explicitly grants which data the Companion uses and which it does not. Can change at any moment.

Action Layer. The Companion has to be able to perform actions on behalf of the citizen with their confirmation (renewal, payment, application). Not redirect to a portal form — execute.

Each of these is a separate project. The Companion is the surface; under it sit all of these layers.

A realistic launch scenario

Not “build a Companion for every citizen at once”. Phased.

Months 1-6. Foundation. One use case (for example, document renewals) with 3-5 document types. One channel (push in the existing app plus SMS). A base Memory Layer for these use cases.

Months 7-12. Pilot. 100,000-500,000 citizens in pilot. Measurement: notification open rate, action conversion, satisfaction, opt-out rate.

Months 13-18. Use case expansion. Add tax notifications, social benefits reminders, legal updates for businesses.

Months 19-24. Scale. The Companion is available to all active digital citizens. 10-15 use cases. Integration with three-four agencies.

By two years in the Companion becomes the primary interface for most citizens. The portal still works but is used less often.

When the topic is premature

If the basic infrastructure (OneID, registries, cross-agency integration) is unstable, the Companion cannot work reliably. Foundation first.

If the country has no adopted regulatory framework for proactive notifications (which can be sent without additional consent), the Companion hits legal limits.

If agencies are not ready to share event data in real time, the Companion’s context will be fragmented.

If the management structure has no owner for the Companion as a product (not for the portal, but for the next layer), the initiative dilutes.

If the budget is constrained on an 18-24 month invest period, the Companion collapses into a quick win that does not deliver the expected effect.

Discussion at the digitalisation council level

Which 3-5 use cases are most painful for citizens today and could be closed by the Companion in year one?

What is the readiness of Memory Layer and Event Graph as foundations?

What is the regulatory framework for proactive notifications? What needs to expand?

Who owns the Companion as a state product? A new role or an existing one?

What 24-month investment commit is needed and is it there?

How SamaraliSoft can help

Personal Government Companion Blueprint — identification of 5 priority use cases, design of Memory Layer and Event Graph architecture, design of the notification framework and UX, regulatory engagement, and a pilot on 1 use case over 9-12 months.

Related reading

• /en/insights/government-after-egov/ — the next layer after e-gov
• /en/insights/government-life-event-orchestration/ — life-event orchestration
• /en/insights/government-personal-state-inbox/ — state inbox
• /en/insights/government-public-trust-layer/ — trust layer

Sources

• Digital Government Portal — state of digital infrastructure UZ
• Ministry of Digital Technologies — telecom and digital UZ
• UzDaily — digital and telecom market UZ
• Central Bank of Uzbekistan — biometric verification for digital banking