Public Sector Transformation (GDS)

Case Study: Public Sector Intake & Service Transformation – A Discovery – First Approach to High-Volume Service Delivery

Project

Role: User Research Consultant (Service Design & Agile Delivery)

Domain: Public Sector Digital Transformation & GDS-Aligned Service Design

Context: UK Government Department Shared Inbox Intake Optimisation (managing 50,000 monthly emails)

Goal

Executive Summary & Project Context

A public sector organisation faces massive operational intake volumes, with 50,000 emails per month into a shared Outlook inbox. The immediate organisational reflex would be to deploy rapid AI automation or custom software to clear the backlog. However, rushing into technical solutions without empirical evidence frequently accelerates chaos.

This case study outlines an agile, UK Government Service Standard (GDS)-aligned user research and service design plan. The objective was to transition a government department from reactive firefighting to structured, evidence-led service delivery by establishing a CRM-first triage baseline before introducing automation.

Research Methodology & Framework

To capture both citizen friction and internal operational constraints, a mixed-methods research strategy would be deployed across a 4-week discovery phase using a commercial or existing CRM, drawing on established service design methodologies:

  • Contextual Inquiry: Shadowing internal customer service operators (e.g., Anna) to observe real-time workflow bottlenecks during peak email intake.
  • Participatory Design: Engaging internal teams and citizen proxy groups to co-design status workflows and triage taxonomies.
  • Task Analysis & Inbox Auditing: Analysing a structured sample of the 50,000 monthly emails to categorise requests, measure time on task, and identify failure points.
  • Customer Feedback Synthesis: Coding unstructured email text and user inquiries into thematic categories to isolate high-frequency pain points.

The Diagnosis & The “Automation Trap”

Secondary research and industry data reveal a critical risk in public sector digital transformation: “37% of public sector AI pilots are paused or abandoned after discovery because they lack sufficient user evidence.”

Key Operational Bottlenecks:

  1. The Citizen Black Hole: Citizens emailing the shared inbox received auto-replies with no status tracking, leading to anxiety and avoidable phone channel congestion.
  2. Internal Firefighting: Multiple operators frequently working on the same requests in silos due to a lack of ticketing visibility, creating duplicated effort and long response delays.
  3. The 1 in 4 Accessibility Barrier: Official data indicates that 1 in 4 UK service users struggle with digital government channels due to the inaccessibility of contact channels. Unvalidated automation risked excluding these vulnerable cohorts.

User Persona & Ecosystem Mapping

To ground the research in human needs rather than system metrics, the service ecosystem was mapped across two primary user profiles:

Public Service Ecosystem

Ecosystem DimensionExternal Citizen (Muhammed, 31)Internal Operator (Anna, 35)
Core NeedsVisibility, predictable response timeframes, and assurance that their request is being actively handled.Clear prioritisation, categorisation, and actionable insight on request trends to reduce team burnout.
Primary Pain PointsGhost inbox anxiety and lack of a transparent status-tracking portal.Shared Outlook inbox chaos, duplicated handling across silos, and constant reactive firefighting.

The Solution: CRM-First & Triage Protocol

Rather than building custom software from scratch or deploying ungrounded AI bots, the intervention proposed a CRM-first, triage-before-automation model, leveraging existing legacy government architecture or secure commercial systems like Zoho:

  1. Structured Ticketing Layer: Routing the control sample of 50,000 monthly emails through a centralised CRM ticketing environment to understand bottlenecks.
  2. Tagging Taxonomy & Status Workflows: Implement clear status tracking, e.g. Responded, Processed, Blocked, Complete and categorisation to separate low-value repetitive queries from high-value policy issues.
  3. Evidence-Backed Automation: Use the empirical data gathered during the CRM trial to identify what is safe to automate (e.g., A/B testing GDS-aligned canned responses, building dynamic FAQs, and automating missing-document checks).

GDS Agile Delivery Roadmap (Alpha, Beta, Live)

To ensure risk-controlled execution and full compliance with GDS delivery standards, the research and implementation roadmap was structured across distinct agile phases:

[DISCOVERY] ──► [ALPHA: Month 1] ──► [BETA: Private & Public] ──► [LIVE: Continuous]

Baseline — CRM Concept Test — Workflow Scaling & KPIs — Iterative Loops

  • Preliminary Research & Discovery: Audit existing cross-departmental government legacy systems before procuring commercial tools to avoid “reinventing the wheel,” ensuring unique departmental requirements, privacy, and legislative compliance are met from day one.
  • Replacing Assumptions: The discovery phase prevents equating assumptions about autoreply clarity, contact-channel accessibility, and the need for application status-testing when there is no evidence of where bottlenecks and problems are located.
  • Alpha Phase (Month 1 — Concept & Taxonomy Testing): Deploying the CRM ticketing prototype (e.g., Zoho or legacy equivalent) on a controlled sample of incoming emails. Testing tagging taxonomies, establishing Standard Operating Procedures (SOPs), and A/B testing GDS-aligned canned auto-responses with clear timeframes validate reductions in citizen follow-up anxiety.
  • Beta Phase (Private & Public Trials): Rolling out the validated workflow across internal operator teams (Internal Beta) followed by wider citizen-facing channel integration (External Beta). Measuring empirical metrics, including time-on-task, backlog reduction, resolution rates, and internal team satisfaction via incremental user surveys, to build the business case for safe automation.
  • Live Phase (Continuous Iteration & Scaling): Transitioning to full operational service with continuous feedback loops, post-service citizen surveys, and automating routing/FAQs driven strictly by proven Beta behavioural data.
  • Stakeholder feedback/pushback: Treating feedback from stakeholders, citizens and internal team members as vital evidence of the progress of the system is necessary. Managing expectations given the high-volume inbox is paramount.

Governance & GDS Alignment by Design

The entire framework is strictly anchored to the UK Government Service Standard:

  • GDS Points 1 & 2 (Understand user needs & ongoing research): Replacing internal assumptions with real CRM behavioural data during the Alpha testing phase and ongoing Beta iterations.
  • GDS Point 5 (Make sure everyone can use the service): Addressing accessibility needs for the 1 in 4 service users struggling with digital channels, ensuring alternative, inclusive access pathways. The system can still be advertised in communal public spaces like libraries, one-stop shops and community halls/event spaces.
  • Privacy & Legislative Compliance: Utilising established government-compliant architecture to maintain data minimisation, role-based access control, and strict public sector data protection standards.

Value Realisation & Expected Outcomes

  • Reduced Team Stress: Eliminating fragmented, duplicate handling among customer service staff, replacing firefighting with structured workflows.
  • Greater Citizen Confidence: Replacing ghost-inbox anxiety with transparent status tracking, predictable response timeframes, and clear guidance.
  • An Unassailable Business Case for Scale: Generating concrete operational metrics (time-on-task, resolution rates, error frequencies) to prove what processes are safe to automate before committing public sector capital to large-scale technical builds.

[RAW INBOX VOLUME: 50,000 EMAILS/MONTH]

│

▼

[CRM-FIRST TRIAGE PROTOCOL]

Categorise ──► Tag ──► Prioritise ──► Track

│

▼

[EVIDENCE-BACKED AUTOMATION & SCALE]