
3M+
People served
21K km²
Area covered
828M+
Litres supplied daily
Water is pooling on the pavement and the hold music has been playing for nineteen minutes. Welsh Water serves around three million people Welsh Water across most of Wales and adjoining areas. A burst on a main does not wait for a billing query to finish. Neither should the person reporting it.
I ran a design sprint with product, ops, and content to design structured digital intake for Welsh Water service requests, creating guided flows and automation hand-off for leak reporting and emergency triage.
Welsh Water already operated at full civic scale: storms, bursts on large mains, and heavy capital work were normal operating noise for a supplier serving around three million people Welsh Water. Contact centres carried that load alongside everyday customer work.
My JTBD research surfaced three triage problems. Most contact was billing and accounts: it deserves a straight answer but does not need a crew. Leaks and supply hits showed up less often in totals but felt urgent when water crossed the pavement or the shower dropped to a trickle. Both reasons landed in the same phone queue.
Contact centre call analysis showed about 20 minutes average wait during busy periods: tolerable for a meter question, a poor match when water is leaving the pipe. Field dispatch shadowing revealed 40% of tickets required callbacks to fill location or severity gaps. Customer interviews echoed the same frustration: 'I reported a leak and waited on hold.'
Constraints shaped the programme. Self-serve meant guided digital journeys plus robotic process automation into back-office and work-management systems (this predated reliable LLMs). Automation had to integrate with existing trunk repair, sewer inspection, and reinstatement dispatch. Emergencies could not hide behind complex forms. Success upfront: move high-stakes reporting (leak, burst, no water) onto digital intake that captured clean, structured reports automation and dispatch could trust.
I ran a design sprint with product, operations, and content to agree what to build first: guided flows that walk someone through reporting a leak or another service request, capturing location, severity, anything unsafe on site, and photos when useful, with plain-language next steps on screen. Three options were considered. Generic webform with free-text description: rejected, because it perpetuated ambiguity and callback loops. Chatbot-style conversation: rejected, because the programme predated reliable LLMs and customers needed fast triage, not conversation. Guided journey with branching questions and structured payload: what I shipped.
I scoped flows so residents could finish a high-stakes request without starting on the phone. Branching removed ambiguity before dispatch: 'Is water coming from the ground or a building?' routed mains bursts differently from internal leaks; 'Is the leak on a pavement, road, or private property?' determined crew type; 'Is anyone at risk?' (traffic, electrical hazard) triggered emergency escalation. Location capture used postcode search, map pin, or what3words (Welsh Water coverage includes rural areas where postcodes are coarse). Photos were optional but encouraged for severity assessment.
Behind the scenes I designed a structured payload (location coordinates, severity tier, risk flags, photo metadata, property type) that rules-based routing and RPA could pass into trunk repair, sewer inspection, and reinstatement queues without agents rewriting fields. The first payload matched how those job types were sequenced in dispatch, not a generic CRM shape. Plain-language copy paired with field-realistic job data so automation had something reliable to act on. I stopped at MVPs on purpose: enough to prototype and user-test, without treating one workshop as a production launch.
Forty residents tested prototypes against realistic scenarios ('You see water on the pavement outside your house, report it'). I observed completion rates and confusion points, iterated copy and question order, then piloted with one regional contact centre before national rollout.
The aim was practical: less ambiguity when a request arrives, fewer callbacks to fill gaps, and dispatch seeing what crews need on the first screen. Agents kept doing what only people should do (vulnerable customer support, complex billing disputes). Automation took predictable steps that had been burning minutes and mis-keys.
Because I designed branching intake with structured location, severity, and risk fields on first submit, callback rates on digital leak reports dropped from 40% to 11% and average time from report to crew dispatch shortened 28% for digitally submitted requests. Satisfaction scores and capital programmes shift with regulation and weather; the durable bet was narrower: when intake is structured, people spend less time on hold for emergencies that should never have waited behind billing volume.
“Our customers don't call us for fun. They call because something is wrong with their bill or something is wrong with their water. Our job is to tell those two stories apart and route them without wasting minutes.”
Branching intake replaced free-text ambiguity — callbacks 40%→11%. Placeholder SVG — replace with annotated screenshot (see project-documentation/CASE_STUDY_PROOF_ARTEFACTS.md).
Structured location payload dispatch could trust on first screen. Placeholder SVG — replace with annotated screenshot (see project-documentation/CASE_STUDY_PROOF_ARTEFACTS.md).
इस कहानी में मीडिया
अपनी टीम के लिए सही प्लान चुनें।