Successfully reported this slideshow.
Your SlideShare is downloading. ×

Housing repairs alpha show & tell 2 - 3 February 2020

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 63 Ad
Advertisement

More Related Content

Similar to Housing repairs alpha show & tell 2 - 3 February 2020 (20)

More from dxw digital (13)

Advertisement

Recently uploaded (20)

Housing repairs alpha show & tell 2 - 3 February 2020

  1. 1. Lincoln 03 February 2020 Housing repairs alpha Show and tell 2
  2. 2. Daria Kwiatkowska Service designer Alex Yedigaroff Transformation manager Our team Debs Durojaiye Designer Vita Mangan User researcher James Smith Technical architect
  3. 3. An alpha to understand what a common pattern for housing repairs would look like
  4. 4. If I need a repair in my home (or in a communal area), I can easily and confidently find information about how to resolve my issue, request and book a repair and understand what will happen, and by when. Vision: residents
  5. 5. If a resident needs a repair in their home (or in a communal area), the correct diagnosis can be easily made so that the right people with the right tools can fix the problem in the right timescale. Vision: organisations
  6. 6. Alpha building prototypes and testing different ideas. testing the riskiest assumptions.
  7. 7. What is a service pattern (and what makes it common)
  8. 8. Apply for a thing, get that thing
  9. 9. discovery ● Modelled on steps from the organisational perspective ● Assumes a linear journey ● Identifies tasks and data points ● Need to define more ‘how?’ and ‘why?’ (and why can’t we)
  10. 10. This sprint: ● observations of repairs service ● cross-council design workshop ● technical discovery ● synthesising insights
  11. 11. Observing the housing repairs service
  12. 12. We visited the housing repairs customer service teams at Lincoln and South Kesteven and observed how the teams handle different types of housing repairs requests.
  13. 13. We learned about the systems, tools and processes each council uses, and identified the similarities between them
  14. 14. What does “completed” really mean?
  15. 15. ● completed job? ● complete call? ● completed repair?
  16. 16. Reliance on paper, notes and folders to have information to hand easily
  17. 17. There is no feedback loop between the trades and the customer services team
  18. 18. Residents lack visibility on the stage they’re in in the repairs journey and so call up to chase requests
  19. 19. Online forms are manually handled as emails, and do not interact with any of the other systems
  20. 20. Even if you start your journey online, you’ll be pushed into the call journey
  21. 21. Reports come from many directions, even internally; wardens, inspectors, housing officers, etc.
  22. 22. Repairs can be dropped (fall out of the system) in the hand-off between different people
  23. 23. Agents context switch a lot, moving between multiple systems and have to enter the same information in different places
  24. 24. Agents don’t currently feel as engaged in this alpha work as they could be
  25. 25. Design workshop
  26. 26. We ran a design workshop with 8 council staff from Greenwich and Southwark.
  27. 27. Workshop aims
  28. 28. 1. To explore and visualise the common steps involved in reporting a repair.
  29. 29. Participants added questions and notes to the service workflow, which gave us a clearer picture of the types of decisions they need to make when processing a request.
  30. 30. 2. To generate new ideas for dealing with a repair request.
  31. 31. Participants were split into mixed groups of two (one person from each council) and sketched ideas for improving the reporting process.
  32. 32. Appointment booking calendar, which shows availability based on repair request priority.
  33. 33. A virtual image of properties showing which property is located where.
  34. 34. Collect customer satisfaction feedback to help identify the parts of the service that need improvement.
  35. 35. Use of photos and videos: - to request a repair - as proof of any work done (before and after pictures) - as proof of a contractor visit when a resident is out - to help explain what repairs a leaseholder can report
  36. 36. Reduce the number of available phone numbers residents can call to request a repair.
  37. 37. 3. To gain further insight into whether the current prototype gathers the required information for processing a repairs request.
  38. 38. Participants carried out a design crit of the prototype we tested with residents.
  39. 39. Ask more questions early in the journey to determine eligibility.
  40. 40. Ask questions to help identify any assistance the residence needs to make a request.
  41. 41. Some questions are poorly worded and open to misinterpretation.
  42. 42. Questions on the type of property and floor of property are missing from the prototype.
  43. 43. Question about emergency repairs is a little ambiguous - I have no water could mean no hot water, no drinking water or no secondary water.
  44. 44. Provide the option for a resident to add a video to their report.
  45. 45. “Any online journey should provide added value for the resident, and not just duplicate current internal processes”.
  46. 46. Mapping the service pattern
  47. 47. https://verify-local-patterns.herokuapp.com/service-patterns/concessionary-travel/overview/policy
  48. 48. ● Check eligibility to use the service ● Report a repair or problem ● Choose availability ● Confirm appointment ● Submit request ● Get confirmation
  49. 49. https://miro.com/app/board/o9J_kv6WJzg=/
  50. 50. Technical discovery
  51. 51. Assessing high level data needs of other systems and mapping the sequencing
  52. 52. Review of the HACT data standard
  53. 53. Next steps
  54. 54. We’ll continue building and validating a service pattern
  55. 55. We’ll identify areas where we have the most to learn or test for iterating the prototype
  56. 56. We’ll develop the business and benefits case for continuing this work past alpha
  57. 57. We’ll actively share this work with everyone involved
  58. 58. Thank you!
  59. 59. Questions?

Editor's Notes

  • Alex
  • Alex
    Multi disciplinary
    Multi authority
  • Alex
  • Alex Set in inception. Guiding star
  • Alex
  • Alex
    Phases.
  • Alex
  • Alex Best practice for providing services that meet user needs
    Does not require uniformity
    Does not mean a single system that all councils will use
    Some councils could adopt all or part of a pattern. Maybe they gave a digital development team
    Existing suppliers could also adopt the pattern. That too would be a good result/.
  • Housing repairs is a more complex service, as, depending on the information that a resident provides in the reporting journey, many different things can happen. There are also parts of the journey that aren’t linear - for example diagnosis can happen in several different places (on the phone, during a visit) and jobs are often not completed on the first visit and require multiple tradespersons - potentially sending the resident back to an earlier part of the journey.
    Because of this, we’re defining where there are patterns in the different stages of the reporting and booking journey, rather than assuming that a single end-to-end pattern is the answer. For example what the patterns are for ‘checking eligibility’, ‘reporting a problem’ and ‘checking availability’. Where patterns exist in these different stages, local authorities may be able to adopt the patterns in part of the journey if they have constraints that prevent them adopting the whole journey.

  • Alex

    Example - task = assess responsibility. Pattern needs to give best practice advise on how to do this.
    Another example - task - confirmation to customer. What is the best way to do this in order to increase confidence for the resident and reduce calls for the organisation


  • Alex
  • Daria
  • Daria
  • Daria

    We spent some time watching and learning how the team currently help to book repairs
    Interesting to spend time with the team and hear about their experiences
  • Daria
  • Daria
  • Daria
  • Daria
  • Daria
  • Daria
  • Calling is the default mode of communication
  • Daria
  • Daria

    We saw that as council’s send out experts to review what needs to be done, the experts requests for repairs might not be fed back into the system so the council has to send out another expert to review what needs to be done...and the resident is stuck in an eternal loop, costing the council money
  • Daria
  • Daria

    Keeping the team informed, sharing the outputs and asking for feedback from the team who are closest to housing repairs
    Sharing our vision, showing what we’re trying to do
    Helping agents to see how their time and effort is helping us reach that
  • We ran this workshop with three aims in mind.
  • We spent some time observing customer service agents in Lincoln and Grantham, we worked some of the common processes into a service workflow. We wanted to find out how much of those processes aligned with what agents at Lincoln and Southwark did. This was a simplified map showing the types of decisions CSAs made when dealing with a repair report.


  • This is useful for leak reports where the issue might be caused by a flat above.
  • This is useful for leak reports where the issue might be caused by a flat above.
  • This is useful for leak reports where the issue might be caused by a flat above.
  • Leaseholder or tenant, reporting on behalf of someone else
  • Another language required?
  • We ask where the repair is located, which could mean where in the apartment is the repair located or what is the address of the repair.
  • These questions are helpful for diagnosing possible sources of a problem.
  • Online journeys should be an improvement and reduce the burden of requesting a repair on the resident and on customer service agents.
  • Daria
  • Daria
    What does a pattern look like?
    Based on all of the work we’ve done, we were able to start building out a service pattern
  • Daria
    Started with a step view of the process
    Establishing what reusable sub-patterns might fit within the whole service: e.g. a pattern for “communicate the problem”
  • Daria
    Refined to reach a higher level view of the pattern
    Grappled with how to keep the service focused on the resident and their language while still being clear about the council’s responsibilities and backstage actions at each step of the pattern
    It is a non-linear process; how could the pattern address non-linear journeys?
  • Daria
    We had a collaborative session where we put our heads together on how to evolve this thinking
    Current iteration of service pattern steps looks like this
    User focused language, high level steps
  • Daria
    Within each larger service pattern step, captured the smaller steps that happen at each stage of the pattern for both the user and the council
    Looked at the data points that would be needed for each step
    Supporting each step and the reasoning behind it with research (both our own, and secondary)
  • Alex
  • Alex
  • Alex
    HACT - 'When it’s decided what the work is’ not the reporting stuff, but we can hook into it
  • Alex
  • Alex
  • Alex
  • Alex
  • Alex

    Make sure that the customer service team feel very involved in this work, building a sense of ownership when it comes to implementation
  • Alex
  • Alex

×