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.

Journey templates help you start with a useful structure when you know the shape of the problem but do not want to begin from a blank page. For startup teams, templates are most valuable when the team needs momentum more than originality.

When to use a template

Use a template when:
  • You want a faster first draft
  • The team is still learning how to structure journeys well
  • You have a familiar operating problem but not a finished journey map yet
Templates are especially useful when the work is still broad enough that you need scaffolding, but not so source-heavy that AI import is the better option.

When not to use a template

Do not start from a template when:
  • You already have strong source material in GitHub, Notion, or Figma
  • The journey structure is highly specific to your product
  • You want to map a narrow, unusual workflow from real evidence first
In those cases, use AI journey imports or start blank.

How to start from a template

From the dashboard:
  1. Open the journey creation flow
  2. Choose Use a template
  3. Review the template library
  4. Pick the closest match
  5. Open the new journey and adapt it immediately
The template gives you the structure. Your team still needs to make it true.

Current template library

Custory currently includes templates such as:
  • SaaS onboarding performance Best when you want to map signup, setup, activation, and first value.
  • Retention and churn risk journey Best when the team needs to surface renewal risk and pre-churn signals earlier.
  • Feedback to prioritized roadmap Best when customer signal is scattered and the team needs clearer opportunities and prioritization.
  • Product-led conversion journey Best when trial behavior, upgrade friction, and buying intent matter more than enterprise sales motion.
  • VOC to product action loop Best when support, CS, and product need to turn recurring feedback into owned work.
  • Founder customer loop Best when a founder-led discovery process needs to become a repeatable team workflow.
  • Research repository to journey system Best when insight already exists across docs, boards, and design files but is not yet operational.
  • Experience quality redesign Best when redesign work needs to stay tied to customer friction instead of drifting into aesthetics-only discussion.
  • Support volume reduction journey Best when you need to connect repeated support demand to product or content fixes.
  • Expansion and account growth journey Best when adoption, stakeholder alignment, and expansion signals need to be visible in one map.

How to choose the right template

Pick the template that matches the operating problem, not just the industry label. Ask:
  • What decision should this journey help us make?
  • What kind of customer motion are we trying to understand?
  • Which team will use this map every week?
For example, a startup may be in SaaS, but still benefit more from Feedback to prioritized roadmap than from Product-led conversion journey if the real bottleneck is signal-to-prioritization, not conversion.

What to change first after creating a template

Do these edits before you invite the rest of the team into the map:
  1. Rename the journey to match your product language
  2. Remove stages that do not apply
  3. Rewrite vague steps from the customer point of view
  4. Add the first real items and evidence
  5. Link the right persona if one matters
If you skip this pass, the template can feel polished without becoming useful.

Template workflow for founder-led teams

A practical pattern:
  1. Start from a template
  2. Spend 20 to 30 minutes trimming it to the real workflow
  3. Add 5 to 10 real items from support, product, or founder conversations
  4. Run the first team review from that version
That gives the team a structure they can react to without forcing them to maintain a generic artifact.

Common mistakes

Treating the template as the final answer

Templates speed up setup. They do not replace product understanding.

Keeping irrelevant stages because they “look complete”

If a section does not help your team make decisions, delete it.

Picking the broadest template

The closer the template is to the actual operating problem, the less cleanup you will need.