A support manager notices something while reviewing a batch of closed tickets. Three agents handled the same type of refund request that week, all within policy, all polite, all technically correct — but each one resolved it slightly differently. Different timelines communicated to the customer, different conditions offered, different follow-up steps taken. No one is wrong, exactly. There's just no written version of "right" to compare against.
What the support manager is looking at isn't a compliance gap or a personnel issue. It's the natural result of a process that lives entirely in informal explanations and one-off walkthroughs, reproduced imperfectly each time someone new learns it.
*Photo by Vitaly Gariev on *Unsplash
How Process Drift Happens
The version each person learned
Every undocumented process starts with one person who knows how it works. When a new teammate needs to learn it, that person explains it quickly, usually while doing something else, drawing on how they do it today rather than any authoritative source. The new person understands enough to proceed and starts handling cases. When they get a question they can't answer, they ask someone else, who may have learned the process from a different person or at a different time. Two months later, there are three people doing the same task in three slightly different ways, each confident they're doing it correctly, because each one is doing it the way they were shown.
The drift is small at first. A different tone in the follow-up message, a step that one person skips because they learned a shortcut, a condition that one agent applies more broadly than another. None of it rises to the level of an obvious error. All of it is invisible until the customer notices.
When inconsistency becomes visible
The moment drift becomes a problem is usually when the same customer interacts with two different team members on related requests and gets different answers, or when a manager reviews a sample of closed tickets and notices the variance. By then, the drift has been accumulating for weeks or months. The customer who received inconsistent responses has already formed an impression of the business. The manager is now trying to diagnose a process problem from individual behavior rather than from the source.
| Situation | What inconsistency looks like | Why it's hard to catch |
|---|---|---|
| Same question, different agents | Different timelines or conditions quoted | No written reference to compare against |
| New hire learns from senior | Picks up personal shortcuts, not the process | No canonical version exists |
| Busy period hits | Each person improvises in their own direction | Deviations go unreviewed until something breaks |
| Process changes informally | Some people hear about it, some don't | No central record to update |
Why an Alignment Meeting Doesn't Fix It
The fix that needs to happen again next month
The natural response to discovering process drift is to call a meeting, walk through the correct approach, and ask everyone to align. That meeting works — for a while. The team leaves with a shared understanding of how the process is supposed to go. Then another new person joins, learns from whoever is available, and the drift starts again. The meeting's effect decays at exactly the rate the team grows.
Verbal alignment can't survive the pressure of a growing team because it has to be re-transmitted every time someone new arrives. The information degrades slightly with each transmission, which is how informal processes reproduce variation faster than alignment sessions can correct it. This is why teams can run the same alignment session quarterly and still arrive at the next quarter with the same problem. The drift is structural, not behavioral.
⚠️ The compounding problem: Each new team member is a fresh starting point for drift. The more the team grows, the more transmissions happen, and the more each person's version diverges. By the time the variance is visible, there may be no clear "original" left to align back to.
*Photo by Annie Spratt on *Unsplash
The Thing That Actually Stops Drift
One source, not one meeting
A written process stops drift not because it's more persuasive than a verbal explanation, but because it exists independently of whoever is explaining it. When a new agent learns the refund process by reading the written procedure rather than by asking a colleague, they learn the same version as the last person who learned it. When the process changes, one update propagates to everyone. When a manager wants to know what the process actually is, there's a place to look.
This is the thing verbal-only teams miss: the written process isn't a document for the sake of documentation. It's the anchor that holds everyone to the same version of the work as the team grows. Without it, consistency is a side effect of having a small enough team that everyone talks to each other constantly. That side effect disappears around the time you need it most.
💡 A useful test: Ask three different team members to describe the most common process they each run daily. If the answers diverge in any meaningful way (different conditions, different steps, different outputs), you have drift, and it started the moment the process stopped being written down.
The fix is not complicated. Write the process down in a place your team can find it, in the form they'll actually use. Then update it when the process changes, instead of calling a meeting. The meeting solves this week's drift. The document prevents next month's.
*Cover photo by Sable Flow on *Unsplash