Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt

Use this file to discover all available pages before exploring further.

Insights are the learnings your team has extracted from the journey. They are not yet the solution. They are not always yet the priority. They are the statement of what you believe, observed, or validated about the customer experience.

What an insight should answer

A strong insight answers one of these questions:
  • What is happening here?
  • Why are customers struggling?
  • What do customers need at this moment?
  • What is unexpectedly working well?

Insight types

Custory supports three insight types:
  • Pain
  • Need
  • Gain
Use:
  • Pain for friction, confusion, blockers, or drop-off
  • Need for missing expectations, required capability, or desired support
  • Gain for positive outcomes or successful patterns worth preserving
This distinction helps teams avoid treating every customer signal as negative.

Insight fields

Insights support:
  • Description
  • Status
  • Type
  • Confidence
  • Severity
  • Affected segment

Confidence

Confidence reflects how sure you are that the insight is true. Available values:
  • Low confidence
  • Medium confidence
  • High confidence
Use confidence to distinguish:
  • A founder intuition
  • A repeated support pattern
  • A clearly validated behavioral truth

Severity

Severity uses a 1 to 5 scale. Use it to describe how painful or consequential the issue is for the customer. Severity is about the customer’s experience, not your roadmap priority.

Affected segment

Use personas when the insight applies to a specific segment rather than all customers. This is especially useful in B2B products where the admin, buyer, and end user often experience different friction.

Insight statuses

Insights use these statuses:
  • New
  • Assumption
  • Observed
  • Validated
  • Archived
Recommended interpretation:
  • New: captured recently and not yet framed well
  • Assumption: plausible, but not yet supported strongly enough
  • Observed: seen in real signals or examples
  • Validated: strong enough to trust operationally
  • Archived: no longer relevant, superseded, or intentionally kept only for history

How insights should connect

Insights can link: That preserves the movement from customer moment to learning to action.

Good insight examples

  • New admins are unsure whether connecting Slack is required for value
  • Support contacts increase after failed payment emails
  • Buyers care more about team visibility than feature depth in demos
Weak insight examples:
  • Onboarding
  • Need better UX
  • Fix this
Those are too vague to guide decisions.

How to leverage insights well

Separate evidence from action

An insight should describe what the team learned. The opportunity comes later.

Use confidence and severity together

This helps smaller teams avoid overreacting to loud but weak evidence, or underreacting to high-severity issues that are already well supported.

Review assumptions regularly

Assumptions are not bad. Unreviewed assumptions are. Keep them visible until they are validated, reframed, or archived.

Common mistakes

Writing opportunities as insights

Improve onboarding clarity is an opportunity, not an insight.

Treating every support ticket as a validated insight

Raw signal matters, but one example is not always enough. Use confidence honestly.

Using generic language

Specific, concrete insights are easier to link, prioritize, and act on than broad statements about “friction.”