If you run a personal search company, you spend a surprising amount of your day on typing. Reading an order email, copying the address, working out which council, building the request in that council's format, placing the other parts, raising the invoice.
None of that is the skill. The skill is knowing what's wrong when something looks off. So the question isn't whether to automate, it's what to automate, and what to leave well alone.
What should you automate in a local authority search request?
Automate the repetitive admin that follows the same rules every time: parsing the incoming order, matching the address to a UPRN, building each council's request in its required format, routing the LLC1, placing the regulated parts with a provider, and invoicing. In our experience around 90% of addresses auto-match cleanly to a UPRN, so most orders never need a human to start them.
The work splits neatly once you look at it honestly. Some steps are mechanical. The same inputs always produce the same outputs. Those are the ones eating your team's hours, and they're the ones worth handing to software.
Order parsing is first. A solicitor sends an order, sometimes a clean form, often a forwarded email with the address buried in a paragraph. Pulling out the address, the property type, the instructed enquiries, and the requested products is pure pattern work. So is matching that address to a UPRN against AddressBase.
Then comes the council request itself. Every council in England and Wales wants its request a particular way: its form, its attachments, its quirks. Rossendale wants the admin ward. Some councils need a prior appointment. Building that request by hand, per council, from memory, is exactly where automation earns its place.
How do you automate the council request in each council's format?
You automate the council request by holding every council's requirements as data, then generating the request from that data instead of from someone's memory. Each council's form, attachments, fee, and submission method are stored once and applied automatically. The operator who "just knows the councils" stops being a single point of failure.
This is the council knowledge problem in practice. The format isn't optional decoration. Send a request in the wrong format and the council rejects it, or worse, sits on it for a week before telling you. That's lost turnaround you can't get back. The council knowledge problem goes deeper on why this data is so hard to hold.
The LLC1 is where routing matters most right now. Around a third of authorities have migrated their Local Land Charges to HM Land Registry's national register for England and Wales, with the programme targeting 2028. For a migrated council, the LLC1 comes from the register, free as a search result or £15 for the official certificate. For a council that hasn't migrated, it still goes to the council direct, with their fee and their wait.
Here's the trap. The register holds the LLC1 only, never the CON29. So even in a fully migrated area, you still raise a council CON29 request the old way. Automation that treats migration as "this council is now done" gets it wrong. The split is per-search-part, not per-council. Get that distinction into your routing logic or you'll either pay LLC1 fees you don't owe, or chase a CON29 from a register that never had it.
What must stay a human decision?
Keep humans on judgement, always. Address exceptions the matcher can't resolve, odd or contradictory instructions, and the final check of the returned report. These are the steps where being wrong is expensive, and where the right call depends on twenty years of pattern recognition, not a rule. Automation should escalate these, not guess at them.
Take the address that won't match. A new-build with no UPRN yet. A flat described three different ways across the order. The software should flag it and stop, not pick the nearest guess and carry on. The worst errors I've seen weren't from slow staff. They were from a request that went to the wrong property because someone, or something, resolved an ambiguous address without checking. Once that report's with the solicitor, it's your problem.
Then the odd instruction. A solicitor asks for something that doesn't fit the property, or contradicts itself, or wants a product that doesn't apply here. A person spots that in two seconds. Automation will happily process nonsense at speed. So the instruction that doesn't make sense should land in front of someone who knows the work.
And the final report check stays human, full stop. Not "did it arrive", but "is it complete, are the optional enquiries answered, is anything blank that shouldn't be". That gate is the thing protecting your name. Automate everything up to it. Never automate it.
Automate vs keep human: the split that works
The simplest way to think about it is two columns. If a step follows the same rule every time, automate it. If a step needs judgement about something unusual, keep a person on it. In our experience that division returns most searches in 24–72 hours without anyone touching the routine ones.
| Automate (repetitive, rule-based) | Keep human (judgement) |
|---|---|
| Parsing the incoming order | Address exceptions the matcher can't resolve |
| Matching the address to a UPRN | Odd or contradictory instructions |
| Building each council's request format | Deciding when a council quirk has changed |
| Routing the LLC1 (migrated vs not) | The final report completeness check |
| Placing the regulated parts with a provider | Borderline calls on product applicability |
| Raising and sending the invoice | Anything the system flags as an exception |
Across our own processing, roughly 90% of orders pass straight through the automated path: parsed, matched, requested, placed, invoiced, with no manual start step. The remaining 10% are the exceptions, and that's where your team's expertise goes, instead of into retyping addresses. That ratio is the whole argument. Automation doesn't replace the expert. It clears the desk so the expert only sees what actually needs them.
"Automation isn't about the software being clever. It's about it being boring and reliable on the boring, reliable bits, so my best person isn't copying postcodes all morning. They're checking the report that's about to go out with our name on it. That's where I want their attention. Always was."
— Valerie Bennett, Personal Search Veteran · June 2026
Provider placement and invoicing round it off. The drainage and water, the coal report, the regulated parts that go to a provider: placing those follows fixed rules once the products are known. So does the invoice. Both are admin, both are automatable, and neither needs a person unless something fails.
Conclusion
Automating local authority search requests isn't a threat to the expertise, it's a way to protect it. The parsing, the council formatting, the LLC1 routing, the placement, the invoicing: hand all of it to software that does it the same way every time. Then put your people where being human actually pays, on the exceptions and the final check.
The firms that get this right aren't the ones who automate the most. They're the ones who automate the right things and guard the rest. Removes the repetitive, keeps the judgement. That's the whole trick.
See how council data works in Valio → · The back-office workflow, end to end → · Valio features →