You can watch the video of the show and tell on our YouTube channel: https://www.youtube.com/watch?v=a5wrzIQkrls

1. Lincoln
03 February 2020
Housing repairs alpha
Show and tell 2

2. Daria
Kwiatkowska
Service designer
Alex Yedigaroff
Transformation
manager
Our team
Debs Durojaiye
Designer
Vita Mangan
User researcher
James Smith
Technical architect

3. An alpha to understand
what a common pattern for
housing repairs would look
like

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. 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

7. Alpha
building prototypes and testing
different ideas.
testing the riskiest assumptions.

8. What is a service pattern
(and what makes it
common)

9. Apply for a
thing, get that
thing

10. 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)

11. This sprint:
● observations of repairs service
● cross-council design workshop
● technical discovery
● synthesising insights

12. Observing the
housing repairs
service

13. 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.

14. We learned about
the systems, tools
and processes
each council uses,
and identified the
similarities
between them

15. What does “completed”
really mean?

16. ● completed job?
● complete call?
● completed repair?

17. Reliance on paper, notes
and folders to have
information to hand easily

18. There is no feedback loop
between the trades and
the customer services
team

19. Residents lack visibility on
the stage they’re in in the
repairs journey and so call
up to chase requests

20. Online forms are manually
handled as emails, and do
not interact with any of the
other systems

21. Even if you start your
journey online, you’ll be
pushed into the call
journey

22. Reports come from many
directions, even internally;
wardens, inspectors,
housing officers, etc.

23. Repairs can be dropped
(fall out of the system) in
the hand-off between
different people

24. Agents context switch a lot,
moving between multiple
systems and have to enter the
same information in different
places

25. Agents don’t currently feel as
engaged in this alpha work as
they could be

26. Design workshop

27. We ran a design
workshop with 8
council staff from
Greenwich and
Southwark.

28. Workshop aims

29. 1. To explore and visualise
the common steps involved
in reporting a repair.

31. 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.

32. 2. To generate new ideas
for dealing with a repair
request.

33. Participants were split
into mixed groups of
two (one person from
each council) and
sketched ideas for
improving the
reporting process.

34. Appointment booking calendar,
which shows availability based on
repair request priority.

35. A virtual image of properties showing
which property is located where.

36. Collect customer satisfaction
feedback to help identify the parts of
the service that need improvement.

37. 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

38. Reduce the number of available
phone numbers residents can call to
request a repair.

39. 3. To gain further insight into
whether the current prototype
gathers the required information for
processing a repairs request.

40. Participants carried
out a design crit of the
prototype we tested
with residents.

41. Ask more questions early in the
journey to determine eligibility.

42. Ask questions to help identify any
assistance the residence needs to
make a request.

43. Some questions are poorly worded
and open to misinterpretation.

44. Questions on the type of property
and floor of property are missing
from the prototype.

45. Question about emergency repairs is
a little ambiguous - I have no water
could mean no hot water, no drinking
water or no secondary water.

46. Provide the option for a resident to
add a video to their report.

47. “Any online journey should provide
added value for the resident, and not
just duplicate current internal
processes”.

48. Mapping the service
pattern

49. https://verify-local-patterns.herokuapp.com/service-patterns/concessionary-travel/overview/policy

52. ● Check eligibility to use the service
● Report a repair or problem
● Choose availability
● Confirm appointment
● Submit request
● Get confirmation

53. https://miro.com/app/board/o9J_kv6WJzg=/

54. Technical discovery

55. Assessing high level data
needs of other systems and
mapping the sequencing

56. Review of the HACT data
standard

57. Next steps

58. We’ll continue building and
validating a service pattern

59. We’ll identify areas where
we have the most to learn
or test for iterating the
prototype

60. We’ll develop the business
and benefits case for
continuing this work past
alpha

61. We’ll actively share this
work with everyone
involved

62. Thank you!

63. Questions?