The Day After the Expert Leaves: Designing Continuity Into UK Business Software

Every organisation has one. The person who knows which invoice needs a manual nudge, which customer record must never be merged, and why the approval screen sometimes needs two attempts before it behaves. They are not necessarily senior, and their knowledge is rarely written down. They simply know how the software really works. The risk is not that they will leave. The risk is that the business has designed its processes around their continued presence.

For UK SMEs, this is a practical product problem rather than an HR one. Software should be built so that ordinary turnover does not become an operational incident. That means treating continuity as a requirement from the outset, not as a document produced during a leaver’s final week.

Turnover is a normal input, not an exception

Many systems are quietly shaped around individuals. A named user is the only person able to release a payment. A particular administrator is the sole owner of a queue. A finance manager knows that a failed direct debit must be re-keyed rather than retried. None of these arrangements looks like a design decision, because they accumulated through habit.

The first step is to accept that people will change roles, take extended leave, retire or hand in their notice. A well-designed product should make those events unremarkable. It should not require a frantic search through email history to discover who can approve a refund or why a customer was placed on a hold list eighteen months ago.

Continuity is therefore a product quality, in the same way as performance or accessibility. It deserves acceptance criteria, testing and a place in the release conversation.

Permissions should describe the work, not the worker

Role-based access control is often treated as a security checkbox. In practice, it is also a continuity mechanism. When permissions are attached to roles rather than named individuals, the departure of one person becomes a straightforward administrative change rather than a redesign of the approval chain.

This requires discipline. Roles should reflect real responsibilities: finance approver, customer service supervisor, warehouse coordinator, compliance reviewer. Each role should carry the minimum access needed to perform the work, with a clear process for granting temporary additional access when circumstances demand it. A break-glass route is acceptable, provided it is logged and reviewed rather than left permanently open.

The test is simple. If the only person who can complete a critical task is on annual leave, the permission model is too person-shaped. A colleague with the same responsibilities should be able to step in without asking for a developer, a shared password or an informal favour.

Person-based permissions also create hidden dependencies. They encourage shared logins, which undermine audit trails, and they make joiners and leavers slower to process. Role-based permissions do not eliminate expertise, but they stop expertise from becoming the only route through the system.

Queues need owners, not bystanders

Operational software is full of queues: invoices awaiting approval, orders held for fraud checks, support tickets escalated to a specialist, exceptions that failed validation. These queues are where continuity problems become visible. If a queue has no named owner, it will be monitored by whoever notices it. If it has an owner who is a person rather than a role, it will stall when that person is unavailable.

Each queue should display a clear owner at role level, an escalation path and an expectation about how quickly items should be reviewed. Exceptions should not disappear into a generic inbox. They should have a status, a reason and a next action. Where a decision has been deferred, the system should record who deferred it, on what basis and when it should be revisited.

Visibility matters as much as structure. A dashboard that shows only completed work is a comfort, not a control. Teams need to see ageing items, unassigned exceptions and approvals waiting beyond their expected window. That visibility allows a manager to redistribute work before a backlog becomes a customer problem.

Audit trails should explain, not merely record

Most systems can say that a user changed a record at 14:32. Far fewer can say why. For continuity, the why is often more valuable than the what. A future colleague needs to understand that a credit limit was raised because a long-standing customer had a temporary cash-flow issue, or that an order was released early because a delivery deadline was at risk.

Decision-rich audit trails capture the context around consequential actions: the reason selected, the supporting note, the approval reference and the role of the person involved. This does not mean recording every keystroke. It means designing the small number of decision points that matter and making the rationale part of the workflow rather than an afterthought in an email.

Such records support good customer service, regulatory assurance and internal review. They also reduce the likelihood that a new starter will reverse a decision simply because its original purpose is invisible. An audit trail that explains past decisions is a form of institutional memory, and it is considerably more reliable than the recollections of whoever happens to still be in the building.

Run the empty chair exercise before launch

Before a significant release, teams can test continuity directly. The exercise is deliberately simple. Identify a critical business process, then imagine that the person who knows it best is absent for a fortnight with no access to email. Ask the remaining team to complete the process using only the software and its written guidance.

A useful version has five steps:

1. List the processes that would stop or slow down if one named person were unavailable.
2. For each process, map the roles, approvals and queues involved.
3. Ask a colleague who does not normally perform the task to complete it in a test environment.
4. Review what they could not find, understand or authorise without asking for help.
5. Convert each gap into a product change, a permission adjustment or a short piece of documentation.

The exercise often surfaces small but consequential issues: an approval button visible only to one user, an exception report with no explanation, a status label that means something different to each team. These are inexpensive to fix before launch and expensive to discover during a busy trading period.

Build for the handover you will need

Continuity is not about making individuals replaceable. It is about making the organisation resilient enough to keep serving customers while people grow, move on and take well-earned leave. UK SMEs do not need elaborate enterprise tooling to achieve this. They need role-based permissions, visible ownership, decision-rich records and a habit of testing the system against absence rather than only against presence.

The empty chair is not a hypothetical. It is a future colleague, a temporary gap or a busy Friday afternoon. Software that survives that chair is software that has been designed for the business as it actually operates.