When Inactive Doesn't Mean Gone: Why Customer Account Aging Breaks the Standard Playbook

Not half of some edge-case segment - half. The kind of number that makes you stop and ask what's actually being measured, because no company loses half its active customers to simple neglect. So we went and found the developer who'd built the acceptance tracking, and the answer was almost mundane: most of these customers were added to the system before “invitations” existed as a feature at all. There was nothing to accept, because acceptance wasn't a concept yet when their accounts were created. The logic wasn't wrong. It was checking for a record that, for a huge chunk of the customer base, could never have existed in the first place.

That's this week’s takeaway from my latest client engagement: a policy built entirely correctly for the system as it exists today, walking straight into a population that predates it.

Workforce IAM assumes a predictable shape. Employee hasn't logged in for 90 days, they probably changed roles or left - HR lifecycle and login activity move together. Customer identity doesn't play by those same rules. A billing contact might log in once a year to pull an invoice or a tax document, while their integration processes thousands of API calls a day. An executive sponsor might touch the platform only at renewal time. None of that is dormancy. It's a login pattern that doesn't match an internal employee's, applied to a population that never included internal employees.

The invitation-acceptance field in this case is a small, specific example of what I call Cognitive Debt: a rule that was perfectly sound the day it was written, quietly accumulating risk as the system it describes keeps changing underneath it. Nobody added bad logic. The product just grew a feature - invitations - after a large slice of the customer base already existed without one, and the aging policy never took that history into account.

The other thing worth reviewing: the developer's instinct was a 1-year inactivity window, which is a completely defensible default. The founder overruled it and set the threshold at 5 years, based on knowing the actual customer base and how the product's renewal and usage cycle runs. That's domain knowledge correcting a number that looked fine in isolation but would have been dead wrong in practice. The right inactivity window isn't a security best practice you import. It's a business fact you have to ask about from someone who actually knows the customers.

Running the numbers before executing is the whole point. Nobody got locked out, nobody's renewal broke, no support ticket ever got filed - because the check happened before the policy went live, not after a customer complained. That's the difference between a policy and an incident: whether you find the gap in a dry run or in production.

What's the last policy your team ran the numbers on before flipping it live — and what did the numbers say?