Project · Government & public sector
Citizen case management
Consolidating seven program areas and a legacy database into a single case-management platform with accessible citizen access and audit-ready decisions.
The operating problem.
A state government program was delivered through seven regional offices, each with its own intake form, assessment spreadsheet and correspondence process. A legacy database held historical cases but was not used for active work.
Citizens could apply online, by email or by post. There was no consistent acknowledgement, no status visibility and no single view of an applicant’s history across programs. Staff spent significant time answering questions that the system should have answered.
The program needed a platform that could support a consistent service while respecting the different eligibility rules and reporting obligations of each stream.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Seven program areas used different forms, eligibility rules and assessment practices.
- Applicant information was duplicated across spreadsheets and email inboxes.
- There was no structured audit trail for decisions, overrides or correspondence.
- Public-facing forms did not meet the required accessibility standard.
What we found
The variation between programs was partly legitimate and partly historical. Some rules were set by policy; others had been introduced locally and never reviewed. The discovery needed to separate the two.
Staff were not resistant to a common platform. They were protective of the local knowledge that allowed them to handle exceptions. A successful design had to preserve the ability to exercise judgement while recording it.
Accessibility was not a cosmetic issue. The existing forms relied on PDFs and complex layouts that were difficult to use with assistive technology. A rebuild was an opportunity to meet the standard properly.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Map programs and rules
Document each program’s eligibility criteria, assessment steps, correspondence and reporting obligations, separating policy rules from local practice.
Design a common case model
Create a shared case record with program-specific fields and a rules layer that could be configured without forking the platform.
Build the case workspace
Role-based queues, assessment tasks, document handling, correspondence templates and an audit history.
Deliver the citizen portal
Accessible online application, document upload, status tracking and secure messaging tested against WCAG 2.2 AA.
Migrate and stage the rollout
Migrate active cases in program waves, keep the legacy database for historical records and run a support bridge during transition.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
Program rules could not be forced into one workflow.
We separated the common case lifecycle from program-specific rules. Each program configured its eligibility questions and assessment steps, while the underlying case record, audit history and correspondence remained common. This preserved policy differences without creating seven platforms.
Local overrides were common and often undocumented.
We introduced a structured override with a reason code and approval. The override remained possible, but it became visible. Reporting could then show where policy and practice diverged, which gave the program owners evidence for future rule changes.
Accessibility testing found issues late in the first release.
We brought accessibility testing into the design system and component acceptance rather than treating it as a final audit. The remediation was smaller and cheaper because it happened before the release candidate.
Historical data was inconsistent and incomplete.
We migrated active cases with a field-level mapping and an exception report. Historical cases remained searchable in the legacy system through a read-only interface. We did not attempt to normalise twenty years of inconsistent records.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
Triage improved because applications arrived with the information required for assessment, and staff worked from a single queue with clear ownership. The program could see demand and backlog by region for the first time.
The audit history changed the quality of management review. Decisions, overrides and correspondence could be reconstructed without asking staff to recall a case. That reduced the time spent preparing for internal review and improved consistency.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- Common platforms must accommodate legitimate policy variation; forcing uniformity creates shadow processes.
- Accessibility is cheaper when it is part of component design and acceptance.
- Historical data migration should be scoped to what is needed for operation, not perfection.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
Policy variation must be configurable, not forked.
The seven programs were not identical, and pretending they were would have created a platform that none of them trusted. The design separated the common case lifecycle from program-specific eligibility and assessment rules, so policy differences could be configured without copying the platform.
That choice required discipline. Every rule needed an owner, a version and a test. The benefit was a single audit history, a single correspondence model and a single support path, while the programs retained the policy distinctions that mattered.
Any multi-program platform should ask early which differences are policy and which are habit. Policy differences deserve configuration; habits often deserve a simpler process.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.