Crossdating Customer Stories: Placing an Account by Pattern, Not by Counting (2026)

You cannot place a new customer by counting how far along they are. You place them by matching the shape of their story against a library of stories whose outcomes you already know. Dendrochronologists worked this out in the early twentieth century and it is the reason a timber can be dated to an exact calendar year rather than an approximate century. The technique is called crossdating, and it is the correct model for what product teams are actually trying to do when they ask where an account sits.

The counterintuitive part: counting is the intuitive method and it is the one that fails. Pattern matching is more work to set up and it self-corrects against exactly the errors that destroy a count.

Why counting rings does not work

The naive method for dating a tree is to count its rings: one ring, one year, subtract from the present. It is obvious, and it is wrong often enough to be useless for precision work, for two specific reasons.

Missing rings. In some years a tree lays down no visible ring at all. Particular tree species may present missing rings, and their frequency varies by species and by stress: they are rare in oak and elm, common enough elsewhere to matter. Every missing ring makes the tree read one year younger than it is.

False rings. The opposite error. Alternating poor and favorable conditions, such as mid-summer droughts, can result in several rings forming in a given year. Every false ring makes the tree read one year older than it is.

Both errors are silent. Nothing in the specimen announces them, and they do not cancel: a sample with three missing rings and one false ring is off by two years with complete confidence. A count produces a number with no way to check itself.

The customer-research analogue is exact, and most teams run on it. The naive method for placing an account is to count: how many weeks since signup, how many sessions, how many features adopted, which onboarding step they reached. Then:

• Missing rings. A quarter where the account used the product hard but under a shared login, or through an integration, or via a champion who left. Real usage, no trace. The account reads younger and less committed than it is.
• False rings. A burst of activity driven by one enthusiastic evaluator, a migration, or a single quarterly reporting scramble. One period of stress produced several rings' worth of signal. The account reads more mature than it is.

A tenure count and an adoption count are both ring counts, and both carry the same unfixable defect: no internal check.

What crossdating does instead

The dendrochronological method was developed by A. E. Douglass, who founded the field in the first half of the twentieth century and established the Laboratory of Tree-Ring Research at the University of Arizona while trying to trace sunspot cycles in climate.

It rests on a single observation: trees from the same region tend to develop the same patterns of ring widths for a given period. A drought year produces a narrow ring in every tree that experienced it. A good year produces a wide one. The sequence of wide and narrow, across decades, is effectively a barcode stamped simultaneously on every tree in the zone.

So instead of counting, you match. A sample's ring pattern is compared ring-for-ring with patterns from trees which have grown at the same time in the same geographical zone, and therefore under similar climatic conditions. Once the pattern locks into position against a reference sequence built from trees of known date, every ring in the sample inherits a calendar year. The method allows specimens of once-living material to be accurately dated to a specific year.

Notice what just happened to the missing-ring problem. If your sample is missing a ring, the pattern will not align until you allow for the gap, and the misalignment is visible: the wide-narrow sequence stops matching. The error announces itself, and once corrected the whole sample is anchored. The same for a false ring. Pattern matching turns silent errors into loud ones, which is the only property that makes precision possible.

That reference sequence has a name worth borrowing: a master chronology. It is built by overlapping samples of known age until you have a continuous, dated pattern for a region. It is the asset, and building it is the whole job.

Building a master chronology for customers

A customer master chronology is a library of narrative sequences from accounts whose outcomes you already know, aligned on the events that all of them experienced.

Four properties make it work, and each maps onto the dendrochronology.

1. Same zone. Trees are only comparable if they shared a climate. Accounts are only comparable if they shared a market, a segment, and a product era. A master chronology for mid-market accounts will misdate an enterprise account, and one built before a pricing change will misdate everything after it.
2. Shared stress events. Rings are datable because bad years hit every tree. Your alignable events are the ones that hit every account: a pricing change, a migration, a renewal cycle, a key integration going live, a competitor entering. These are your narrow rings, and they are what the pattern locks onto.
3. Pattern, not magnitude. Dendrochronology matches the relative sequence of wide and narrow, not absolute widths, because absolute growth varies by tree. Match the shape of an account's experience, the order in which friction appeared and resolved, rather than the absolute size of its usage numbers.
4. Overlap to extend. A master chronology is built by chaining overlapping samples. You extend yours the same way: each new account whose outcome resolves becomes part of the reference, which is why the library compounds while a dashboard does not.

With that library in hand, the question changes usefully. Not "how long has this account been a customer" but "which known sequence does this account's pattern match, and what happened next to the accounts that matched it." That is a forecast with a mechanism attached, rather than a correlation.

One honest caution, because dendrochronology is honest about it: rings record only what was limiting. A drought year produces a narrow ring because water was the constraint; in a year when water was abundant, ring width says nothing about rainfall. Your signals work the same way. Adoption reflects whatever was the binding constraint that quarter, and in a quarter when nothing was binding, the metric records nothing about the thing you are trying to measure. Which constraint was active is a question only a conversation answers.

Getting the narrative in comparable form

Crossdating requires that every sample be measured the same way. This is the practical obstacle: account stories normally live as unstructured notes taken by different people asking different questions, and two narratives gathered differently cannot be aligned any more than two trees measured with different rulers.

What you need from each account is the same sequence, in the same order, at the same grain: when did friction first appear, what did they try, what changed, what was the state at each named event. That is a structured interview protocol, run identically across accounts, which is also why how many interviews are enough is the wrong first question here. Crossdating does not need a large sample. It needs comparable samples, and enough of them with known outcomes to form a reference.

How Koji handles this

Building a master chronology means running the same protocol across many accounts and getting back identically-shaped data. That is precisely what Koji is for.

• The same interview, run identically every time. Koji's AI interviewer asks every participant the same core sequence, so the samples are comparable by construction. Human moderators drift across 40 interviews; the drift is what destroys alignability.
• Structured questions give you the measurable rings. Koji's six question types, open_ended, scale, single_choice, multiple_choice, ranking, and yes_no, produce values on identical scales across every account in the library, which is what makes ring-for-ring comparison possible at all. See structured questions in AI interviews.
• AI follow-ups capture the limiting factor. Where a scale question records that a quarter was hard, Koji's follow-up probing records which constraint was binding, which is the information a ring width cannot carry.
• Always-on studies extend the chronology continuously. Running discovery through Koji as a standing study means each newly-resolved account joins the reference sequence automatically, rather than requiring a fresh research project to extend the library.
• Reports and exports built for comparison. Koji aggregates structured answers across a study and exposes the underlying data through its MCP tools, including koji_get_study_data and koji_export_data, so aligning a new account against the library is an analysis step rather than a transcription project.
• Quality scoring keeps bad samples out of the reference. Koji scores each conversation from 1 to 5 on relevance, depth, and coverage. A thin interview is a specimen too degraded to crossdate, and keeping it out of the master chronology matters more than keeping it out of any single report.

Frequently asked questions

What is crossdating, in one sentence?

Matching the pattern of a sample against a reference sequence of known date, rather than counting units within the sample, so that every unit inherits an absolute position and any counting error reveals itself as a misalignment.

Why is counting tenure or usage a bad way to place an account?

Because both are ring counts with no internal check. Unrecorded usage makes an account read younger than it is, and a one-off burst of activity makes it read more mature than it is; neither error announces itself, and they do not cancel out. A pattern match against known cases fails visibly when it is wrong, which is what makes it trustworthy.

How many accounts do I need before a master chronology is useful?

Fewer than you would guess, and the constraint is comparability rather than volume. A dozen accounts with resolved outcomes, interviewed with an identical protocol and aligned on shared events, beats hundreds of inconsistently-gathered notes. Add each resolved account to the reference as it closes and the library compounds.

What are the shared events I should align on?

Things that hit every account in the zone at roughly the same time: pricing changes, migrations, renewal cycles, a major integration going live, a competitor's entry, a platform change you shipped. These are the narrow rings. Account-specific events are useful detail but cannot anchor an alignment, because nothing else shares them.

Does this replace segmentation?

No, it operates inside a segment. The same-zone requirement means a master chronology is only valid for accounts that shared a market, a segment, and a product era, so segmentation defines the zone and crossdating places accounts within it. Customer segmentation research covers building the zones themselves.

What does the limiting-factor caveat mean for my metrics?

That a metric records information only when the thing it measures was the binding constraint. Adoption falling tells you something was limiting; adoption being fine tells you almost nothing about which constraints exist, because a non-binding constraint leaves no mark. Interviews are how you find out which constraint was active, which is why the pattern library needs conversational data and not only telemetry.

Related Resources

• Structured Questions in AI Interviews - the six question types that make account narratives comparable across a library
• How Many Interviews Are Enough? - why comparability beats raw sample size for pattern work
• Customer Segmentation Research - defining the zone within which a master chronology is valid
• The Assemblage and the Type Fossil - which individual signals actually carry dating information
• Terminus Post Quem - dating the pile your reference sequence is built from
• The Complete Guide to Thematic Analysis - turning transcripts into the comparable patterns this method needs