// online services portal for citizens and businesses

Technical Specification for an Online Services Portal: What Clients Usually Miss

A technical specification for an online services portal is one of the most common IT procurements among government agencies and large companies that serve the public or businesses. The logic is simple: a citizen or a company submits an application through a personal account, the system routes it to the right agency or department, and the status can be tracked online without visits or phone calls.

The client is usually the agency or organization that delivers the service itself, but doesn't have an in-house IT team capable of designing architecture at this scale. In this case, the specification is written by one of the staff members, modeled on existing portals — and it inevitably carries over the names of services without their internal logic.

A portal isn't a website with a contact form; it's a system tied to login through government identification services, data exchange with other agencies, and stability during peak load. If these things aren't described in the specification at the procurement stage, they'll have to be figured out during development instead — and that changes timelines, cost, and who's responsible for what.

What specs usually miss

Services are listed by name, with no application route

What it leads to. The contractor doesn't know how many steps an application goes through, who reviews it, or when the status should change. At acceptance, the client expects one process and the developer has built another — the dispute turns into reworking the logic, not a minor fix.

How to write it right. For each service, a separate process map: who submits it, what documents are attached, what stages the application passes through, who processes it at each step, and what statuses the applicant sees.

Login to the personal account isn't described

What it leads to. If the login method isn't fixed, the contractor builds in one option (say, simple phone-based registration), and at acceptance it turns out login via OneID or a digital signature was required. That's not an interface tweak — it's a different authentication architecture and a different timeline.

How to write it right. In the login section, state explicitly which authorization methods are mandatory (OneID, digital signature, confirmed phone number), for which user categories — citizens, businesses — and what data the system receives at login and from where.

Integrations are named but not described

What it leads to. The phrase "integration with agency X's system" says nothing about the data exchange format, protocol, request frequency, or who needs to open access to the test environment. The contractor finds this out during development, once timelines are already agreed, and ends up waiting on a third party it has no control over.

How to write it right. For each integration, a separate block: which system, what protocol and exchange format, what data is passed in each direction, who provides access to the test environment and by when, and who's responsible for supporting the integration after launch.

No requirements for storing personal data

What it leads to. The portal handles applications containing passport details, addresses, often company information. Without requirements for storing and protecting this data, the contractor chooses the architecture on its own, and at acceptance or during a regulator's review it turns out not to match the client's expectations.

How to write it right. A separate section with requirements for where data is stored, access levels, logging of actions on personal data, and retention or deletion periods.

Peak-day load isn't estimated

What it leads to. Services have seasonality — days when far more applications come in than usual. If load isn't built into the specification, the system is sized for an average day, and on a peak day applications stall or aren't accepted — visible to users, not just in internal testing.

How to write it right. State the expected number of applications on a regular day and a peak day, the required response time under that load, and the load-testing conditions to be met before acceptance.

No definition of what counts as a finished, accepted system

What it leads to. Without acceptance criteria, client and contractor disagree on what "done" means: one side considers a working application-submission form a portal, the other expects a full cycle with statuses, integrations, and reporting. The dispute surfaces at the final stage, when changes are costly for both sides.

How to write it right. Spell out specific acceptance criteria for each service and integration, plus test scenarios that must pass before sign-off.

What a good spec gives

For the client, a specification with described routes, login, and integrations yields comparable bids from contractors and predictable acceptance without rework at their own expense.

For the contractor, such a specification makes it possible to estimate the real scope of work and timelines, instead of padding the price with risk "just in case."

Clear requirements for data storage and load remove the need for both sides to argue about this after the fact, once the portal is already live.

Drafting such a specification is a separate stage that belongs before the tender is announced, not alongside it.

Price and timeline

Technical specification: from $400, 1-4 weeks; the price depends on the system's complexity, architecture, stack and integrations. Subcontracted development: priced by contract scope, estimated before the bid is filed.

Tender specs or subcontracting: details →

We do not name buyers or tenders: we look at a typical spec, not at anyone's procurement.

Preparing a procurement or already won a tender?

Discuss a tender