Running a Personal Search Business: What Nobody Tells You About the Back Office

There's a version of running a personal search business that looks fine from the outside.

Orders come in. Searches go out. Invoices get paid. The team knows what they're doing. You've been doing it for years and it works.

Then someone leaves. Or volume jumps. Or a council changes their submission process and nobody notices for three weeks. And suddenly what worked is held together with overtime and the institutional knowledge of one person who's quietly thinking about what else they could be doing.

I've seen this in firms processing fifty searches a week and firms processing five hundred. The shape is always the same.

The market underneath it is not small. There were around 1.1 million residential property transactions across the UK in 2024 (HMRC), and every one of them needed searches. The firms that handle that flow without it turning to chaos all do the same things — and they're not the things most people expect.

The thing that actually breaks most search businesses

It's not the councils. It's not the solicitors. It's the fact that most search operations are built around people remembering things rather than systems knowing things.

The right council email address lives in someone's sent folder. The admin ward requirement for Rossendale is something your most experienced processor just knows. Which orders are overdue is visible to whoever happened to check the spreadsheet last. The invoice goes out when someone gets a minute.

None of this feels like a problem when it's working. It only becomes a problem when it stops — and by then you're already behind.

What the order-to-invoice process should look like

Here's every step in a search, and where the wheels typically come off.

Order in

An email arrives from a solicitor. In a manual workflow, someone reads it, pulls out the relevant details, and enters them somewhere — a spreadsheet, a shared system, a notebook. If they're busy, it waits. If they misread a postcode, the error travels through every step that follows.

In a well-run operation, the order is parsed automatically. The data goes into the system. Nothing gets typed twice.

Address cleansed, UPRN confirmed

The address the solicitor sends is rarely in the format the council or Land Registry uses. Before anything else happens, it needs to match to a confirmed UPRN — the unique reference number that anchors the search.

About 90% of addresses match automatically. The other 10% need manual work. That's unavoidable. What is avoidable is spending twenty minutes on each one because the lookup tools aren't good enough or the exception process isn't clear.

Council request out

This is where institutional memory does the most damage.

Every council in England and Wales has its own way of working. Some want the request by email; some have portals. Some need the admin ward included; most don't. Some need a prior appointment before they'll accept anything. Some have specific attachment formats. Some councils will reject a submission over a single missing field and you won't know for three days.

A firm that has all of this in a proper system can send the right request to the right place in the right format without anyone having to think about it. A firm where this lives in people's heads works fine — until it doesn't.

Boundary plan attached

Every council request needs a property boundary plan. Pulling it from HM Land Registry's INSPIRE data, getting it in the right format for the right provider, attaching it — this is a handful of steps that should take seconds, not minutes.

If someone on your team is manually downloading plans and converting formats, that's time that should be spent on something else.

Providers placed

Drainage and environmental searches go to Landmark or Martello, not the council. In most operations this means logging into a separate portal, entering data that's already in your system, and placing the order.

Multiply that by every search you process in a week. It adds up.

Responses tracked, not chased

This is where the shared inbox shows its limits.

When a council response is running late, you want to know before the solicitor does. That means tracking expected return times against actual, not waiting for someone to notice that an email hasn't arrived.

The best operations have a clear view of what's in flight, what's due when, and what needs chasing today. Most have someone who checks the inbox and hopes nothing's been missed.

Report built from data, not typed from scratch

When the council response comes back, the report needs to be built. In a manual workflow that means opening a Word template and typing in the answers from the council's email. That's slow. It's also where errors happen — not because people are careless, but because transcription is inherently imperfect.

A system where the report populates from data already captured cuts that risk significantly. The processor checks and approves. They don't type.

Invoice out, not when someone gets round to it

The search is done. The report is issued. At this point, in most firms, the invoice happens somewhere between immediately and two weeks later, depending on who's busy.

Invoicing from completed order data — automatically, at the point of issue — means the gap between doing the work and asking for the money is as short as possible. Month-end stops being a task that takes most of a day.

---

"The back office of a search company is more intricate than anyone outside the industry gives it credit for. But intricate doesn't have to mean complicated. When I was processing at scale, the difference between a good week and a bad week wasn't how hard the team worked. It was whether the process held up — or whether someone had to hold it together."

— Valerie Bennett, Personal Search Veteran · June 2026

---

What does a single search actually look like start to finish?

One real search, start to finish, in a firm where the process holds. The order lands at 9am. The address auto-matches to a UPRN in seconds. The council request goes out by 9:20. Manchester returns it in four days. The report is checked and issued, and the invoice goes the same hour.

Let me walk through that one properly, because the gap between this and a bad day is entirely in the detail.

The order lands at 9am from a conveyancer in Didsbury. It parses automatically: applicant, address, search type, all in the system without anyone typing a postcode. By 9:05 the address has matched to a confirmed UPRN. It's a terraced house with a clean record, so it's one of the ~90% that match without a second look.

Manchester City Council wants the request a particular way. The system already knows that, so the LLC1 and CON29 request goes out by 9:20 in the right format, to the right address, with the INSPIRE boundary plan attached. At the same time the CON29DW drainage search is placed with the provider, no second login, no re-keying.

Then we wait. That part you cannot speed up. Manchester returns the result on day four, which is normal for them. The CON29DW is already back. The report builds from the data we captured at the start, the processor checks it rather than types it, and it's issued before lunch. The invoice goes out the same hour, automatically, from the completed order.

Total hands-on time inside the firm: maybe fifteen minutes across two touches. The rest was the council wait, which is the council's, not yours. That's what good looks like. Now compare it to the same job where the postcode was mistyped at intake, the request went to a stale email address, and nobody noticed until the solicitor chased on day seven.

Manual workflow versus a connected system: where do they differ?

At every stage of a search, the difference between a manual workflow and a connected system is the same: who carries the knowledge. In one, a person does, and the work waits on them. In the other, the system does, and the work just moves. Here's each stage side by side.

The manual column is not wrong. It is how most good firms have always worked, and at low volume it is genuinely fine. The trouble is that every box in that left-hand column depends on a person being available, accurate and not on holiday. More on where firms quietly lose time sits inside that left column, not the council wait.

How does the back office actually break?

The back office rarely breaks loudly. It breaks in four predictable ways, and each one shows early warning signs weeks before it becomes a crisis. The key person leaving, a volume spike, a council changing its process, and the silent stall. Knowing the signs is most of the fix.

The key person leaves

Your most experienced processor knows which councils want the admin ward, which one rejects a missing field without telling you, and where the good email addresses live. None of it is written down. When they hand in their notice, that knowledge is on a clock. The early sign is simpler than you'd think: notice how often the rest of the team asks them a question they can't answer from a system. That's the measure of your exposure. This is the council knowledge problem in one sentence.

Volume spikes faster than the process

A new client doubles your weekly orders and the manual steps that were merely tedious become a backlog. Turnaround slips, chasing falls behind, invoices lag. The warning sign is overtime creeping in before headcount does. If a good week now depends on nobody being off, you've already outgrown the manual workflow, you just haven't admitted it yet.

A council changes something quietly

A council switches to a portal, changes a required field, or updates an email address. Nobody announces it. Your requests start bouncing or stalling, and because the failure is silent, you find out from the solicitor. The warning sign is a single council's rejections or non-responses clustering in a way they didn't before.

The silent stall

The worst one. An order sits, not chased, not flagged, not lost exactly, just not moving. No alarm goes off because nothing visibly went wrong. You discover it when the solicitor rings, annoyed, on day ten. The only defence is a view of every order's status that doesn't rely on someone remembering to look.

What should a well-run search firm measure?

A well-run firm watches four numbers, and none of them is "how hard the team worked". Turnaround by council, the percentage of addresses that auto-match, the size of the overdue queue, and time-to-invoice. Track those and the operational problems show up as a trend before they show up as a complaint.

Turnaround by council tells you which authorities are slow this month and which are slipping, so you can warn the solicitor early rather than apologise late. Auto-match rate (the share of addresses resolved without a person) tells you how much manual effort is buried in intake. The overdue queue is your real-time backlog: it should be near zero, and a creeping number is the first sign the process is straining. Time-to-invoice, the gap between issuing the report and raising the invoice, is pure cashflow, and in most manual firms it's far longer than anyone realises.

You don't need a dashboard to start. You need to know the four numbers and watch them move. The firms that grow without chaos are simply the ones that noticed the trend early.

What this looks like in practice

The firms I've seen run well are not the ones with the most experienced staff. They're the ones where a new person can pick up an instruction and know exactly what to do — because the system tells them, not because they had to ask.

Every council requirement is documented and up to date, in the system, visible to everyone. Every order has a clear status. Every overdue response is flagged before the solicitor notices. Every completed search triggers an invoice.

That's not complicated. It's just a process that's been built rather than inherited.

Valio runs this process for you — from the order arriving to the invoice going out, with every council in England and Wales already configured. Most firms are live the same day.

See how it works → · How the council knowledge base is built → · How the subcontracting network works →