When One Person Is the System
Somewhere in your business there is a file that everything depends on, and one member of staff who is the only person who truly understands it. That is not a spreadsheet problem. It is a continuity problem that happens to be shaped like a spreadsheet.
Nobody Decided to Run the Company This Way
Key-person dependency is never a decision. It accumulates, one sensible small step at a time, until it is load-bearing.
Somebody solves a problem on a Friday afternoon
A scheduling clash, a pricing calculation, a way of tracking which jobs have been invoiced. One tab, one afternoon, no ceremony. It is a genuinely good piece of work and it saves the team real time.
It works, so it grows
Another tab for the exceptions. A lookup against a second file. A macro that reformats the export from the accounts package. Each addition is reasonable. None of them is documented, because none of them felt like a system at the time.
Other people start relying on its output
Operations plan the week from it. Finance invoices from it. The monthly figures for the directors are built on it. It has quietly become the source of truth without ever being appointed as one.
Only one person can change it safely
Everyone else can read it. Nobody else can alter a formula without risking a number that nine people will act on. Requests queue up behind one desk and small changes wait a fortnight.
That person takes two weeks in Crete
Or is off sick, or hands in their notice, or is promoted into a job that leaves no time for this. Whichever it is, the business finds out exactly how much of it lived in one head, at the least convenient moment available.
What It Is Costing Before Anything Goes Wrong
The failure everybody pictures is dramatic and rare. The steady cost is neither, and it is larger.
Operational and commercial exposure
- A single point of failure holding a salary, a holiday entitlement and a notice period
- Changes queued behind one person, so the business moves at the speed of their diary
- No history, so when a number is wrong nobody can say when it changed or who changed it
- Due diligence for an investment round or a sale will find it, and will price it
- Business interruption cover and professional indemnity conversations become harder to have honestly
- Growth is capped: the process that works for forty jobs a week falls over at a hundred and fifty
Data protection exposure
- Personal data in a file with no access log and no way to restrict one column to one team
- Copies in inboxes, on laptops and in a downloads folder, all of them technically current
- Nothing is ever deleted, because no retention rule can be enforced on a spreadsheet
- A subject access request turns into a manual search through email attachments
- An erasure request that you cannot honestly confirm you have completed
- No record of processing to show anyone, which the ICO expects an organisation to hold
Which Processes Repay the Investment
Not everything manual should be automated. These are the signals that mean it is worth doing, and the more of them apply, the clearer the case.
The same shape, over and over
Daily or weekly, with the same steps in the same order. Rare, irregular work rarely repays the build cost no matter how tedious it feels.
A mistake is expensive to unpick
A wrong price on a quotation, a missed compliance date, a double-booked engineer. Validation at the point of entry costs far less than the apology.
The same data is typed in twice
Once into the quoting sheet, again into the accounts package, occasionally a third time into a job board. Every retype is a chance to disagree with yourself.
Somebody has to prove it happened
An auditor, a regulator, a funder or a client asking who approved what and when. An audit trail is nearly free inside a system and impossible outside one.
The waiting is the real cost
An approval that sits in an inbox for three days while a customer waits. Moving the step into a system with a queue and a reminder usually changes the business more than the automation does.
Volume is about to double
A new contract, a second site, an acquisition. Build before the surge rather than during it, when nobody has the time to be interviewed about how they work.
The Written Procedure Is Not What Happens
Every organisation has a documented process and a real one, and the gap between them is where the software gets built badly. The documented version says a job is approved by the operations manager. The real version says that on a Thursday, when she is on site, the office administrator approves anything under a thousand pounds because otherwise nothing would ship. That exception is not an inefficiency to be designed out. It is how the business actually functions, and a system that ignores it will be worked around within a fortnight.
So we sit with the people doing the work and watch them do it. Not a workshop with a facilitator and sticky notes, but an hour each with the three or four people who touch the process, asking what they do when it goes wrong, which customer is the exception, and what they keep in a separate note because the system will not let them record it.
The person who owns the spreadsheet is first on that list, and they are in the room as the expert rather than the subject. What comes out is a written process with every rule and exception attributed to a named person who has agreed it. Several clients have said that document was worth more in year one than the software.
How we run a buildThe Four Parts That Turn a Tool Into a System
A form that saves records is not an internal system. These are the pieces that make it safe to rely on.
Roles, permissions and approvals
- Who can see a figure, who can change it, and who has to approve the change before it counts
- Field-level control, so a supervisor can see a rate card whilst an operative cannot
- Delegation for holidays, because a process that stops when one person is away has recreated the original problem
- An immutable log of who did what, when, and what the value was before
- Access reviewed when somebody changes role, not only when they leave
Integration with what you already run
- Accounting and payroll, so invoices and timesheets stop being retyped between systems
- Email and calendars, so reminders and bookings appear where people already look
- Companies House lookups for onboarding a new trade account without typing an address
- Payments through Stripe or Direct Debit collection through GoCardless where money moves
- Older on-premise software with no interface, handled by scheduled exchange rather than pretending
Migrating what is already there
- Years of history with inconsistent spellings, blank fields and three different date formats
- Rules agreed in advance for the rows that cannot be cleaned automatically, decided by you rather than by us
- A rehearsal run against a copy, reconciled line by line, before anything touches the live system
- The old file kept read-only for a fixed period, then formally retired rather than quietly abandoned
- Retention applied at the point of migration, so you are not importing a compliance problem
Reporting people will actually trust
- Definitions agreed in writing, so a completed job means the same thing in two departments
- The monthly figures produced by the system rather than assembled by hand from it
- Exports that match the format your accountant and auditor already expect
- An honest boundary: where reporting becomes the main job, it belongs in a proper dashboard
If reporting is the whole point, start with data and analytics dashboards instead, and read about the services and integrations that sit underneath either one.
Good Software That Nobody Uses Is a Write-Off
In our experience this is where internal projects fail, and it is almost never the code. People are being asked to give up a way of working they are fluent in, for one they are slow at, in the middle of a normal week.
Start with the team that wants it
One depot, one office, one service line. Volunteers first, and tell them plainly that they are first because their feedback will change what everyone else gets.
Run both ways for a fixed fortnight
Short and dated. Open-ended parallel running means the spreadsheet wins, because it is the one people already know how to use under pressure.
Train on live work, in small groups
Forty-five minutes with their own jobs on the screen, four or five people at a time, run by the colleague who owned the old process rather than by us.
Fix week-one complaints immediately
The first fortnight sets whether people believe the system is theirs. A small annoyance fixed within a day buys more goodwill than a feature delivered in a month.
Then retire the old file properly: read-only, dated, announced. A spreadsheet left editable will still be in use next year, and you will have paid for two systems.
Build It, Buy It, or Leave It for Now
Three legitimate answers. We give the one we believe rather than the one that bills.
Build
- The process is genuinely part of how you compete rather than ordinary back-office work
- Off-the-shelf only fits after enough configuration that you are paying for software and a permanent consultant
- You need it to sit between three systems that will never talk to each other on their own
- The rules are stable enough to write down and have somebody sign
- Somebody internal is willing to own it after launch, by name
Buy
- It is a solved and ordinary problem: payroll, accounts, helpdesk, holiday booking, expenses
- You need it working next month and a subscription starts on Monday
- A regulator effectively expects a recognised product and you would spend the build budget on assurance
- The total licence cost over three years is comfortably below a build, once support is counted
- We will name products we know of, and we do not take referral fees for doing it
Wait
- The process is still changing every fortnight, so anything built now is scrap by spring
- A restructure, an acquisition or a system replacement is already scheduled this year
- Nobody internally will own it, and an unowned internal system decays faster than the spreadsheet did
- The real problem is that two departments disagree about the process, which software cannot settle
- Six weeks of tidying the current file would remove most of the pain for almost nothing
What Operations Directors Ask Us
The person who built our spreadsheet is nervous about this. How do we handle it?
Carefully, because they are usually the most valuable person in the project and the easiest one to lose. They are not protecting a file, they are protecting the only part of their job that nobody else can do. The approach that works is to give them the role of expert rather than subject: they define the rules, they sign off the logic, their name is on the decisions, and they become the person who trains everyone else. The approach that fails is presenting the new system to them at a demo three weeks before launch. We ask for them in the first session and we keep them in every session after that.
Our staff and client data sits in a spreadsheet on a shared drive. Is that a UK GDPR problem?
It is at least a difficult one to defend. A spreadsheet of personal data typically has no record of who opened it, no way to restrict one column to one team, copies in several inboxes, and no retention rule, so nothing is ever deleted. When a subject access request arrives you are searching email attachments by hand, and when somebody asks for erasure you cannot be confident you found every copy. A proper system fixes this almost as a side effect: access is per role, every change is attributed and timestamped, retention can be enforced, and a subject access request becomes a search rather than an archaeology project. Your data protection lead judges the risk; we build so the answer is straightforward either way.
Who owns the system once it is built, and what happens if you disappear?
You own it. The repository, the hosting account and the domain are in your company name from the first week rather than ours, and intellectual property transfers to you on final payment. The handover pack includes the architecture notes, the deployment procedure and the credentials, and we write it as we go rather than in a panic at the end. The honest test of a supplier is whether another firm could pick the system up without ringing us, and we build assuming that will eventually happen, because over a long enough period it usually does.
What if the person who understands the process leaves halfway through the build?
This is precisely why the mapping stage produces a written document rather than a shared understanding. Every rule, exception and approval we uncover is recorded, attributed and signed off by name before it is built, so the knowledge stops living exclusively in one head from about week two. If that person then hands in their notice, you have lost a colleague rather than the project. It is also one of the more useful by-products of the work, and several clients have told us the written process turned out to be worth more than the software in the first year.
Can it work with Xero, Sage and the other systems we already pay for?
Usually, and where we cannot we say so before you commit. Accounting packages, payroll, CRM, email and calendars generally offer a documented interface, so invoices, contacts and jobs can flow both ways without anyone retyping them. Older on-premise software sometimes offers nothing at all, in which case the options are a scheduled file exchange, a database-level integration where the supplier permits it, or accepting one manual step and designing it to take seconds. We check the integration surface of every system on your list during scoping, because finding out in month three is how fixed prices come apart.
Send Us the Spreadsheet
Genuinely. Attach it, tell us who maintains it and what breaks when they are away, and you get back a scope, a delivery window and a sterling figure excluding VAT within two working days.