Most companies have integrated their software less effectively than they think.
The CRM works. The support platform works. The data warehouse works. Documentation exists. Slack contains decisions. Employees know how to navigate all of it.
That last sentence is doing a lot of work.
When information doesn’t move reliably between systems, employees move it themselves. They search, copy, compare, translate, route, and remember. Once they’ve rebuilt the necessary context, they can finally make the decision they were hired to make.
We tend to call this collaboration. Often, it’s skilled people performing systems integration by hand.
The work before the work
Think about an account executive preparing for a customer meeting.
They need the account history, recent conversations, product activity, open support issues, previous commitments, contract details, and any internal discussion that might change how they approach the customer.
That information probably exists. The account executive still has to know where to find it.
They may need to decide which source is current, compare records that disagree, locate the relevant Slack thread, and figure out which details matter now. Only then can they turn the pieces into a usable picture of the account.
Meeting preparation is the visible task. Reconstructing the context is the work before the work.
At one company, I mapped more than 100 go-to-market tasks, many with four or five subtasks. The same pattern kept appearing. Before someone could act, they had to retrieve information from several systems and rebuild context that had already existed somewhere else in the workflow.
The company didn’t lack information. The workflow lacked a reliable way to carry that information forward.
Fragmentation can look like a functioning process
This work rarely appears in a process document.
A playbook might say, “Review account health.” It won’t mention that the employee has to open five tools, search two versions of the customer’s name, check whether a dashboard refreshed, ask Customer Success about an exception, and compare a recent conversation with a note entered six months ago.
Employees get good at navigating this. That’s part of what makes the operating problem difficult to see.
The experienced person knows which dashboard is usually behind, which field can’t be trusted, who remembers why a decision was made, and where the useful spreadsheet lives. The process appears to work because that person knows how to compensate for it.
Then they go on vacation, change roles, or leave.
What looked like a functioning workflow turns out to have been one person quietly holding several systems together.
Every system holds part of the story
I saw the same pattern at another company while trying to understand customer problems.
Product analytics showed what happened. Support conversations showed what customers experienced. Documentation explained what was supposed to happen. Engineering understood why the system behaved as it did. Account records, churn surveys, app reviews, bot conversations, and Help Center activity supplied other parts of the story.
No source could explain the problem on its own.
Someone had to connect the metric to the customer’s experience, the intended product behavior, and the technical explanation before the company could decide what needed to change.
Connecting those perspectives is valuable work. Rebuilding the same context at every handoff isn’t.
A support issue becomes a product investigation. The investigation becomes an engineering task. The fix becomes a customer communication. Each time the work moves, someone summarizes what they know for the next person. Some detail disappears. The next team searches for it again. The company pays several times to reconstruct the same chain of events.
Every tool may be working correctly. The space between them is where the work gets expensive.
Coordination is an operating cost
Businesses measure labor by role, team, and project. They rarely measure how much time employees spend preparing to do the work.
Searching for information takes a few minutes. Checking whether it’s current takes a few more. Copying it into another system barely registers. Asking someone to clarify an exception feels like normal collaboration.
Each action is small. Across a company, they add up.
The burden also tends to grow with the business. More customers create more records. More teams create more handoffs. More tools create more places to look. As work becomes more specialized, fewer people can see the full picture without first assembling it.
Growth creates more coordination around the work, not just more work.
This is why a useful new tool can still make the overall process worse. If an employee has to leave the workflow, assemble context for the tool, evaluate its output, move the result somewhere else, notify another person, and document what happened, the company has added another stop to the route.
A clever answer in a separate window doesn’t help much if the employee still has to transport it by hand.
Start with the decision
I’d start by looking at the decision or action the employee is trying to complete.
What do they need to know at that moment? Which source should they trust? What has changed since the last step? Which exceptions need attention? Where should the decision and its supporting context go next?
Those questions reveal whether the workflow is actually carrying information forward or relying on an employee to reconstruct it.
An account executive preparing for a meeting should begin with the relevant account context already assembled. They shouldn’t need to know how every department stores information.
A support agent receiving an escalated conversation should inherit what the customer has already explained, which content they saw, what the automated system tried, and why the case was handed over.
A finance employee reviewing a discrepancy should see the source records, the rules already applied, and the reason the case now requires judgment.
People don’t need everything the company knows. They need the smallest amount of reliable context that allows them to make a good decision.
Save people for the work that needs people
Employees will always connect information in ways software can’t. They understand relationships, history, consequences, and the unusual situation that doesn’t fit a documented rule.
That’s where their time belongs.
They shouldn’t have to remember which tool owns the answer, translate the same information for every team, or rebuild a customer’s history each time the work changes hands.
When skilled people spend most of their time gathering context, the company is paying for judgment and using it for retrieval.
Look closely at the work people do before the visible work begins. That’s often where the operating cost is hiding. It’s also where better information flow can give employees their time back for the decisions that actually need them.