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.

Touchpoints are the places where the customer actually meets the product, team, or business. They are not internal workstreams. They are the moments the customer experiences.

​
What counts as a touchpoint

A touchpoint can be:
  • A page
  • A feature surface
  • An email
  • A support interaction
  • A sales conversation
  • A documentation step
If a customer can experience it, move through it, react to it, or get blocked by it, it is usually a touchpoint.

​
Why touchpoints matter

Touchpoints keep the journey grounded. Without them, teams jump too quickly into general statements such as “onboarding needs work” or “activation is weak.” Touchpoints force the map back to the actual moment where the experience happens. For smaller product-led teams, this is useful because it reduces vague debate. Instead of talking about “the problem area,” the team can point to the exact page, screen, email, or conversation.

​
When to create a touchpoint

Create a touchpoint when you want to document:
  • A meaningful moment in the customer flow
  • A surface where friction repeatedly appears
  • A specific interaction that generates evidence
  • A place where multiple personas behave differently

​
Touchpoint fields

Touchpoints support:
  • Description
  • Status
  • Channel
  • Actor

​
Channel

Use channel to classify where the touchpoint happens:
  • Website
  • App
  • Email
  • Sales call
  • Support
  • Docs
  • Store
  • Other

​
Actor

Use actor when the touchpoint depends on who is experiencing it. Example:
  • An admin sees setup complexity
  • An end user only sees the final invitation
  • A buyer experiences pricing and trust signals

​
Touchpoint statuses

Touchpoints use these statuses:
  • Exists
  • Suspected
  • Confirmed
  • Deprecated
Recommended interpretation:
  • Exists: the touchpoint is part of the journey as currently understood
  • Suspected: the team believes this moment exists or matters, but it needs confirmation
  • Confirmed: the touchpoint and its role are well supported
  • Deprecated: the touchpoint no longer reflects the current experience

​
How touchpoints should connect

Touchpoints link downstream to Insights. That is the intended move:
  • First identify where the experience happens
  • Then capture what the team learned from that moment

​
Strong touchpoint examples

  • Pricing page before signup
  • Workspace invite email
  • First-run setup wizard
  • Support conversation about failed billing
Weak touchpoint examples:
  • Growth
  • Activation
  • Product
Those are categories, not customer-facing moments.

​
Best practices

​
Use customer-visible language

Write the touchpoint the way the team would recognize it in the actual flow.

​
Keep touchpoints stable

Touchpoints should not change every week unless the product changed. If the learning changes, update the insight. If the surface changed, update the touchpoint. If the team learns something important from a support thread or onboarding step, connect that learning directly. This preserves the origin of the signal.

​
Common mistakes

​
Turning internal activity into touchpoints

Sprint planning or Support team review are not touchpoints. They may matter internally, but they are not part of the customer journey.

​
Creating a touchpoint for every tiny UI element

Touchpoints should be meaningful moments, not microscopic fragments. Choose a level of granularity the team can actually maintain.

​
Skipping touchpoints and starting with opportunities

That usually weakens the chain of reasoning. You can still prioritize, but you lose clarity on where the problem actually shows up.