When the Real Workflow Lives Outside the System

Open the shared drive in almost any operational service and you will find part of the real workflow.

There may be a spreadsheet of cases awaiting review, an Outlook folder for reports that need consent, or a document that explains which inbox should receive each type of request. Staff may copy information from one record into another because the two parts of the system cannot share it.

These are often called workarounds. The word suggests temporary inconvenience or user error.

That misses what they tell us.

A manual workaround is usually a small piece of software design carried out by the people doing the work. It introduces a state, a queue, an owner or a connection that the main system does not provide.

The workaround is not necessarily bad. It is product feedback.

People complete the model for themselves

Software does not need to contain every task someone performs. People will always use notes, email and spreadsheets for thinking, analysis and one-off coordination.

The more interesting workarounds are repeated and shared. They have agreed column headings, folder names, colour codes or rules about who updates them. New starters are taught how to use them. If they are unavailable, work slows down.

At that point, the team has not found a convenient personal tool. It has built a missing part of the operating model.

Consider an Outlook folder called “Waiting for employee consent”. Moving an email into that folder changes how the team treats the case. It is no longer ready for release. Someone needs to monitor it and take action when consent arrives.

The folder is acting as a workflow state.

The occupational health system may still show the report as complete. Operationally, it is not complete at all.

This distinction matters because the official record and the working record have diverged. Management reporting reads one version. The team works from another.

Different workarounds reveal different gaps

The tool a team chooses often gives a clue about what is missing.

A spreadsheet commonly appears when people need to see many cases together. The case system may be adequate for opening one record, but weak at answering questions across a queue: what is waiting, how long has it been waiting, which client does it relate to and who needs to act?

The spreadsheet adds a view of the service that the system does not have.

A shared inbox often becomes an unofficial work queue. Messages arrive, somebody decides what they mean, and unread flags or categories indicate whether work has been claimed. Forwarding becomes routing. Initials in a subject line become ownership.

The inbox is carrying workflow, not just communication.

Copying and pasting is a manual integration. It usually means information exists, but not where it is needed. A manager’s referral question is copied into an assessment. Appointment details are copied into an email. A report outcome is retyped into a client portal.

The immediate cost is time. The more serious cost is divergence. Once information has been copied, correcting the source does not correct the copy.

Duplicated records can reveal a deeper boundary problem. A team may create a second record because the first has the wrong access controls, lifecycle or purpose. What looks like poor data discipline may be an attempt to separate clinical information from employer-facing information, or an active case from a long-term surveillance record.

The duplication is risky, but deleting it without understanding why it exists may remove a distinction the service genuinely needs.

Product feedback is not a product requirement

It would be a mistake to turn every spreadsheet into a feature.

Spreadsheets are good at exploratory analysis. Email is useful for communication outside a system. A short-lived tracker may be the most proportionate response to an unusual contract or a temporary increase in demand.

Absorbing every local practice into the product would create a different problem: software shaped by exceptions rather than a clear account of the work.

The first question is not “How do we replace this tool?” It is “What job is this tool doing?”

A tracker may exist because a useful filter is missing. Or it may be compensating for case statuses that have no consistent meaning. Adding an export solves the first problem. It makes the second easier to hide.

A shared inbox may need better integration. It may instead reveal that nobody can assign a task inside the case, or that responsibility moves between teams without a recorded handover.

The visible workaround is only the surface. Product work begins by finding the missing concept underneath it.

Repetition is a useful signal

One workaround tells you that somebody found a way to complete a task. The same workaround appearing across teams tells you more.

If several administrators keep private lists of reports awaiting release, the service does not have one workaround. It has several competing versions of the same queue.

If every client implementation needs a spreadsheet to translate local statuses into provider-wide reporting categories, the gap is unlikely to be client-specific. The product has allowed labels to vary without preserving shared operational meaning.

The most valuable signals are not always the workarounds that consume the most time. A five-minute reconciliation carried out every day may expose a missing boundary that affects reporting, audit history and integration. Its small daily cost makes it easy to tolerate. Its reach makes it important.

Frequency matters. So do the number of people involved, the sensitivity of the information, the consequences of a missed update and the distance between the workaround and the official record.

Those factors help distinguish harmless local convenience from a second system that deserves attention.

Study the workaround before removing it

Teams are often told to stop using shadow systems before the main system can support the work they contain.

That creates compliance in appearance and confusion in practice. The spreadsheet disappears from the shared drive, then returns as personal notes, flagged emails or knowledge held by one experienced administrator.

A better approach is to observe the workaround closely.

Who creates an entry? What event causes it to change? Which columns are trusted, and which are rarely maintained? What decision does the team make from it? What happens when two people update it at once? When is an item considered finished?

The untidy details are useful. Colour coding may express urgency. A blank cell may mean “not yet known” rather than “not applicable”. A weekly copy of the file may be the team’s only history of change.

Replacing the tool without preserving that meaning produces a cleaner interface and a weaker process.

In the meantime, workarounds that hold operational or sensitive information still need care. The service should be clear about the source of truth, who owns reconciliation, who can access the information and when the temporary record can be removed.

Temporary does not mean unmanaged.

Build for the work that is really happening

At Occentra, we are interested in workarounds because they expose the difference between the workflow described in a process document and the workflow people can operate.

The answer is not to reproduce every spreadsheet inside the product. It is to model the recurring concepts properly: visible case states, owned tasks, controlled handovers, reusable information and a complete history of meaningful change. That is also the lens we use in our occupational health software comparisons: whether the official system can carry the work, or whether the real workflow still lives beside it.

When those foundations are present, teams can still use spreadsheets for analysis and email for communication. They no longer need them to remember what the core system has forgotten.

When a team builds a system beside your system, it has not rejected software. It has finished the part the software left undone.