How to find processes that depend on one employee

Your best operations manager just handed in their notice. Suddenly, nobody knows how the monthly supplier reconciliation works, where the export files go, or why the planning sheet has a hidden tab nobody's touched in three years. The next two weeks are damage control — and you realise that the real problem started long before the resignation letter.

This article gives you a practical method to find every process in your organisation that depends on a single person, audit the risk it carries, and take concrete steps to document, delegate, or automate it away — before the next crisis hits.

Why single-person dependencies are so hard to spot

The problem is almost never deliberate. Nobody decides to make themselves irreplaceable — it happens gradually. A capable employee steps in to solve a problem once, does it better than anyone else, and quietly becomes the person for that task. Over months and years, tribal knowledge accumulates: workarounds, manual corrections, undocumented decisions, and informal rules that only they carry in their head.

The most dangerous dependencies are invisible in your org chart and your software. They live in:

• Email threads only one person is copied on
• Spreadsheets only one person knows how to update correctly
• Passwords and logins stored in one person's personal password manager
• Verbal agreements with suppliers or clients that never made it into a contract
• Manual steps inserted into an otherwise automated flow — "Sophie always checks this before it goes out"
• Institutional memory — knowing why a rule exists, not just what it is

If your business continuity plan consists of "ask Thomas," you have a single-person dependency.

How to audit your processes for hidden dependencies

Auditing for single-person risk is not the same as drawing a process map. Most process maps show the happy path — what's supposed to happen. You need to find what actually happens, including the informal detours.

Step 1: Start with absence, not with roles

Don't start by listing job titles. Start by asking a sharper question: "If this person were unreachable for two weeks starting tomorrow, what would break?" Go through every person in your team and answer it honestly. The answers will surprise you.

Common triggers to probe:

• Who approves things nobody else can approve?
• Who is the only one with access to a specific system or account?
• Who do clients or suppliers call directly — and only them?
• Who handles a task that nobody else has been trained on?
• Who do colleagues ask when they don't know what to do?

Step 2: Map the "last resort" paths

In every organisation, there are informal escalation paths that never appear in any procedure. Someone gets stuck, they ask the one person who knows. Document these by interviewing your team — not by asking "what is your process" but by asking "what do you do when you're stuck?" and "who do you go to when the system doesn't cover a situation?"

Those answers reveal your real process owners — and your real single points of failure.

Step 3: Classify by operational impact

Not every dependency is equally dangerous. Prioritise them using a two-axis view:

Axis	Low	High
Frequency	Monthly or less	Daily or weekly
Impact if blocked	Delay tolerable	Revenue, compliance, or client relationship at risk

A daily, high-impact task owned by one person is a critical dependency. A quarterly report that only one person runs is still a dependency — but lower on your fix-it list. Start with the top-right quadrant.

Step 4: Check your software and system access

Process dependencies are not only about knowledge — they are also about access. Run an access audit alongside your process audit:

• Who has admin credentials to your ERP, CRM, or custom databases?
• Who is the only named contact for a SaaS subscription?
• Who runs the scheduled exports, backups, or API connections?
• Who holds the master login for a tool the company pays for but nobody else can enter?

In FileMaker environments specifically, it is common to find that one in-house developer or power user is the only person who knows the data schema, can modify layouts, or can reset accounts — making them a technical single point of failure on top of any process dependency.

Step 5: Run a "bus factor" exercise

The "bus factor" is a blunt but useful thought experiment from software engineering: how many people would need to be hit by a bus before a project grinds to a halt? Apply it to your business processes. A bus factor of one means you have a critical dependency. The goal is not to be morbid — it's to make the risk visible enough that leadership will act on it.

Run this as a short workshop with department heads. Ask them to name every process in their area with a bus factor of one. Write them on a board. The length of that list is usually enough to motivate change.

How to document what only one person knows

Once you've identified the dependencies, the next challenge is getting the knowledge out of one person's head and into a form the organisation can actually use. This is harder than it sounds — not because people are unwilling, but because experts genuinely forget what they know.

Don't ask them to write a manual — shadow them instead

Asking a person to document their process usually produces one of two results: an outline so high-level it's useless, or a detailed essay nobody reads. A better approach is process shadowing: sit with the person while they do the task, and you (or a colleague) write down every step, decision, and exception in real time. You will catch things they would never think to include — precisely because those things are so automatic to them.

Key questions to ask during shadowing:

• "Why did you do it that way and not another way?"
• "What would go wrong if you skipped this step?"
• "Has this ever broken? What did you do?"
• "Is there anything here that depends on something outside this process?"

Document decisions, not just actions

Most process documentation captures what someone does. The real value is in capturing why they make the decisions they make. A step that says "check the margin before approving" is almost useless without: what threshold triggers a rejection, what exceptions exist, who to escalate to, and what the last three exceptions looked like.

Decision documentation is what separates a procedure someone can follow from institutional memory that can only live in one person's head.

Make it findable, not just filed

Documentation that lives in a shared folder nobody opens is as useless as no documentation at all. Embed process documentation where the work actually happens: inside your ERP, your project management tool, your custom FileMaker solution, or your intranet — whichever surface your team already uses daily. A process note attached to the relevant screen in your business application is worth ten Word documents in a SharePoint folder.

How to delegate and distribute critical knowledge

Documentation is a starting point, not a finish line. The goal is that at least one other person can actually perform the task under pressure — not just read about it.

Build a redundancy-first training plan

For every critical process, identify a backup owner: a second person who is trained, practiced, and confident enough to run it independently. This does not mean the original owner hands over responsibility — it means you build a genuine redundancy layer.

A practical structure:

1. Primary owner — runs the process day-to-day
2. Backup owner — runs it at least once per quarter to stay current
3. Documentation owner — keeps the written process accurate and up to date

These can overlap, but all three roles must be named explicitly. If you cannot fill all three for a given process, that process is still a dependency risk.

Use cross-training, not just documentation handoffs

Documentation handoffs — where you hand someone a procedure and call them trained — rarely produce real redundancy. Effective cross-training means the backup owner actually performs the process, makes the decisions, and encounters the edge cases, while the primary owner is still available to answer questions. Build this into your normal schedule before you need it.

How to reduce dependency risk through standardisation and automation

Documentation and cross-training reduce the human risk. Standardisation and automation reduce the process risk itself — by making it impossible for the task to depend on a single person's knowledge or access.

Standardise the decision rules

If a process requires expert judgment, the first question is: can that judgment be codified? Not everything can — but more than you think. Rules like "orders above €10,000 need a second approval" or "suppliers in category B always get net-60 terms" can be written down, tested, and eventually enforced by your software rather than held in someone's memory.

Every rule you codify is a dependency you eliminate.

Automate the repetitive handoffs

Many single-person dependencies exist because a task involves moving data between systems — and only one person knows how to do it correctly. An order gets entered into FileMaker, and then re-typed by hand into Exact Online — every single order, every single day — because Sophie learned the mapping years ago and nobody else did. An API integration between those two systems eliminates Sophie's role in that data transfer entirely, and removes the dependency with it.

Look specifically for:

• Manual data re-entry between two systems
• Scheduled exports or imports run from someone's personal machine
• Approval steps done via email because the system doesn't support them
• Reports generated by one person using a spreadsheet only they understand

Each of these is a candidate for automation — and each automation removes a human single point of failure.

Build access control that survives staff changes

System access should be role-based, not person-based. If your ERP gives admin access to "Jan Bos" rather than to the "Finance Manager" role, your access structure will break every time someone leaves. Review your user management and ensure:

• Shared accounts are replaced with individual role-based accounts
• Admin credentials are stored in a company password manager, not a personal one
• System ownership is documented at the role level, not the person level
• Offboarding checklists include access revocation for every system

---

Checklist: Is your process a single-person dependency risk?

Use this checklist for each critical process in your organisation:

• Can at least one other person perform this task without help?
• Is the process documented with decisions, not just steps?
• Is the documentation stored where the work actually happens?
• Is system access to this process role-based, not person-based?
• Has the backup owner performed this task in the last 90 days?
• If the primary owner left tomorrow, could this task run next week?
• Are any manual data transfers in this process candidates for automation?
• Are exception-handling decisions written down and agreed upon?

If you answered "no" to two or more of these, treat the process as a critical dependency risk.

---

FAQ

How do I get employees to share knowledge they might feel protective of? Frame the conversation around business resilience, not replacement. Most employees are not gatekeeping knowledge — they simply haven't been asked to share it in a structured way. Involve them in designing the documentation process rather than imposing it, and position the backup owner as a collaborator, not a successor.

Where should I start if I have dozens of potential dependencies? Start with the process that would cause the most immediate operational or financial damage if the responsible person were unavailable tomorrow. Use the frequency-versus-impact matrix above to prioritise. Fix the top three before you try to fix everything.

Can automation really eliminate a human dependency, or does it just move it? Automation eliminates a dependency on a specific person knowing how to do a manual task. It does create a new dependency: someone needs to understand the automated system. The difference is that a well-built automated process is transparent, auditable, and maintainable by any trained person — unlike tribal knowledge, which is invisible and non-transferable.

How often should we re-audit for single-person dependencies? At minimum, after any significant staff change (hire, departure, role change) and once a year as a standing review. Dependencies tend to re-form quietly — a new employee becomes the go-to person for a new tool, and within a year you have a new single point of failure.

What if the employee is also the founder or a director? Founder-dependency is one of the most common and most under-addressed risks in SMEs. The same principles apply: map what only they do, document their decision rules, and build at least one trusted person who can cover each critical area. For founders, the goal is not replacement — it is sustainable growth without a single point of organisational failure.

---

If your audit uncovers processes that are genuinely hard to document, delegate, or standardise — because they rely on undocumented data logic, manual system workarounds, or years of accumulated custom configuration — that's often a sign the underlying systems need attention, not just the people. Loggix helps organisations map business processes, untangle knowledge that's buried in custom software, and build the integrations and automations that turn personal know-how into reliable, auditable workflows. Whether that means extending a FileMaker environment, connecting systems through an API, or rethinking a process from the ground up, the starting point is always the same: making the invisible visible.