{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-08-15T19:57:48.404Z"},"content":[{"type":"documentation","id":"3ee848e0-57e6-4c54-b183-6d2b57a91620","slug":"condition-based-vs-scheduled-customer-research","title":"Preventive vs Condition-Based: Why Scheduled Check-Ins Are Wasted on Most Accounts (2026)","url":"https://www.koji.so/docs/condition-based-vs-scheduled-customer-research","summary":"Argues that scheduled account intervention is justified only when the churn hazard is rising and enough accounts survive to reach the intervention point, imports the reliability-centered maintenance finding that 89 percent of items had no wear-out zone, shows that intrusive scheduled contact carries a real destabilisation cost, defines the potential-failure condition and its required lead time, applies the observer position-and-standards test to telemetry versus interviews, and gives a cadence redesign sequence ending in a randomised holdout.","content":"Scheduled account check-ins only reduce churn when the risk of churn rises with tenure. When risk is flat or falling - which describes the large majority of accounts for most of their life - a calendar-driven cadence is not merely low-yield, it can be actively counterproductive. The alternative is condition-based: define an observable condition that indicates churn is imminent, establish how much warning it gives you, and trigger on the condition instead of the date.\n\nThis is the operating conclusion of the two analyses that precede it. Our [churn hazard curve guide](/docs/churn-hazard-curve-tenure-analysis) shows how to see the shape of risk; our guide to [why average lifetime is not 1/churn](/docs/customer-lifetime-mtbf-ltv-formula) shows why the summary statistic hides it. Both assume the goal is to measure failure correctly. This one asks the question measurement exists to serve: given the shape, what work is worth doing?\n\n## The rule scheduled intervention has to satisfy\n\nMaintenance engineering states the condition for a scheduled task to help, and it has two parts, not one. Effectiveness \"depends not only on large increases in conditional probability at higher ages, but also on a high probability of survival to those ages\" ([Nowlan and Heap, *Reliability-Centered Maintenance*, 1978](https://www.omdec.com/wikifiles/nowlanHeap.pdf), p. 25).\n\nIn account terms, a scheduled intervention at month N is justified only if:\n\n1. **The hazard is rising into month N.** If risk is flat, intervening at month 9 has no more expected value than at month 4 - you are choosing a date at random. If risk is falling, you are intervening when things are getting safer.\n2. **Enough accounts actually reach month N.** A well-aimed intervention at month 30 is worthless if 80 percent of the cohort left before month 30. The value is the risk reduction multiplied by the population that survives to receive it.\n\nMost cadences satisfy neither. Quarterly business reviews land on quarters because quarters exist.\n\n## What happened when an industry checked\n\nThe United Airlines analysis found that 89 percent of items \"had no wearout zone; therefore their performance could not be improved by the imposition of an age limit.\" Only 11 percent had an age-related pattern that might justify a scheduled limit, and only 6 percent showed pronounced wear-out.\n\nThe largest single group - pattern F, 68 percent of items - is infant mortality followed by a constant or very slowly increasing failure probability. For that shape, the optimal scheduled-overhaul interval does not exist. There is no age at which the item becomes more likely to fail, so there is no age at which pre-emptive action pays.\n\nThe industry response was not to schedule harder. It was to stop scheduling where scheduling could not work, and to redirect the effort into inspecting for conditions that indicate imminent failure. As the report puts it, \"recognition of the specific need to identify potential-failure conditions has been responsible for the change from scheduled overhauls to on-condition inspections for signs of imminent failure.\"\n\n## Scheduled work can cause the failure it was meant to prevent\n\nThis is the part that should change how you think about a low-value QBR.\n\nNowlan and Heap's decision logic defaults to *no scheduled maintenance* when the costs are close, and the reasoning is explicit: \"any preventive-maintenance task may disturb the steady-state conditions of the mechanism, and this risk should not be introduced without good cause. Thus a preventive task will be scheduled only where the cost of correcting failed items far outweighs the cost of preventing failures.\"\n\nIntrusive work resets a settled system into its infant-mortality phase. The account analogue is not a metaphor:\n\n| Intrusive scheduled action | How it can disturb a stable account |\n|---|---|\n| Quarterly review with a new CSM | Reopens \"what are we actually paying for\" with someone who lacks the history |\n| Renewal outreach 120 days early | Starts a procurement process that would otherwise have auto-renewed |\n| Unprompted \"how are we doing\" survey to a content user | Manufactures a complaint that had not been salient |\n| Reorganising the account team on a schedule | Destroys the relationship capital that was doing the retention work |\n| Proactive upsell call during the flat regime | Converts a quiet account into an active budget conversation |\n\nNone of these is always wrong. The point is that they carry a cost that cadence-based programs book as zero. The default for a flat-hazard, healthy account should be no scheduled contact, with the burden of proof on intervening.\n\n## Condition-based: the potential failure and its warning time\n\nThe alternative requires something more specific than a health score. The concept is the *potential failure*, defined as \"an identifiable physical condition which indicates a functional failure is imminent.\"\n\nTwo properties make a condition usable:\n\n- **It is identifiable.** Someone can determine whether it is present, with a stated standard, not a vibe.\n- **It gives warning.** There is a real interval between the condition becoming detectable and the failure occurring. If your signal fires two days before cancellation, it is a notification, not an early warning.\n\nThat second property is the one retention programs almost never measure. Before trusting a churn signal, establish the lead time empirically: for accounts that churned, how long before cancellation did the condition first appear? If the honest answer is \"we do not know,\" the program is running on faith.\n\n| Candidate condition | Identifiable? | Typical warning time | Verdict |\n|---|---|---|---|\n| Champion leaves (detected via CRM or org change) | Yes, with a defined standard | Months | Strong trigger |\n| Support tickets on the same workflow three months running | Yes, countable | Weeks to months | Strong trigger |\n| Login count drops below threshold | Yes | Days to weeks | Weak - often coincident with the decision |\n| Composite health score turns amber | Depends on the model | Unvalidated in most teams | Measure lead time before trusting |\n| Renewal date approaching | Yes, trivially | Fixed | Not a condition at all - this is the calendar |\n\nThe two policies differ on more than timing:\n\n| | Scheduled (preventive) | Condition-based (on-condition) |\n|---|---|---|\n| Trigger | A date | An observed condition |\n| Requires | Rising hazard plus high survival to the date | A detectable condition with real lead time |\n| Fails when | Hazard is flat or falling | The condition is unobservable from your position |\n| Cost profile | Fixed and predictable; paid on every account | Variable; paid only on flagged accounts |\n| Typical failure mode | Activity mistaken for coverage | Trigger fires too late to act |\n| Right use in accounts | Renewal windows, contractual decision points | The long flat middle of the book |\n\n## Who is in a position to observe the condition\n\nDetection has two prerequisites, and both are frequently missing. The observer \"must be in a position to detect the failure,\" which may mean \"a physical location, a particular moment in time, or access to the inspection equipment that can reveal the condition.\" And the observer \"must have standards that enable him to recognize the condition he sees as a failure.\"\n\nApply that pair to your retention program and the gap is usually obvious. Your telemetry has excellent standards - thresholds, definitions, dashboards - and a poor position: it observes what happens inside your product, and most churn causes originate outside it. A budget cut, a reorganisation, a competitor's roadmap commitment, a champion's quiet decision to change jobs. None of these emit an event.\n\nNowlan and Heap make the corresponding observation about aircraft: \"Members of the operating crew are the only people in a position to observe the dynamic operation of the equipment in its normal environment,\" in contrast to an airplane in a maintenance facility, which \"is in a static environment.\"\n\nYour users are the operating crew. Your analytics is the maintenance facility. Both are necessary, and only one of them is positioned to see the conditions that matter most.\n\nThis is the honest case for research inside a retention program, and it is a position argument rather than a product pitch: some conditions can only be detected by asking, and a program that only watches telemetry has excellent standards trained on the wrong location.\n\n## Redesigning the cadence\n\nA practical redesign, in order:\n\n1. **Plot the hazard by tenure and segment.** You cannot allocate rigour without knowing the shape. This is the input, and it is why this article is third.\n2. **Classify each segment.** Falling hazard (post-onboarding), flat (the long middle), or rising (wear-out, or a genuine contractual event such as a renewal decision window).\n3. **Cut scheduled contact in the flat regime.** Replace it with condition triggers. Expect resistance: the cadence is often what the team's calendar is made of.\n4. **Keep scheduled work only where the hazard genuinely rises and enough accounts arrive.** Renewal windows are the legitimate case, because the risk really is concentrated at a known date.\n5. **For each trigger, measure lead time before you trust it.** Retrospectively, on accounts that already churned.\n6. **Check that the condition is observable from a position you occupy.** If not, the only way to detect it is to ask.\n7. **Test the program, do not assume it.** The clean design is a randomised holdout of accounts that are scored but not contacted - the test described in our guide to [surveillance bias](/docs/surveillance-bias-detection-research). Without it, a retention program can run for years generating activity reports and no evidence.\n\n## How this differs from building a health score\n\nOur [customer health score guide](/docs/customer-health-score-saas-guide) covers how to construct the model - the pillars, the weighting, the tiers. This article covers two questions that sit outside the model and are usually left unasked:\n\n- **Should the calendar be a trigger at all?** For most accounts, most of the time, the answer is no, and the health score is not what tells you that. The hazard shape is.\n- **Does the score have lead time?** A score that turns amber at the same moment a human would have noticed is a dashboard, not an early warning. Lead time is a measurable property, and measuring it is the difference between a validated trigger and a comfort blanket.\n\nA good health score is the instrument. This is the maintenance policy that decides when to read it.\n\n## How Koji operationalises condition-based research\n\nCondition-based work fails in practice for a mundane reason: the trigger fires and there is no affordable way to find out what is actually happening at that account this week. Scheduling a moderated interview takes days, so teams fall back on a CSM's impression or an email that goes unanswered.\n\n- **Trigger-fired studies.** When a condition fires, launch an AI-moderated interview against that account immediately. Interviews run asynchronously, in the participant's own time, which is what makes a same-week response realistic rather than aspirational.\n- **Standing wear-out coverage.** For the regime where the hazard genuinely rises, keep a continuous study running against tenured active accounts. Wear-out accumulates too slowly for anyone to recall it at cancellation.\n- **Lead-time measurement you can actually run.** Interview accounts whose condition has fired but who have not churned, and ask directly how long the underlying problem has been building. That establishes the warning interval that separates a real trigger from a coincident one.\n- **Consistent instrumentation across accounts.** Comparing detected conditions across accounts staffed by different CSMs is invalid when probing depth varies. An AI moderator applies the same brief everywhere, which is the precondition for treating the comparison as evidence.\n- **Both halves of the signal in one study.** Koji's six [structured question types](/docs/structured-questions-guide) - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - let a triggered study return a countable severity reading alongside the narrative. A yes_no on whether a workaround is still in place and a ranking of current frustrations give the trigger a measurable state; the open_ended gives you the mechanism.\n\nThe economic argument mirrors the maintenance one. Nowlan and Heap schedule preventive work only when the cost of failure \"far outweighs the cost of preventing failures.\" When the cost of finding out what is happening at an account drops from a week of coordination to a same-day study, more conditions clear that bar - and the calendar stops being the default answer to a question nobody re-examined.\n\n## A working checklist\n\n1. Plot the hazard by tenure and segment before touching the cadence.\n2. For every recurring scheduled touchpoint, ask which rising hazard it targets. Cut the ones with no answer.\n3. Assume intrusive scheduled contact has a non-zero cost; require a reason to run it.\n4. Define each trigger as an identifiable condition with a written standard.\n5. Measure lead time retrospectively for every trigger before trusting it.\n6. Audit position: list the top churn causes and mark which are observable from telemetry. Cover the rest by asking.\n7. Keep scheduled work at genuine risk concentrations, principally renewal windows.\n8. Run a randomised holdout before claiming the program works.\n\n## Frequently asked questions\n\n### Are quarterly business reviews a waste of time?\n\nNot universally, but the default assumption should be reversed. A QBR is justified when it targets a period of rising churn risk, when enough accounts reach that period, and when the meeting does work no trigger-based contact could do - such as a genuine renewal negotiation. A QBR held because the quarter ended, against an account in a flat-hazard regime, is very likely to be low-yield and carries a real risk of destabilising a settled relationship.\n\n### What is condition-based maintenance in a customer success context?\n\nIt is triggering action on an observed condition that indicates churn is imminent, rather than on a date. The condition must be identifiable against a written standard and must provide meaningful warning time before the outcome. It is the direct analogue of on-condition inspection replacing scheduled overhaul in aviation maintenance.\n\n### How do I know if my churn signal has enough lead time?\n\nMeasure it retrospectively. Take accounts that churned in the last year, find when the condition first became true for each, and compute the interval. If the median interval is shorter than the time your team needs to respond meaningfully, the signal is a notification rather than an early warning, and no amount of dashboarding will fix that.\n\n### Can proactive outreach actually increase churn?\n\nIt can. Reliability practice defaults to no scheduled intervention when costs are comparable, on the grounds that intrusive work \"may disturb the steady-state conditions of the mechanism.\" Commercially, an unprompted review can reopen a settled value question, an early renewal conversation can start a procurement process that would not otherwise have happened, and a satisfaction survey can make a minor irritation salient. These costs are real and are almost never modelled.\n\n### Does this mean I should stop talking to healthy accounts?\n\nNo - it means stop contacting them on a calendar for the purpose of retention. Research contact serves a different goal: understanding the wear-out mechanism, testing concepts, and establishing baselines. Keep that, run it as sampled research rather than blanket account management, and be clear internally about which of the two any given touchpoint is.\n\n### How does this fit with a customer health score?\n\nThe health score is the instrument; this is the policy governing when and whether to act on it. A score tells you an account looks unwell. The hazard shape tells you whether scheduled intervention could have helped at that tenure, and the lead-time measurement tells you whether the score fires early enough to matter.\n\n## Related Resources\n\n- [The Churn Hazard Curve](/docs/churn-hazard-curve-tenure-analysis) - how to see the shape of risk by tenure\n- [Average Customer Lifetime Is Not 1/Churn](/docs/customer-lifetime-mtbf-ltv-formula) - why the summary statistic hides the shape\n- [Customer Health Score Guide](/docs/customer-health-score-saas-guide) - building the instrument this policy reads\n- [Structured Questions Guide](/docs/structured-questions-guide) - the six question types and when to use each\n- [Surveillance Bias in Research](/docs/surveillance-bias-detection-research) - why the randomised holdout is the only clean test\n- [Customer Renewal Interviews](/docs/customer-renewal-interview-guide) - the one cadence the hazard curve justifies\n","category":"Research Operations","lastModified":"2026-08-15T03:24:20.834591+00:00","metaTitle":"Condition-Based vs Scheduled Customer Check-Ins (2026 Guide)","metaDescription":"Quarterly check-ins only work when churn risk rises with tenure. Learn the two-part rule for scheduled intervention, how to define a potential-failure condition, and how to measure a trigger's lead time.","keywords":["condition based customer success","QBR effectiveness","proactive outreach churn","churn early warning lead time","customer check-in cadence","preventive maintenance analogy customer success","churn trigger validation"],"aiSummary":"Argues that scheduled account intervention is justified only when the churn hazard is rising and enough accounts survive to reach the intervention point, imports the reliability-centered maintenance finding that 89 percent of items had no wear-out zone, shows that intrusive scheduled contact carries a real destabilisation cost, defines the potential-failure condition and its required lead time, applies the observer position-and-standards test to telemetry versus interviews, and gives a cadence redesign sequence ending in a randomised holdout.","aiPrerequisites":["A churn hazard curve by tenure and segment","An existing check-in cadence or health score to evaluate"],"aiLearningOutcomes":["Apply the two-part rule for justifying a scheduled intervention","Recognise when preventive contact can destabilise a healthy account","Define a churn trigger as an identifiable condition with a written standard","Measure a trigger's lead time retrospectively","Audit whether your program is positioned to observe its top churn causes"],"aiDifficulty":"advanced","aiEstimatedTime":"13 min"}],"pagination":{"total":1,"returned":1,"offset":0}}