Most personal search companies start on a spreadsheet. One tab for live orders, a shared inbox for the council traffic, and one person who just knows how it all hangs together.
And for a while, that's genuinely fine. It's cheap, it's flexible, and it bends to whatever you need.
Then volume grows. A second person joins. A third. And the same spreadsheet that ran the whole operation quietly starts working against you.
This isn't a "spreadsheets are bad" piece. They're not. It's about the specific points where they break — and what to do about it.
Are spreadsheets actually a problem for a search firm?
Not at low volume. A spreadsheet and a shared inbox work well while one person can hold the entire pipeline in their head and edit one row at a time. The trouble starts as you grow — more orders, more people, and more chances for two of them to overwrite each other.
The honest version: spreadsheets don't break because they're bad tools. They break because they were never built to be the operating system for a multi-person firm processing dozens of orders a day. They have no concept of an order, a status, or a deadline. They're a grid that you've taught to behave like a system through habit and memory.
That works until the habit and the memory hit their limit.
Where do spreadsheets break a growing search firm?
They break in six predictable places: version conflicts, no live order status, key-person risk, no proactive chasing, manual invoicing, and no audit trail. Each one is survivable on its own. Together, at volume, they quietly drain your turnaround and your margin.
Let's take them one at a time.
Version conflicts and overwrites
Two people open the master sheet. One updates a status, one updates a fee, and the save order decides whose change survives. The other one's just gone. Nobody notices until a report goes out with the wrong figure on it.
Shared cloud sheets help, but they don't fix the underlying issue: a spreadsheet has no record of who changed what, or why. You're trusting that everyone edits the right row and nobody fat-fingers the one above it.
No live order status
Where's order 4471? On a spreadsheet, the honest answer is often "let me check with whoever sent it." There's no single, trustworthy status that the whole team can see, so the status lives in someone's memory and the inbox. A solicitor chasing for an update means a person going digging.
Key-person risk
This is the big one. The council knowledge — Rossendale needs the admin ward, which councils want a prior appointment, which ones bounce a certain attachment format — that lives in one person's head, not the spreadsheet. The grid records what happened. It doesn't hold what they know.
It works, until that person is off sick. Until they take a fortnight in Spain. Until they leave. Then the operation slows, and you find out how much of your firm was running on one memory.
No proactive chasing
A council goes quiet. On a spreadsheet, that order just sits there, blank, until someone scrolls past and thinks to ask. Chasing depends on a human remembering — and at fifty live orders, humans forget. The slow ones are exactly the ones that slip, because they don't shout.
Manual invoicing
The work's done, the report's out, and now someone rebuilds the figures by hand into an invoice. Disbursements, the council fee, your charge, copied across from the order row. It's slow, it's error-prone, and it's usually the bit that gets left to Friday afternoon — which is how cash slips.
No audit trail
When a solicitor queries a result six months later, can you show what was requested, when it came back, and who signed it off? On a spreadsheet, the row's been edited forty times since. The history's gone. For a YMYL service like property search, "I think that's what we did" is not a strong place to stand.
"I've watched a firm lose two days because the one person who knew the council routing was on holiday and the spreadsheet didn't say a thing. Nobody did anything wrong. The knowledge just wasn't anywhere you could get at it. That's the bit a grid can't fix."
— Valerie Bennett, Personal Search Veteran · June 2026
What does a connected system do instead?
A connected system replaces memory with structure. Instead of a grid you've trained to act like a system, you get one that actually models the work: every order has a live status, councils get chased on a schedule, the knowledge sits in the system, and the order flows straight through to invoice with a full history behind it.
Address matching is a good example of the difference. Type an address and the system resolves it to a UPRN — in our experience around 90% match automatically — so you're requesting against a precise property, not a free-typed line that might be wrong. On a spreadsheet, that's a manual copy-paste and a hope.
The same structure is what holds turnaround steady. Most searches we handle come back inside 24 to 72 hours, and the difference between firms isn't the council wait — it's whether the time inside the firm is managed or left to memory.
Here's the side-by-side.
| Spreadsheet + shared inbox | A connected system | |
|---|---|---|
| Order status | Lives in someone's head and the inbox | One live status per order, everyone sees it |
| Council knowledge | In one person's memory | Held in the system, every council pre-configured |
| Chasing | When someone remembers to | Automatic, on a schedule, by council |
| Invoicing | Rebuilt by hand from the order row | Generated from the order, order-to-invoice in one flow |
| Audit trail | Overwritten as the row gets edited | Full history behind every action |
| Key-person risk | High — the firm runs on one memory | Low — the process runs whether they're in or not |
None of this means a spreadsheet was a mistake. It got you here. It's just not the thing that takes you to the next level, and the cost of staying on it goes up with every order you add. For more on where the hidden time actually goes, see where firms lose time.
When should you actually make the switch?
When the cracks start costing you. The practical trigger is the point where one person can no longer track every live order in their head — usually somewhere past the second hire, when chasing starts slipping and version conflicts stop being rare. If you're firefighting instead of processing, you're already past it.
You don't need to be a big firm for this to bite. You need to be a busy one. Plenty of two- and three-person operations hit the wall faster than larger firms that switched early, simply because they're carrying more in their heads.
The full shape of the back office — order intake through to invoice — is worth understanding before you move. We cover it in the order-to-invoice workflow, and you can see how Valio works if you want the system version.
How Valio works → · The order-to-invoice workflow → · Where firms lose time →