Six weeks after Marcus left, a customer asked a question that should have taken five seconds to answer.
Why does our integration sync once a night when everyone else's runs hourly?
Nobody knew.
The ticket from years ago said "changed to nightly per customer request." The configuration was clear. The reason was not.
Marcus would have known. There had been a call with the customer's IT team. Their system could not handle hourly load, and nightly was a temporary fix until they upgraded. They did upgrade, eventually. Nobody on either side remembered the arrangement.
So the new owner of the account made a guess. It was a sensible guess. It was also wrong, and it took two more calls to untangle.
Nothing dramatic happened. No system went down. A question that used to take five seconds took a week, and the customer noticed.
That is what losing an expert usually looks like.
The Handover Covers What, Not Why
When someone good gives notice, companies do roughly the same things. A handover document gets written. Open projects get reassigned. Access gets transferred. There might be a few knowledge transfer meetings in the final week.
All of that is useful, and all of it captures the same kind of knowledge: what the person was responsible for, and what state it is in. Which accounts they owned. Which projects were in flight. Where the important files live.
A handover tells the next person what they're inheriting. It rarely tells them what they'll regret changing.
What the handover rarely captures is why. Why the integration syncs nightly. Why one customer has different payment terms. Why the team stopped using a particular vendor. Why a piece of code that looks wrong is actually deliberate.
The reasons are not left out on purpose. The person leaving cannot list them, because they do not experience them as separate facts. They are just how things are. And the people staying do not know what to ask, because they do not know what they do not know.
What Actually Leaves With Them
It helps to be specific about what walks out the door, because it is rarely the obvious things.
The reasons behind decisions. The decision itself is usually recorded somewhere: a closed ticket, a merged change, a contract term. The reasoning lived in a conversation, and the person who remembers it is gone.
Exceptions and their conditions. Every business runs on a set of agreed exceptions. This customer gets extended terms. That integration skips one validation step. The exception is visible in the system. The conditions under which it was granted, and when it should end, often are not.
What was already tried. Experienced people carry a quiet history of approaches that failed and why. Without it, a team can spend a quarter rediscovering a dead end.
Who to ask. Long-tenured people know who knows what, inside the company and at customers and partners. That map is rarely written down anywhere.
The Cost Arrives Later, Somewhere Else
Knowledge loss is hard to manage partly because it does not show up when the person leaves. The first few weeks often go fine. The handover covered the active work, and the team is paying attention.
The cost shows up months later, scattered across small moments. A decision gets made again, differently, because nobody knew it was already made. A customer exception gets removed because it looked like a mistake. A new hire spends a day reverse-engineering something one message could have explained. A question that used to have an instant answer now needs a meeting.
None of these moments gets labeled "caused by Marcus leaving." They show up as longer support calls, repeated investigations, unnecessary meetings, and customers wondering why the new team doesn't understand decisions the old team made.
The employee leaves once. The company keeps paying for the missing context.
Why the Final Two Weeks Are Too Late
The instinct is to fix this at exit time: longer handovers, more thorough documents, recorded walkthroughs. These help at the margins, but they ask for the hardest thing at the worst moment.
In their last two weeks, the departing person is busy closing out work, and the people staying are busy absorbing it. Years of context cannot be compressed into a document in a few days, especially when nobody knows which parts will matter. The question about the nightly sync would never have come up in Marcus's handover. It only became important later.
The more reliable approach starts much earlier, while the expert is still making decisions, answering questions, and explaining exceptions. As we argued in Your Best Employees Are Holding Your AI Back, Without Knowing It, the knowledge that matters is mostly being shared all the time, in answers, comments, and threads. The question is whether those answers land somewhere that outlasts the person who wrote them.
If Marcus had explained the nightly sync in the ticket, or in a shared channel, instead of only on a call, the reason would still be there. Nobody would have needed a handover to find it. In most of the tools teams use every day, what someone wrote in a shared channel, a ticket, or a pull request stays in place after they leave.
How Modly Handles It
Modly connects the systems a company already works in, such as Slack, Jira, Confluence, GitHub, Salesforce, and Google Drive. That matters here because the reasoning behind decisions is rarely in a formal document. It is in a ticket comment, a thread, or a pull request discussion, written by someone who may no longer be at the company.
The explanation stays attached to the answer. When the new account owner asks why the integration syncs nightly, and the reasoning exists in a connected ticket or thread, the answer links straight to it. They can read the original explanation in the original author's words, see when it was written, and judge whether it still applies. The person is gone. Their reasoning is not.
Missing knowledge stays visible. If the reason was only ever said on a call, there is nothing to cite, and Modly says so rather than inventing a plausible explanation. That matters most right after someone leaves, when a confident wrong answer is the most expensive kind. It also tells the team something useful: this is a question where the knowledge may have walked out the door, so ask before acting.
Old knowledge doesn't become public knowledge. Knowledge outliving a person does not mean it becomes visible to everyone. Each person gets answers built only from the sources they can already access, on every query, so a restricted thread stays restricted.
The next person starts with the right context. A profile for the account management team can include the channels, projects, and records the role depends on, so whoever inherits the work is asking questions against the same sources the previous owner worked in. We covered how profiles work in Context Profiles: Why AI Shouldn't Treat Everyone the Same.
None of this replaces the person. Modly cannot preserve a conversation that was never recorded. But when the reasoning exists in a connected, accessible source, it can help the next person find it without knowing who originally wrote it.
What Changes
Go back to the customer and the nightly sync.
Suppose the reasoning had been written in the ticket when the change was made: "Customer's system cannot handle hourly load. Nightly until their upgrade, then revisit." Two sentences.
The new account owner asks the assistant why the integration syncs nightly. The answer comes back with the reason and a citation to the ticket. It also makes the next step obvious: the customer has since upgraded, so it is time to revisit. A question that once depended on Marcus's memory can now be answered from the reasoning he left behind.
You cannot stop good people from leaving. And you cannot expect their final two weeks to account for every question someone will ask six months later.
What you can do is make sure the reasoning they share today becomes something the company can find tomorrow.
The person may leave. The reason behind the decision shouldn't have to leave with them.
The best time to prepare for an expert leaving is long before they give notice.
If you want to see how cited, permission-aware answers work on your own systems, we run a 30-minute walkthrough on real data: Book a demo.
Related reading:
