Intent clustering
Intent clustering is the work of looking at qualitative data about users (interview transcripts, support tickets, freeform survey responses) and grouping it by what users are actually trying to do. The hard part is finding the right level of generality: "taking an Uber to a wedding" is too specific to design around, "getting transportation" is too general to mean anything, but "attending a formal event" is closer to the level where a useful cluster lives. The output is a candidate set of categories that still has to be tested before anyone treats it as settled.
Definition
The activity of identifying user-intent categories from qualitative data — taking raw responses, observations, and examples, and proposing typologies of how those intents distribute across a user base.
The three operations
Three operations run inside the activity:
- Pattern recognition — reading the data for what's there before naming it. Recurring situations, framings, and contexts that show up across multiple respondents.
- Altitude-finding — choosing the right level of generality. Specific enough to design around, general enough to capture a meaningful cluster. "Uber to a wedding" abstracted to "attending a formal event" is altitude done well; "needs transportation" is too general to discriminate; "Uber to her cousin's Saturday wedding in Brooklyn" is too specific to recur.
- Typology proposal — naming the candidate categories the data suggests, so the clusters can be referenced and acted on by name.
Methods that feed it
Three methods produce data that clustering operates on:
- Email inquiry — an open-ended email to recent customers asking what they were trying to accomplish. Replies are the data.
- Situation explorer — a worksheet for structuring qualitative interviews about the user's transition, with the sought-state column filled in first.
- Starting-churn CS ticket pattern analysis — pattern-clustering across support tickets filed by users while they were still inside their early-period window.
Different methods produce different data shapes; the clustering activity itself is the same in each case.
Validation runs separately
The direct output of intent clustering is a candidate typology — clusters the analyst thinks they see in the data. Re-sort validation is the operation that tests the typology by reassigning every original response to its best-fit cluster and reading the column totals. Clusters that absorb everything, clusters that absorb nothing, and responses that don't fit any cluster all surface typology problems. Without re-sort, the typology is what the analyst remembers seeing; with re-sort, it's a typology the raw data demonstrably supports.
What validated typologies feed
Once validated, the typology becomes input to:
- Sorting hat design — the clusters become the categories the runtime instrument routes users into.
- Intent-mix fit — the cluster set is the theorized distribution of intents the offering serves; deployed apparatus generates ongoing drift signal against it.
- Path-investment decisions — which clusters get their own designed-for path and which route to the OSFA default.
Example
An analytics tool sends an email inquiry to its signup cohort asking what brought them here. Eighty replies come back into a spreadsheet. Reading across them surfaces recurring framings — some users describe a recent product launch, some describe a specific funnel they suspect is leaking, some are migrating off a competitor, some are setting up tracking for the first time. Altitude-finding picks the level: "post-launch validation" groups several launch-adjacent framings together; "first-time instrumentation" stays separate because the underlying situation is structurally different. The proposed typology — post-launch validation, diagnose-known-leak, competitor migration, first-time instrumentation — then goes into re-sort validation against the eighty replies. Clusters that absorb cleanly survive; clusters that don't get split, dropped, or renamed.