> ## 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. # Items > Understand Custory items, the five item types, and how evidence turns into decisions, solutions, and measurement. 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](/building-blocks). 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. | Type | Use it for | Good example | Avoid | | ----------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------- | -------------------- | | Touchpoint | A customer-facing moment, surface, or interaction | `Workspace invite email` | `Activation` | | Insight | What the team learned from evidence | `Solo admins hesitate because they are not ready to invite teammates yet` | `Need better UX` | | Opportunity | A problem or leverage point worth acting on | `Reduce pressure at the teammate invite step` | `Add skip button` | | Solution | A candidate, planned, or shipped response | `Add a skip-and-return-later path` | `Improve onboarding` | | Metric | A number that shows whether the problem matters or the response worked | `Invite completion rate within 3 days` | `Growth` | 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](/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](/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 ```mermaid theme={null} flowchart LR S["Signal
Raw customer evidence"] --> T["Touchpoint
Where it happened"] T --> I["Insight
What the team learned"] I --> O["Opportunity
What is worth improving"] O --> U["Solution
What you will change"] O --> M["Metric
How you measure the problem"] U --> M2["Metric
How you validate the response"] ``` 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. | Type | Item | | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Signal | Several support chats and analytics drop-off show users stopping after the invite prompt | | Touchpoint | `Customer reaches the invite teammate step` | | Insight | `Solo admins hesitate because they are not ready to involve the team yet` | | Opportunity | `Reduce pressure at the teammate invite step` | | Solutions | `Add a skip-and-return-later path`; `Explain why inviting a teammate helps`; `Send a follow-up email instead of forcing the invite in-session` | | Metric | `Invite completion rate within 3 days` | 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](/item-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 Each item type should do a specific job. Use touchpoints for moments, insights for learnings, opportunities for problems worth solving, solutions for responses, and metrics for measurement. You can prioritize faster when the team can still see where the customer signal came from and how it turned into a proposed response. Use confidence and status honestly. One support thread can be a useful clue without becoming a validated pattern. That usually creates feature debate before the customer problem is clear. Frame the opportunity first when the team needs a durable decision. ## 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](/item-fields) when you need the field, attachment, comments, history, and relationship reference. Read [Prioritize with customer context](/prioritize-with-customer-context) when the team is ready to compare opportunities and choose what to work on next.