CASE STUDY · GOVTECH SOLUTIONS
Building a citizen services dashboard for a regional government office.
- 25%Average response time down 25%
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised regional government office. Name withheld under confidentiality.
Data feeds from the existing systems and a dashboard of open requests by team. Each team could see its own queue, request age and status, and managers could see the whole office. The dashboard was refreshed regularly from the sources, so it needed no extra data entry.
- 1The office received service requests through several channels: phone, email, a web form and walk-in visits.
- 2Each team tracked its own list.
- 3Nobody could say how many requests were open, which team held them or how old they were.
- 4Delays were noticed only when a citizen or an elected official complained.
- 5Managers asked for reports that took staff days to compile, and the numbers disagreed.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early on, two teams used the same status words to mean different things
One used "closed" when a reply was sent, the other when the work was finished. The dashboard made one team look slow and the other fast, and the first team objected. We held a short workshop, agreed a status list with plain definitions, and mapped each team's local statuses to it.
- PROBLEM 02We also showed local status next to the shared one so no one felt their work was being renamed
Trust in the numbers rose once the definitions were written down.
- PROBLEM 03A second hurdle was data freshness
One source only produced an export overnight, so teams saw yesterday's picture and doubted the dashboard. We displayed the last refresh time on every panel, and moved the busiest source to a more frequent feed. Once the timing was visible and predictable, the objections faded.
- PROBLEM 04Once the timing was visible and predictable, the objections faded
03 · THE PROCESS
How we ran it.
We began by listing every channel and the system behind it, then interviewed team leads about how they tracked work. We agreed a small shared definition of a request: an identifier, a type, a team, a status and dates. Feeds were built one source at a time, starting with the busiest. After each, we checked the dashboard against the team's own list and fixed differences with the lead. A first version went live to managers, then to teams. A weekly review meeting was set up from the first month, and the dashboard became its agenda.
- 01Step 1
We began by listing every channel and the system behind it, then interviewed team leads about how they tracked work.
- 02Step 2
We agreed a small shared definition of a request: an identifier, a type, a team, a status and dates.
- 03Step 3
Feeds were built one source at a time, starting with the busiest.
- 04Step 4
After each, we checked the dashboard against the team's own list and fixed differences with the lead.
- 05Step 5
A first version went live to managers, then to teams.
- 06Step 6
A weekly review meeting was set up from the first month, and the dashboard became its agenda.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
The weekly backlog review uses one set of numbers, and old requests are named and assigned instead of discovered by complaint.
- NOW 02
Team leads check their own queue each morning.
- NOW 03
Managers decide on staffing with figures in hand.
- NOW 04
New channels can be added to the feed instead of creating another private list.
- 25%
Average response time down 25%
Backlog reviewed weekly
05 · WHAT WE BUILT
How it works.
- Each source is connected through a read-only integration, by database view, export or API, depending on what the system offered.
- Records are mapped to a common model and loaded on a schedule into a reporting database.
- Duplicate requests from different channels are matched by rules on citizen reference and subject, and flagged for review.
- The dashboard shows queue size, age bands and status by team, with filters for request type.
- Access is by role, and personal data is limited to what each viewer needs.
- Data stays inside the office's hosting environment, and changes to mapping rules are logged.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The office received service requests through several channels: phone, email, a web form and walk-in visits. Each team tracked its own list. Nobody could say how many requests were open, which team held them or how old they were. Delays were noticed only when a citizen or an elected official complained. Managers asked for reports that took staff days to compile, and the numbers disagreed. The office needed one view of open requests that teams would trust, without forcing everyone to change their tools at once.
- What did Brandsmashers build?
- Data feeds from the existing systems and a dashboard of open requests by team. Each team could see its own queue, request age and status, and managers could see the whole office. The dashboard was refreshed regularly from the sources, so it needed no extra data entry.
- How was the work run?
- We began by listing every channel and the system behind it, then interviewed team leads about how they tracked work. We agreed a small shared definition of a request: an identifier, a type, a team, a status and dates. Feeds were built one source at a time, starting with the busiest. After each, we checked the dashboard against the team's own list and fixed differences with the lead. A first version went live to managers, then to teams. A weekly review meeting was set up from the first month, and the dashboard became its agenda.
- What were the results?
- Average response time down 25%; backlog reviewed weekly.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
