Catering for reality: Addresses will differ and be missing
In a perfect world, we'd expect users of a system or residents looking up their address against a definitive source to find it 100% of the time, however in reality this isn't the case. The below scenarios outline some of the situations where this can occur and why:
Issue | Implication | |
|---|---|---|
Scenario 1: Different understandings | Members of the public may refer to or know their address as something different compared to what it is legally known as, for example: "15A Forest Street" instead of "Flat 1, 15 Forest Street" OR "Sunshine Cottage, Heath Way", instead of "12 Heath Way" | Address appears to be incorrect to the resident |
Scenario 2: Early lifecycle capture required | The property being searched for exists on the ground, has planning permission and has gone through the Street Name and Numbering process but is not in the LLPG or any other address data product. The address should be captured as early as possible in its lifecycle. | Address appears to be missing |
Scenario 3: Unlawful property | The property being searched for exists on the ground but is not registered in planning or Street Name and Numbering. The address may be unlawful or unregistered. | Address appears to be missing |
Scenario 4: Data currency | The property being searched for exists in the LLPG, but does not yet exist in the OS address data product used to update the system / address search. This is due to how often the data product is updated. | Address appears to be missing |
Scenario 5: Search accuracy | The search tool being used by the software or system is ineffective and fails to display or return the users desired address despite them inputting an accurate search term. | Address appears to be missing |
In other words, no matter how accurate or official address data may be, it will always be challenged with the presence of missing or incorrect addresses.
The following sections go into further depth and detail around the process to handle this.
Integration needs to be flexible
The concept of "integration" is often seen as a firm, hard-line where only official, definitive addresses can be used in a system and nothing else. This can often lead to the mindset that if an address cannot be found when searched for, then the service request or use of the address shouldn't proceed until it has been duly investigated and added to the LLPG, a process which could take weeks.
The utilisation of definitive address data should support the delivery of services rather than prevent it from occuring.
For example, if an address being searched on a public facing web form cannot be found, then an option should be made available for the user to enter their address manually enabling their request to progress through.
Potential impacts and mitigation
Preventing service requests from being made due to an address not being found is likely to frustrate users and could impact those in need of critical council services.
It is also important to keep in mind what a "service request" could actually mean, for example it could be a member of the public reporting offensive graffiti, a missed bin or applying for a school place all of which are time-sensitive and are of high importance to the reporter.
How to handle manually entered addresses
It may seem counter-productive that manually entered addresses are being permitted, however this is a valuable source of address intelligence which can be investigated and in turn mitigated by following the below steps:
Point 4 is critical in that it serves to clear down and rationalise the manually entered addresses in the system it originated from. Not doing this allows their volume to creep up which in turn makes general communication and data-linking activities more difficult due to the absence of a UPRN. Therefore it is a key step to implement.
The "building sustainable integrations" guide goes into further depth around the process of handling manually entered addresses.