1.sam-researching-casework.pdf

Transcript

1. Researching ‘casework’ Property boundaries - myth and legend
2. Boundary queries - lots of them and they’re emotive Title boundary Legal boundary (invisible and imprecise) Physical boundary (a wall)
3. Research aims • what’s the [customer] trying to do - what are their needs? • what are call handlers and caseworkers doing and why? • what’s it like for caseworkers when they use the existing systems? • what actually needs to happen* behind the scenes? * not just what’s currently happening
4. Approach 1. Desk research (volumetrics, staff surveys, speed of service etc) 2. Contextual research (observing calls, triage, workflow) 3. Themed workshops (3 half-day workshops in 2 locations) 4. Playback of quick wins and long-term solutions
5. Contextual research: 2 key types of boundary query Citizens phone us to ask us who owns a fence, wall or hedge (usually because it needs repairing) Solicitors send us letters about boundary location disputes (they want us to investigate and provide a definitive answer, or at least arbitrate)
6. We found out that users had heard a lot of myths
7. It’s a myth that... • Both of you ‘own’ a boundary feature • If you come out of any door in your property and turn left, you own that boundary • If the fence posts are on your side, you own the fence • The title plan will have T marks on it that show ownership • The ‘Party Wall Act’ explains ownership of a boundary feature • HMLR can fix title plan issues • HMLR knows the answer • HMLR can arbitrate
8. We found 1 issue straight away HM Land Registry can’t tell you who owns a physical boundary ‘feature’ - ie a wall, hedge or fence. • sometimes your deeds or title will say who owns it - but we can’t tell you that • you can make an agreement with your neighbour and have this registered • but this isn’t easy to do...and it’s only valid while you both own your properties This is the main reason citizens call us about boundaries - yet it’s a myth that we have the answer or can help
9. Who owns (and must fix) the fence that blew over?
10. Pain points “Poor quality or incomplete applications” “Ineligible applications” “Systems that make it really hard to do your job”
11. “Bad internal user experience creates a burden that means the people in your organisation won’t always have the motivation, time, or willpower to do what it takes to deliver a level of service that is going to work best for your customers.” Ben Holliday
12. We asked what happens when users struggle • “they get things wrong” • “they call for advice which we can’t provide” • “they think we can arbitrate when we can’t” We have to fix all this, which takes time, money and patience - and causes delay. Every service failure = a pain point for us.
13. We heard some legendary ‘received wisdom’ “I need to check everything I can, including the applicant’s ID so I know their interest” (nope) “We need to help them sort this out” (also nope) “We’re the authoritative source of information on boundaries” (we’re not) “All applicants should know the process” (haha)
14. Quick wins Reducing demand for services by encouraging self-service Reducing avoidable contacts by tackling myths
15. So far • Boundary guidance for citizens on GOV.UK rewritten and simplified • Mythbusting boundaries blog published • Key referrers identified, contacted and asked to link to the new guidance (rather than giving out our phone number) • Updated HMLR guidance on boundary disputes • Call centre staff guidance updated
16. Service map: reporting boundary location errors
17. Started a conversation about reported boundary location errors... 0.04% are registration errors on our part 90% of queries
18. Is this fence in the wrong place?
19. Helped frame the problems we’re trying to solve “We need a better way for people to ask us to correct a boundary location error which they think is our fault.” For this to happen: 1. They’ll have to provide evidence - title deed and title plan 2. We’ll check this against our records 3. We’ll make a decision 4. We’ll tell the applicant about the outcome - and what to do next
20. Emerging patterns for our registration casework 1. user identifies the property 2. user explains why the change is needed (eligibility) 3. HMLR checks against its records 4. HMLR makes a decision (to change or not to change) 5. HMLR notifies the user of the outcome (and what to do next) Identifying common service stages means we can assemble services from common components, eg ‘Find property’, ‘Submit’, ‘Route’ etc