14 min read
Email is one of the most useful tools in any organization. It is fast, familiar, flexible, and widely used, which is why it often becomes the default place where work is discussed. The problem starts when email stops being a communication channel and becomes the workflow itself.
A task is assigned in an email. A document is attached to a reply. A clarification is buried halfway down a thread. A decision is approved by someone writing “looks good to me.” A delay is explained in a side conversation. A handover depends on someone forwarding the right message to the right person.
A workflow hidden in email is not a controlled process. It is a trail of conversations. The more critical the process, the greater the risk of managing it through messages, replies, and inboxes instead of a system designed to execute and track work.
This is especially true in complex asset organizations, where maintenance, assembly, deployment, sustainment, and asset data flow depend on many people working across many systems. In these environments, email does not just create administrative inconvenience. It can weaken accountability, delay decisions, hide operational risk, and make it harder to understand what is actually happening.
Why email takes over operational work
Email takes over because it works well enough at first. Everyone already has access to it, and everyone knows how to use it. When a task falls between systems, email becomes the fastest way to keep things moving.
That is why email often fills the space between formal enterprise systems and real operational work. An ERP, PLM, CMMS, MES, or logistics system may hold official records. But the actual movement of work often happens somewhere else, across teams, departments, and external partners as they coordinate day-to-day activities and decisions.
This is also why email often appears alongside spreadsheets, SharePoint folders, screenshots, PDFs, and local databases. These tools become the informal layer that helps teams get through the day when the official systems are too rigid, too fragmented, or too far removed from the work itself.
This connects closely to the broader operational challenge described in The Reality of Operational Workflows in Complex Asset Organizations. Many organizations do not lack systems. They lack a structured execution layer that reflects how work actually moves across people, assets, tasks, and decisions.
Email feels safe because it is familiar
One reason email persists is psychological. It feels controlled. A person can see the message they sent. They can search their inbox. They can forward the thread. They can keep a local copy of a document. They can add more people if needed. Compared with a new system, email can feel safer because it is already part of the organization’s daily rhythm.
But familiarity is not the same as control.
As Raluca from Empact explains, having helped some of the biggest original equipment manufacturers (OEMs) in defence reduce their reliance on emails and spreadsheets:
“Email, Excel, and SharePoint often give teams a false sense of safety because they feel familiar and controllable. But the work is still easy to misroute, duplicate, corrupt, or lose in fragmented conversations.”
That false sense of safety matters. In many defense and complex asset environments, reluctance to adopt new systems is often linked to security concerns. Teams worry that new platforms might introduce risk. But email and spreadsheets can create their own exposure. Information can be forwarded too broadly. Files can be edited incorrectly. Context can be separated from the work. Sensitive operational details can spread through informal channels.
The risk is not only that something gets lost. It is that the organization believes the process is under control because the conversation exists somewhere.
Email avoids the harder process questions
Email also allows organizations to avoid more difficult questions about how work should be structured. Who owns the task? What is the current status? Which version is valid? What evidence is required? What happens when someone is unavailable? Where is the audit trail? Who is accountable if the task is delayed, duplicated, or misunderstood?
Email can carry all these conversations, but it cannot reliably govern them. That is why email-driven processes often survive for years. They allow work to continue without forcing the organization to define ownership, dependencies, permissions, evidence, status, and escalation rules clearly.
In the short term, that flexibility is useful. In the long term, it becomes operational debt.
The hidden risks of email-based workflows
The biggest risks of email-driven processes are rarely obvious at the beginning. They appear slowly, as the organization scales, the asset base grows, more people become involved, and the work becomes more dependent on accurate handovers and reliable records. Email does not usually fail all at once. It creates small gaps that compound.
1. Accountability becomes personal instead of operational
Email assigns responsibility informally. A person may be copied on a thread. Someone may be asked to “take a look.” A manager may reply with approval. But none of that creates the same structure as a workflow where ownership, status, due dates, dependencies, and required evidence are clearly defined.
In an email-driven process, accountability depends on people remembering what was agreed, finding the right thread, and interpreting the latest message correctly. That creates a personal form of accountability rather than an operational one. The process depends on individual discipline, inbox habits, and memory.
In maintenance and sustainment, this can show up in very practical ways. A maintenance action is requested in one thread and updated in another. A spare part question is buried in a long reply chain. A handover depends on someone forwarding the right message. A task is considered complete because someone replied, not because the required evidence was captured and validated.
This is where email creates a dangerous gap between communication and execution. People may be talking about the work. But the organization still lacks a structured view of who owns it, what has changed, what is blocked, and what is complete.
This is closely connected to the visibility problem discussed in Why Operational Visibility Is So Hard to Achieve. A dashboard cannot create reliable visibility if the work underneath it is scattered across inboxes, files, and personal follow-ups.
2. Visibility is always delayed
Email can show that communication happened. It cannot reliably show the real-time state of work. A manager may know that a message was sent, a supplier was contacted, or a team was asked for an update. But that is not the same as knowing whether the task is assigned, accepted, blocked, overdue, waiting for parts, waiting for approval, missing evidence, or already completed.
Email can create activity without creating visibility, a significant challenge in complex asset operations where decisions often depend on timing. If a maintenance task is delayed, a part is unavailable, a configuration has changed, or an inspection has not been completed, the consequence is not just administrative. It can affect readiness, planning, customer support, fleet availability, production flow, and downstream lifecycle data.
The UK MOD’s Data Strategy describes a broader version of this problem as the “data paradox”: defense organizations may have more data than ever, while still struggling to isolate useful insight from information because data is inaccessible, non-standardized, poorly governed, or trapped in silos.
Email contributes to the same pattern at the workflow level. It produces more messages, more attachments, and more updates, but not necessarily more operational insight. The question is not whether the information exists somewhere. The question is whether the right people can find it, trust it, and act on it at the moment they need it.
3. Traceability breaks across attachments, replies, and versions
Email often creates the illusion of documentation because it contains many of the elements people associate with a formal record: timestamps, named participants, attachments, approvals, and a visible history of communication. However, an email thread is not the same as a structured operational record.
As conversations continue, the thread gradually accumulates instructions, clarifications, decisions, files, screenshots, side comments, and outdated attachments, making it increasingly difficult to distinguish authoritative information from supporting discussion. Documents may be revised and resent multiple times, recipients may unknowingly respond to older versions, and locally edited copies can diverge from the original. Important approvals can also become buried within reply chains, leaving them disconnected from the final task record and harder to trace later.
This is where traceability starts to break. A process may appear documented because the emails exist, but the operational record is not structured. As conversations grow and documents are revised, it becomes increasingly difficult to prove which action was taken, by whom, based on which version of the information, and with what supporting evidence. In safety-critical environments, that lack of clarity can become a significant operational weakness.
A similar issue often emerges when spreadsheets are shared and updated through email. While a spreadsheet can help track activity, it cannot reliably govern a process when ownership, version control, permissions, and evidence are managed informally. Over time, email threads and spreadsheets tend to reinforce each other's limitations, creating workflows that are difficult to audit, validate, or reconstruct with confidence.
For more on that, read our article The Hidden Risks of Spreadsheet-Based Workflows.
4. Work becomes dependent on individual inboxes
When operational context lives in email, the organization becomes dependent on personal inboxes. This creates a significant problem because the person managing a thread often becomes the primary holder of the information needed to understand the current status of the work, including key decisions, dependencies, and historical context that may never have been captured elsewhere.
While this informal knowledge can help keep work moving in the short term, it is not organizational knowledge. It exists largely in one person's inbox and memory rather than in a shared, structured record that others can easily access and understand.
As a result, the process becomes fragile. If that person is unavailable, changes role, leaves the company, or simply misses a message, others may be forced to reconstruct the status of the work from scattered conversations, attachments, and disconnected email threads.
This is a practical version of a broader knowledge-management problem. Military Review’s article on “unknown knowns” describes how organizations can possess relevant knowledge but fail to access or use it when needed. In email-driven workflows, this happens every day. The organization may “know” the answer, but the answer is trapped in someone’s inbox. If the only person who understands the status of a task is the person managing the email thread, the process is not resilient.
5. Email makes handovers weak
Operational work rarely stays with one person or team. Work often moves across multiple functions, organizations, and stakeholders, requiring clear handovers and shared context.
Research on defense supply chains points to the importance of better information exchange, visibility into future needs, and stronger collaboration across stakeholders. That is not a soft communications issue. It affects forecasting, spare parts, production capacity, delivery readiness, and operational resilience.
Email can help people communicate across boundaries. But it does not create a shared operational workflow across those boundaries. This is where the organization starts paying a hidden coordination cost. People spend more time searching, clarifying, confirming, forwarding, checking, and re-checking. The IEA’s work on defense markets highlights that transaction costs include the cost of searching for information, negotiating agreements, and monitoring or enforcing what has been agreed. Email-driven workflows increase these costs because decisions, evidence, and responsibilities are scattered across informal exchanges.
Why this matters more in complex asset organizations
Email-driven processes are risky in many organizations. They are especially risky in complex asset environments. That is because the work is long-lived, cross-functional, security-sensitive, and operationally consequential.
The work is cross-functional
Maintenance, sustainment, and assembly workflows typically span multiple teams, functions, and external stakeholders, requiring clear coordination, ownership, and traceability. Email struggles in this environment because it organizes work around conversations rather than operational structure. While a thread can include many participants, it does not reliably define roles, responsibilities, dependencies, permissions, or completion criteria, making it harder to maintain shared context as work moves across the organization.
The assets are long-lived
Complex assets often remain in use for years or decades, which makes accurate operational records essential. A missing handover, poorly documented assembly step, manual update, or decision buried in an email thread can create problems long after the work is completed. Email-driven processes are therefore more than a short-term productivity issue. They can weaken lifecycle data, making it harder to support maintenance, readiness, traceability, reliability analysis, and long-term asset management.
The environment is security-sensitive
In defense and other critical asset environments, security concerns shape every technology decision, and rightly so. Sensitive operational, maintenance, deployment, and supplier data must be carefully controlled. However, this can create a contradiction: teams may hesitate to adopt new systems because of security concerns while continuing to rely on email, spreadsheets, and shared folders simply because they are familiar.
Familiarity is not the same as control. Information shared through email can still be forwarded, copied, downloaded, or separated from access controls, making it difficult to manage. Effective security depends on clear visibility into who has access, what actions they have taken, what they have approved, and how information moves through the process. Email was never designed to provide that level of operational control.
Email is not a workflow automation system
Email remains a valuable communication tool, but it was never designed to manage operational execution. It can help people share information and coordinate work, yet it cannot reliably provide the ownership, visibility, traceability, governance, and lifecycle connection that complex asset workflows require. The key distinction is simple: email supports communication, while operational execution requires a structured system for managing work.
This is where many organizations run into the same broader problem described in From Fragmented Systems to Unified Workflows. They have systems of record, but the work itself is still fragmented. They have communication, but not structured execution. They have data, but not enough shared context.
What replacing email-driven processes actually means
Replacing email-driven processes does not mean stopping people from emailing. That is not realistic, and it is not the goal. The goal is to move email back into its proper role. Email should support communication around the workflow.
Do not replace communication. Replace hidden execution.
A practical transformation does not begin by banning email. It begins by identifying where operational execution is currently hidden inside email.
Where are tasks being assigned through messages? Where are approvals happening in replies? Where are files being passed around as attachments? Where are people manually chasing updates? Where are handovers dependent on forwarding conversations? Where are decisions disconnected from the asset record?
These are the points where email has become more than communication. They are also the points where the organization can create the most value by introducing structure.
Create a structured execution layer
For complex asset organizations, the answer is usually not another disconnected system of record. It is a structured execution layer that connects people, tasks, evidence, asset data, and operational context across the workflow.
It should support the reality of complex operations: multiple teams, multiple sites, suppliers, OEMs, operators, security requirements, offline or constrained environments, and long-term traceability needs.
The point is not to add more administration. The point is to reduce the hidden administration already happening through inboxes, spreadsheets, meetings, and manual follow-ups.
Build on existing systems
Most complex asset organizations already have important enterprise systems. They do not need to throw them away.
ERP, PLM, MES, CMMS, logistics, and document systems often play critical roles. The issue is that they do not always match the way work is executed by frontline teams, planners, maintainers, fitters, suppliers, and support organizations.
A structured execution layer should work with those systems, not against them. It should make existing data easier to use, existing processes easier to follow, and existing systems more valuable in real operational workflows.
That is the shift: from email as the unofficial workflow to structured execution that connects the system of record with the work as it actually happens.
Conclusion: email should support the workflow, not contain it
Email is useful, but it is not enough. In complex asset operations, the problem with email-driven processes is not that people communicate too much. It is that communication becomes a substitute for operational control. When work is managed through inboxes, the organization loses visibility and accountability, even when tasks are being completed and conversations are actively taking place.
Email should remain an important part of the communication layer, but the work itself needs to live somewhere structured, visible, secure, and connected to the asset lifecycle. In complex asset operations, the goal is not less communication. It is more controlled execution.