A European metropolis asked Partners to clean its case data so leadership could finally see how long an average citizen request took. Two iterative sprints, six weeks total, built on top of the existing database. No system replacement. The work delivered a 35 % improvement in average weekly throughput and a 20 % reduction in median case lifecycle. It also surfaced a finding nobody had asked for: in several major case categories, more than a third of open cases were already past their statutory deadline. The dashboards now make those breaches visible in real time, and inform staffing decisions across the executive office.
The mayor's question
Every council meeting, the mayor would ask the same kinds of questions. How long does an average request take? Which department is the bottleneck? What share of our cases are running late?
The questions were operationally elementary. None of them could be answered.
The data was already there. The metropolis runs every citizen request, every administrative file, every internal ticket through a single case management system that had been collecting data for years. The database held every answer leadership needed. But the database had been built to store the answers, not to show them. Somewhere along the way the documentation had been lost.
So the head of each department assigned cases by feel. Senior workers chose the cases they wanted. The newer ones got whatever was left. Some departments knew what they were doing. Others ran on intuition and reasonable approximation. The result was uneven workload across teams, uneven complexity per worker, and a small set of departments running into the calendar without anyone in the executive office knowing.
The mayor stopped asking. The questions hadn't gone away. The instrument to answer them was missing.
What we did
The brief was modest. Clean up the data so we can see how long an average request takes.
We started with the database itself. There was no documentation. We reverse-engineered the schema: what each table meant, what each field captured, which fields the system actually used and which were vestigial. In a public-sector context, this work is usually outsourced to the original vendor on a maintenance contract. We did it ourselves in two weeks, end-to-end.
Then we built a thin analytical layer on top of the existing database. The case management system itself was never touched. In public-sector architectures, anything that requires replacing a core system is a multi-year programme, not a sprint output. The city's existing investment stayed intact.
The stack was deliberately conventional:
- PostgreSQL as the unified analytical warehouse, populated from the existing case management database.
- Power BI as the reporting and audit surface: every dashboard, every algorithmic decision, every staffing view delivered through a tool the city already had a licence for.
- Auditable automation scripts for case assignment: every routing decision logged and inspectable through Power BI alongside the dashboards. In a public-sector context, automation has to be auditable to be usable at all.
- AI complexity scoring at intake: a model that scores every new case for the work it represents before it is assigned. Without it, throughput targets reward cherry-picking the easy cases. With it, that loophole closes.
The work moved through two iterative sprints over six weeks.
Sprint 1. See what the city has. A reverse-engineered data model. A profile of every case category. The first operational dashboards: workload by department, aging buckets, throughput baselines. At the end of week three, department heads could answer the mayor's questions for the first time.
Sprint 2. Act on what the city sees. Workload-balancing assignment scripts that distributed new cases across the department based on current work-in-progress, target WIP per team, and the AI complexity score for the case in question. Multi-persona dashboards shipped in the final week. Department heads got the planning view: where workload was concentrated, where deadlines were tightening, where reassignment was warranted. Frontline workers got their own personal queue: what they owned, what was nearing its statutory deadline, what needed their attention next. The same data, sliced by the question each person actually had.
The result that mattered
The throughput gain was real. Average cases processed per week climbed by roughly 35 % between the quarter before the first sprint and the quarter after the second. The median case lifecycle dropped by about 20 %. Those are the numbers the city reports.
Beneath the numbers, the executive office got something back. Operational questions used to require three weeks of Excel reconciliation across departments. Now the answer is in the dashboard the mayor opens before the meeting starts.
The dashboards are still in daily use. The city's internal IT team owns the architecture and continues to extend it. The reporting layer now informs staffing decisions across departments: where there are too many people, where a process needs to be reworked, where complexity is concentrated unfairly on a small team.
What we didn't expect
The throughput numbers were the brief. The deadline number wasn't.
When the data finally became readable, one finding stopped the room. In several major case categories, more than a third of open cases were already past their statutory deadline. Not a minor margin. A structural pattern. The cases were being processed. They were just being processed late, often by months, often without anyone in the executive office knowing.
European municipalities carry legal obligations tied to statutory deadlines. Missed deadlines can lead to liability for damages, ombudsman complaints, audit findings, and political consequences. None of that exposure had been visible. The case management system had been recording every breach. Nobody could see them.
The new dashboards now surface the breaches in red, by category, in real time. The first leadership meeting after they went live spent ninety minutes on the categories that had been hiding the largest backlogs. That meeting changed the city's enforcement priorities for the next quarter.
Most organizations don't have a case management problem. They have a case visibility problem. The compliance risk they think they're managing is hiding inside it.
The data is there. The view is missing. The reform is closer than the system-replacement budget assumes.
A diagnostic you can run this week, without us
If you run a European municipality, here is what you can do this week, without hiring anyone, to find out whether you carry the same exposure.
Step 1. Pick your three highest-volume case categories. Ask your IT team to pull the list. They should be able to do it in an afternoon. If they cannot, if your case management system cannot tell you which categories carry the most volume, that is already your first finding. You are running the city on the assumption that the system knows what it is doing. The system cannot even tell you what it is doing.
Step 2. For each category, demand one number on one page by Friday. The question: of the cases opened in the last 180 days, what percentage are still open past their statutory deadline? A single number per category. No new dashboards required. No new procurement. Just one query, three answers, one page.
Step 3. Whatever the number is, make it your next standing agenda item. Bring it back next quarter. If it has not moved in the right direction, the cure is not a new process or a new system. It is a measurement layer the operations team can act on every Monday. That layer is weeks of focused engineering, not years of system replacement.
The number you receive on Friday will tell you whether your case management system is steering your city, or hiding it from you. Either way, you will be in a better position to lead it on the following Monday.