Items

Use this page when you need the whole item model in one place: what an item is, which type to use, how item types connect, and how to manage them on a journey. Items are how your team turns a customer journey from a diagram into working context. Stages and steps show where the customer is. Items explain what happens there, what the team learned, what is worth improving, what you plan to change, and how you will measure progress.

​

What an item is

An item is a structured record attached to a journey step or saved as a reusable building block. Use items for:

• customer-facing moments
• learnings from evidence
• problems worth solving
• candidate or shipped responses
• metrics that show whether the work helped

Items can live in two ways:

• On a journey - placed on a specific stage and step
• In building blocks - maintained as a reusable workspace record and attached to one or more journeys

When an item is reused, removing it from one journey is different from deleting it from the repository. Use Delete from journey when the placement should go away but the reusable item should stay available elsewhere.

​

Item types

Custory supports five main item types. The distinction matters because each type answers a different question:

• Touchpoint: Where does this happen?
• Insight: What did we learn?
• Opportunity: What should we improve?
• Solution: What will we try, build, change, or ship?
• Metric: How will we know whether it matters or worked?

​

Touchpoints

A touchpoint is a customer-visible moment in the journey, such as a page, email, support chat, sales conversation, feature surface, or documentation step. Create a touchpoint when you want to document:

• a meaningful customer moment
• a surface where friction repeatedly appears
• a specific interaction that generates evidence
• a place where different personas behave differently

Touchpoints can use Channel, Actor, and Status. Common channels include website, app, email, sales call, support, docs, store, and other. Use Actor when the same moment feels different for a buyer, admin, or end user. Touchpoint statuses are:

• Exists
• Suspected
• Confirmed
• Deprecated

Touchpoints have dedicated cards in grid view. Open the Touchpoints tab in a journey or in building blocks to scan them visually. Cards can show a preview image from an attachment, external link, or link card, plus title, description, channel, status, actor, and placement. Add screenshot of touchpoint cards in grid view here Touchpoint previews use the best available visual context:

1. an image attachment on the item
2. a preview image from an external link
3. a link card with host, title, and description
4. a fallback state when no preview exists

Use customer-visible language. Workspace invite email is stronger than Activation, because the team can find and discuss the exact moment.

​

Insights

An insight is what your team learned from the evidence. It describes what is happening, why customers are getting stuck, what a customer needs, or what is working better than expected. Create an insight when the team can say a clear sentence after looking at evidence. Insight types are:

• Pain for friction, confusion, blockers, or drop-off
• Need for missing expectations, support, or capability
• Gain for positive outcomes or patterns worth preserving

Insights usually use confidence, severity, and affected segment. Use Confidence to separate an early clue from a repeated pattern. Use Severity for the size of the customer pain or consequence, not roadmap priority. Use affected segment or personas when the learning applies to one customer group more than another. Insight statuses are:

• New
• Assumption
• Observed
• Validated
• Archived

Good insight titles name the learning:

• 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

If the item already sounds like the problem to prioritize, it is probably an opportunity. If it sounds like the answer, it is probably a solution.

​

Opportunities

An opportunity is the problem or leverage point your team may want to act on. It sits between the learning and the response: more concrete than an insight, but still problem-led rather than solution-led. Create an opportunity when a learning is ready to be compared, prioritized, assigned, or connected to follow-through. Opportunities usually use:

• owner
• impact
• effort
• priority
• confidence

Use Impact for the upside if the opportunity is addressed well. Use Effort for the likely cost or complexity across product, engineering, design, support, or operations. Use Priority after comparison, not as a default label on every new item. Opportunity statuses are:

• New
• Framed
• Prioritized
• Parked
• Closed

Good opportunities describe the problem:

• Reduce confusion before first integration
• Shorten the time between signup and first teammate invite
• Clarify billing recovery after failed payment

Avoid solution-shaped opportunity titles such as Build setup wizard, Add button, or Rewrite docs.

​

Solutions

A solution is the response your team wants to try, ship, or validate. It can be a product change, experiment, process change, content update, or service intervention. Create a solution when the team has a candidate or committed response to an opportunity. Solution types are:

• Idea
• Experiment
• Feature
• Process
• Content
• Service

Solutions usually use owner, solution type, impact, effort, priority, and target date. Use target date only when the solution has a real planning horizon. Solution statuses are:

• Idea
• Proposed
• Planned
• In progress
• Shipped
• Validated
• Rejected

Shipped is not the same as Worked. Link the solution to a metric when possible so the team can review whether the response changed the outcome.

​

Metrics

A metric is a number attached to an opportunity or solution. It helps the team understand whether a problem matters, whether it is getting better, and whether a shipped response worked. Metrics can stay manual or pull live values from PostHog or Stripe. Use a metric when:

• an opportunity needs evidence of size or urgency
• a solution needs a success measure
• the team wants a reusable outcome visible across journeys

Metrics usually use metric type, unit, baseline, current, target, and direction. Use:

• Customer for experience outcomes such as activation rate or time to first value
• Business for commercial outcomes such as trial-to-paid conversion or refunds
• Operational for internal execution signals such as response time or backlog age

Metric statuses are:

• Draft
• Defined
• Active
• Broken
• Deprecated

Read Metrics for live data setup, PostHog and Stripe configuration, sync behavior, thresholds, limitations, and troubleshooting.

​

How item types connect

The item model preserves the path from evidence to action. Allowed relationships are:

• Touchpoint -> Insight
• Insight -> Opportunity
• Opportunity -> Solution
• Opportunity -> Metric
• Solution -> Metric

This model is intentional. Custory helps you preserve causality, not create an unrestricted graph where every record links to everything.

​

Connected example

A B2B SaaS team sees trial users stall during setup. The touchpoint keeps the team grounded in the moment. The insight captures the learning. The opportunity frames the problem. The solutions show possible responses. The metric tells the team whether the response helped.

​

Create an item

You can create an item from a journey or from building blocks. From a journey:

1. Open the journey step where the item belongs.
2. Click Add item.
3. Choose the item type.
4. Give it a concrete title.
5. Fill only the fields the team will actually use.
6. Save it and link related items when the relationship matters.

From building blocks:

1. Open Building blocks.
2. Choose the relevant tab.
3. Create the item once as a reusable record.
4. Attach it to each journey step where it belongs.

Use building blocks when the same touchpoint, insight, opportunity, solution, or metric should appear in more than one journey.

​

Link items

Link items when the relationship changes a decision, clarifies reasoning, or makes review easier. The cleanest pattern is:

1. Link a touchpoint to the insight it produced.
2. Link the insight to the opportunity it creates.
3. Link the opportunity to one or more possible solutions.
4. Link the opportunity or solution to the metric that defines success.

Avoid linking everything to everything. Too many weak links make the chain harder to trust.

​

Edit an item

Open an item when the title and basic fields are not enough. Items open as dedicated records with readable slug-based URLs, such as /{workspaceSlug}/metrics/activation-rate in building blocks or /{workspaceSlug}/journey/onboarding?item=activation-rate when focused inside a journey. Old ID-based links still resolve, so shared bookmarks keep working after renames. Item details can include:

• description
• status and type-specific fields
• files and attachments
• image gallery
• external links with context
• comments and @ mentions
• linked items
• linked external tasks
• item history
• pending AI-related activity

Read Item details and fields for the practical field, attachment, comments, relationship, history, and permissions reference.

​

Remove an item

Use the lighter delete option unless you are sure the source item is no longer useful.

• Delete from journey removes the item placement from that journey and keeps the reusable building block.
• Delete from repository removes the shared record from the workspace.
• Delete journey removes the map but can keep reusable blocks.
• Delete journey and items removes the map and deletes the items too.

​

Common mistakes

​

What good looks like

A healthy item system lets the team answer:

• what happened
• where it happened
• what the team learned
• what problem is worth acting on
• what response is proposed or shipped
• how success will be measured

​

Next step

Read Item details and fields when you need the field, attachment, comments, history, and relationship reference. Read Prioritize with customer context when the team is ready to compare opportunities and choose what to work on next.