Series

The software strategy of small and medium-sized firms tends to fail slowly. It creeps up. A change to a formula in a Google Sheet. A day later, an automation pushes the information into a database. A key person will be on leave by Friday. The work seems to be moving. So no one calls it a risk. It looks like a slow week. Like a messy handover. Like someone dropped the ball. The Google Sheet opens, Zapier reports success, and the email flows. But something important stops moving between systems, and no one noticed.

Where it all goes wrong. What exactly went wrong?

In small teams, operational risk is the chance that routine work might fail due to a process, person, or technology. In the larger world, operational risk is bad people doing bad things. In small firms, it is more often a missed approval, an overwritten cell, an expired connection, or unwritten knowledge. Larger businesses employ dedicated teams of professionals to manage their operational risk. But the basic discipline – identify, assess, mitigate, monitor – still matters.. We are talking about the same cycle. In fact, we’re radically simplifying it.

Here’s our model:

$$Operational risk = undocumented change × concentration of knowledge × silent failure$$

Undocumented change. Concentration of knowledge. Silent failure. All three factors in this equation make each other worse.

How ordinary work hides risk

There is likely to be a monthly invoicing process. The invoice template might be a Google Sheet. The signed work orders and client information might be in a folder. One person knows the exceptions in that folder. There might be a lead handover process, getting information from Typeform into Sheets, and between Sheets & Slack. It involves sending documents by email and doing manual checks against the spreadsheet. And so on. It looks like a normal business. It doesn’t look like an operational risk register.

Trouble starts when normal work is treated as self-explanatory. When it depends on unrecorded assumptions, be it working logins and passwords, manual corrections in the spreadsheet, or it doesn’t quite wrap up correctly where it started. Growth might amplify it a little. There might be an addition of a service line. There might be a joiner who doesn’t quite get the handover. There might be a new approval step in the workflow. There might be a forgotten rule that needs to be applied to the spreadsheet. There might be a renaming of a column. Or the renaming of something important. Each of these decisions makes perfect sense in itself.

All of them, together, create a gap between the perception of a single, harmonious process, and the actual oddball activities in play right now. It’s that gap where internal processes start to fail.

The following three conditions make routine work dangerous.

1. The first multiplier is an undocumented change. Operational risk happens when something changes without anyone documenting why & what it changes, what it depends on, or how the result will be checked. Maybe someone renames a column in a spreadsheet. Maybe someone adds a new step for approval. Maybe someone edits the flow in an n8n or Zapier workflow.
2. The second multiplier is the concentration of knowledge. It might be the case that only one person understands why the process exists in the first place. They might be the only person to know where the source data sits. They might be the only person to know how to deal with bad output. Or they might be the only person in the organisation to hold any admin credentials. Even if there’s a backup all the team has is a checklist with vague instructions. They don’t have the context.
3. The third multiplier is silent failure. Sometimes you run an operation and it doesn’t work, and you immediately know something has gone wrong. Sometimes you run an operation, and it looks plausible, but it’s still wrong in some way. If you compute something in a column and the range doesn’t include all the data, you end up excluding things. It might make the output look plausible, but it’s definitely wrong. And once it’s passed downstream, fixing it takes longer, and it costs more.

In that sense, it’s like a fuse tripping. It would be inconvenient but at least visible. If the fuse goes bad behind the wall, however, the damage would spread unnoticed until it is too late to do anything about it. In that sense, visibility is a control. With visibility problems get resolved before they metastasise.

The single point of failure

Let’s assume that a boutique marketing agency has 10 people. They use a Google Sheet as their lead tracker, hand it over to Zapier, and everything progresses from there. One ops lead is responsible for this particular part of operations and has full admin rights to the Zapier automation. The lead tracker has grown over the space of two years and now contains multiple tabs. A new service tab has been added, and someone has edited the tracker and renamed the “Status” column to “Pipeline stage”, presumably to avoid confusion with another project-tracking spreadsheet elsewhere in the agency. While the Zapier trigger is still running, one of the steps expects the value of a field called “Status”, and Zapier still names the column that way internally. When the value is sent further down the chain, the destination treats it as an optional field and simply leaves it blank for scope.

That’s the undocumented change. The ops lead is aware of the lead tracker and considers it the version of the truth. They own the Zapier workflow, and they have what they call a Friday check: every Friday afternoon, they run through the chain to make sure everything looks good. That’s the concentration of knowledge. A few days later, the delivery team receives a collection of records that seem to look perfectly legitimate. The client’s name and the start date are there. It seems as though the person who filled in the lead tracker skipped a step and either didn’t feel like entering the scope or missed it. Either way, the answer seems to be, “they probably just rushed it.” So the delivery team asks in Slack for clarification, and the agency continues with business as usual. That’s the silent failure. When the ops lead is away for a week, things start to be noticed. The delivery team is chasing pieces of a brief that are missing key information, forecasting is wrong, and the ratio of new opportunities to closed deals deteriorates.

A visible symptom is appearing: too much rework. Real failure lies in the chain of undocumented changes, concentrated knowledge, and silent failures that produced it in the first place. It doesn’t matter if the read-only ops lead blames the wrong tool. Moving away from Sheets to Airtable or from Zapier to n8n will not change this. It still doesn’t document processes, spread knowledge of any value, or systematically check output. A proper database might even preserve the process that already contains the bug more reliably.

So, next time something slips through, spend some time answering these questions:

• What has changed in that part of the process since it last worked well?
• Who can tell me why we’re doing it that way without opening up the tool?
• What would prove that the result is correct?
• What would happen if the owner of that part of the workflow was away for two weeks?
• Where would the first incorrect output appear in the chain?

If you find that the answer to all these is, “just my knowledge, nobody else’s”, you’re looking at a single point of failure. A single point of failure doesn’t have to be a particular tool; it can be a person, their browser profile, an unshared email inbox, or a Friday-afternoon habit. And the most dangerous of them is the one nobody notices.

Interrupting a single point of failure doesn’t just mean replacing a tool; it might mean interrupting the entire chain leading up to it.

Do not try to document everything.

Start with the processes that affect moving money, client commitments, legal obligations, or daily delivery. Invoicing will almost always matter more than office supplies; a lead-to-project handoff will matter more than color-coding lead records for org charts.

For each such process: Keep a small change log so you can interrupt the change-making chain. It should say what changed, why you changed it, who did it, and what you tested. Add links to the relevant sheet tab, workflow, or script it affected. Don’t worry about filling it in exhaustively – the goal is helpful context for recovering from change, not exhaustive documentation.

Someone reading the record of a critical workflow should be able to tell you what the purpose is, what the inputs and outputs are, who owns it, who is the backup, what the symptoms of failure are, what steps do they need to take to recover it, and where to find the source of truth. And never save credentials in a browser profile or a save list; use a shared password manager instead.

Make the output checkable. Be able to tell if that workflow has produced correct outputs. Compare lead counts to delivery records, approved work to draft invoices, and a sample of AI output to its source. How often you review can vary depending on risk, volume, rate of change, and consequences. Daily client commitments may need daily or weekly checks. A missed internal notification may be acceptable depending on risk appetite, but a missed client deadline might not be. Payments to the wrong bank account definitely need an approval control before the money leaves.

To start, pick an audit of your processes and test your ability to recover – not to audit your documentation quality.

First, make a list of the ten processes that would interrupt your work if they should stop. Note who owns it, the backup, the source of truth, when it was last changed, and how you’d spot failure (e.g., seeing that the client has no project assignments, or that the vendor hasn’t filed a second tax form this quarter). Pick the most risky one, have the backup run it, and ask them how they would spot bad output and recover from it. Write down the first missing instruction they give you, or the first symptom of invisible failure they point out. Start with the workflow that sends money, commitments, or client work downstream, and compare its last successful output with the source record it was meant to represent.

If this post described your operation a little too accurately, Let’s talk about how to solve it, get in touch.