A resident who wants to settle a matter at a public office compares that experience not with another office, but with their bank and their favourite online shop. They expect to file a request from a phone, at any hour, and to see exactly where their case stands. That is why a citizen portal and online public services have stopped being an add-on to the office and become its first counter, often the only one a resident will ever visit.
In our experience, the hardest part of such a project is not the form itself, but what happens after it is submitted: validation, case flow, statuses, integrations with line-of-business systems, and the strict demands of accessibility and security. We do not claim to have shipped a ready-made citizen portal, but we have supported public institutions on the engineering side, and we know how to design such a system and staff it with people who will build and maintain it.
What do citizens expect from e-government services today?
Commercial apps set the bar, so a resident assumes that a public matter can be handled entirely online and that they will not have to print anything or show up in person to drop off a document. That shift in expectations translates into a few hard requirements for the system:
- phone access as the default, not a fallback version of the desktop site,
- a single point of entry to many matters, instead of a separate portal per department,
- a transparent status, meaning clear information on what is happening with the request and what the office still needs,
- minimal re-typing of data the office already holds.
If any of these fails, the resident goes back to the counter and the whole point of digitisation dissolves.
How do you design a citizen portal and e-forms?
A citizen portal is, in practice, a structured catalogue of matters, not a pile of loose pages. Each e-service should walk the resident through it step by step, guard the completeness of the data before submission, and refuse to accept a request that would only come back for correction.
We design the e-forms layer around validation on both the browser and the server side: fields are checked as the user types, while business rules (field dependencies, required attachments) are enforced by the backend. Where the law requires identity confirmation or a signed request, the system integrates with electronic identity and signatures (in general terms: national identity nodes, e-ID, qualified signatures) rather than building its own shaky mechanism. The form also saves drafts, so a resident can finish later, and data entered once is carried into the following steps.
How does case handling and status tracking work?
A submitted form turns into a case with its own lifecycle. This is where it is decided whether digitisation truly relieves the office or merely moves the paper onto a screen. A well-designed case module carries a request from submission, through verification and any request for additional information, all the way to a decision, and every one of those steps leaves a trace visible to both the clerk and the citizen.
For the resident, what matters is a readable status and case history: what the office has already done, what it expects from the applicant, and by when. For the office, the internal flow matters just as much, meaning case assignment, queues, deadlines and integration with the document management system and line-of-business systems. We design that flow so the statuses shown to the citizen follow directly from the case state in the system, rather than being updated by hand.
How do you add appointment booking to e-services?
Not every matter can be closed remotely, so online appointment booking belongs inside the portal rather than living as a separate tool. We tie it to the office calendar and to a specific case, so the resident books a slot at the right desk and knows up front which documents to bring.
A well-built booking module shortens queues, spreads traffic over time and cuts no-shows thanks to reminders. The details decide its usefulness:
- slot availability computed from the real staffing of desks, not entered by hand,
- a link between the appointment and the case, so the clerk is prepared before the meeting,
- easy cancellation and rescheduling, which free the slot for others.
How do you build email and SMS notifications for residents?
A system that does not inform forces the citizen to keep logging in “just in case”. So we treat email and SMS notifications as part of case handling: we send them on a status change, on a request for additional documents, and before a booked appointment. We build them on queues and templates, with a delivery log, error handling and retries, and with respect for consents and data-processing rules. The content of a notification always points back to the case in the portal, instead of moving sensitive data into the message.
Why is accessibility (WCAG) a requirement, not an add-on?
In the public sector, WCAG-compliant digital accessibility is a legal obligation, not a nice-to-have bolted on at the end. The portal has to work with a screen reader, from the keyboard alone, and with enlarged text, while contrast and heading structure must be correct from the start. So we weave accessibility in at the interface-design stage and keep an eye on it throughout development, because retrofitting it later usually means rewriting components. As a bonus, every user benefits, not only people with disabilities.
How do you handle security and identity in a citizen portal?
The portal processes personal data and administrative decisions, so security and identity management are a foundation, not a cosmetic layer. We base authentication on proven standards (for example OpenID Connect) and national identity nodes, instead of maintaining our own passwords where we do not have to. On top of that come role-based access control, encryption of data in transit and at rest, full audit logs, and compliance with GDPR and national security requirements. These things are designed in from the start, because adding them later is costly and risky.
Which skills do we provide for an e-services project?
This is where our real role begins. Even if we do not front a ready-made citizen portal, we supply the people who design, write and maintain such systems, and we staff the roles against the specific project spec:
- a solution architect who ties together the portal, case flow and integrations,
- backend and frontend developers for the e-forms, case module and notifications,
- an integration specialist for identity nodes, document management and line-of-business systems,
- an accessibility and QA expert who guards WCAG and quality,
- a DevOps engineer who builds deployments, environments and monitoring.
We shape the team around the scope and verify skills before the start, rather than staffing a project “just in case”.
How do we do it at RITS?
We operate as a nearshore partner from Poland that tops up an institution’s team with the missing skills, rather than taking over its accountability. We have experience in engineering support for a public institution and in building transactional systems where data flow, security and integrations are what count. We work in your time zone, join code reviews and meetings without a long ramp-up, and grow the team under the client’s management. Most often we do this as custom software built by our team, or as team augmentation when skills need topping up fast. How to choose between those models we covered in our article on IT engagement models.
Where do you start building e-services for citizens?
Start from the single most frequently filed matter and walk it from the end, meaning from how it is handled inside the office and which systems it has to touch. That defines the scope of the e-form, the flow model, the set of integrations and the roles you need. The first properly finished e-service, with validation, statuses, notifications and accessibility, becomes the template you replicate across further matters, instead of building ten inconsistent portals.
Building a citizen portal or online public services? Let’s talk - we’ll match a team and an architecture to your institution.