Most teams try to prevent problems they haven't verified and verify things they haven't detected. The sequence isn't a slogan — it's the operating logic of a system that actually works.
Every RevOps team is trying to solve the same problem: make sure your revenue systems agree with each other and reflect reality. But the approaches differ — and the order matters more than most people realize.
Prevention without detection is policy theater. You can have the best offboarding checklist in the world. If you don't have a way to verify that the checklist was followed — and a way to detect when it wasn't — the policy is just a document. Prevention without detection is hope, not a control.
Verification without detection is random sampling. You can reconcile your HRIS and ICM at the end of every quarter. But if you don't know where the drift is likely to be — which events create misalignment, which employees are in a transition state — you are checking everything equally when most of the risk is in a few places.
Detection is the hardest step to operationalize — not because the technology is complex, but because it requires accepting that your current state is probably wrong. Most revenue leaders run on the assumption that their systems are in sync unless someone files a dispute. Detection inverts that assumption. You assume drift until you can prove otherwise.
Effective detection is cross-system, event-triggered, and specific. Not 'run a quarterly reconciliation.' Not 'check when a rep complains.' When an event occurs in HRIS — a role change, a departure, a territory shift — that event should trigger an automatic check across every system that depends on the changed data. Within 24 hours. Not at quarter-end.
There is an important distinction between a finding and evidence. A finding is 'these two systems disagree.' Evidence is 'these two systems disagreed starting on this date, triggered by this event, and the disagreement created this specific exposure — documented with timestamps, system names, and the nature of the mismatch.'
Verification without evidence generation is an alert system. Alert systems are useful but they don't survive an audit. An auditor doesn't want to know that you have alerts. They want to know that when an alert fired, you have a record of what was found, when, by what process, and what action was taken. That's an audit trail. That's verification.
The difference between a finding and evidence is the difference between knowing something is wrong and being able to prove it — to yourself, to your team, and to an auditor. Most orgs produce findings. Very few produce evidence. — Ken Lannon, OrgDrift
Prevention gets misunderstood. Most organizations define it as 'stop the same error from happening again.' The right definition is narrower and more ambitious: eliminate the class of problem — not just this instance, but the structural condition that allowed it to happen.
If your comp tool keeps running calculations against departed reps' plans because the ICM update process is manual and dependent on a specific person noticing, the instance-level fix is to update the plan after each departure. The class-level fix is to make the ICM update a triggered, automated consequence of the HRIS termination event — so that no future departure can ever create the same condition.
The ODI is a score — a single number that represents the degree of misalignment between your revenue systems at a point in time. A high ODI means many systems are out of sync; a low ODI means they are closely aligned. But the most important ODI metric is not the score itself — it's the trend.
If your ODI goes down over time, your prevention efforts are working. Each cycle, fewer drift events are going undetected, fewer systems are out of sync, fewer departures are creating downstream problems. The ODI trend is the measurement that tells you whether your control environment is improving or just reacting.
Detect → Verify → Prevent is the operational sequence. The ODI is how you know the sequence is working. And the starting point — before any of the rest is possible — is a baseline scan that tells you where your systems currently stand.
The first step is detection — and the easiest version of detection is a point-in-time scan. Drop in a CSV from your HRIS and CRM, or your HRIS and ICM, or all three. Get a report showing every record that doesn't agree. That is your current drift state. It is almost certainly worse than you expect and better than it will be if you don't act.
You can't verify what you haven't detected. You can't prevent what you haven't verified. Start with detection. Everything else follows.
Drop in a CSV export from your HRIS, CRM, or comp system. Get your ODIS in minutes. Your data never leaves your browser.
Scan my data →No IT ticket. No OAuth. No data upload to any server.
Get Drift Notes
Short, sharp field notes on data propagation, control risk, and audit pain.
OrgDriftThe verification layer between your systems and your auditors.
“Your org changed. Nobody told your data.”
Every record sealed with a tamper-evident hash
Your data never leaves your browser
Enterprise compliance certification in progress