> ## 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.

# How Custory works

> Understand the Custory hierarchy and operating model: Workspace -> Journey -> Stage -> Step -> Item.

Custory keeps the customer journey, supporting evidence, and follow-up work in one place.

The product model is:

**Workspace -> Journey -> Stage -> Step -> Item**

Reusable items also live in [Building blocks](/building-blocks), the workspace repository. A journey placement can reference the same reusable item without copying it.

```mermaid theme={null}
flowchart LR
    A["Workspace<br/>One team, product, or area"] --> B["Journey<br/>One customer flow"]
    B --> C["Stage<br/>A broad phase"]
    C --> D["Step<br/>A customer moment"]
    D --> E["Item<br/>Evidence, decision, follow-up, or metric"]
```

## The hierarchy

### Workspace

A [workspace](/workspace) is the shared home for one team, product, product area, client, or business unit.

It contains members and roles, journeys, building blocks, personas, integrations, notifications, automations, and AI memory or MCP access.

### Journey

A [journey](/journeys) is one customer flow the team wants to understand or improve, such as onboarding, activation, trial to paid, support escalation, or renewal risk.

### Stage

A stage is a broad phase inside a journey, such as discovery, evaluation, setup, first value, or retention.

### Step

A step is a specific customer moment inside a stage.

Good step names are concrete:

* `Customer reads pricing page`
* `Customer connects Slack`
* `Customer invites teammate`

### Item

An [item](/items) is structured context attached to a step. Items hold touchpoints, insights, opportunities, solutions, and metrics.

Items are where the journey becomes useful for decisions instead of staying a static map.

## The operating loop

Custory is designed around a simple loop:

1. Customer signals appear in analytics, support, billing, research, or delivery work.
2. The team places the signal on the right journey step.
3. Items turn that signal into evidence, learning, decisions, and measurement.
4. Integrations and automations move follow-up into the tools where work happens.
5. Results and shipped changes update the journey again.

```mermaid theme={null}
flowchart LR
    S["Signals<br/>Analytics, support, billing, research"] --> J["Journey<br/>Place the context"]
    J --> I["Items<br/>Structure the evidence"]
    I --> W["Work<br/>Prioritize, automate, ship"]
    W --> R["Results<br/>Update the journey"]
```

## Where each part helps

| Part            | Use it for                                                              |
| --------------- | ----------------------------------------------------------------------- |
| Journeys        | Mapping and maintaining the customer flow                               |
| Items           | Capturing evidence, decisions, responses, and metrics                   |
| Building blocks | Reusing canonical items across journeys                                 |
| Personas        | Interpreting the journey from the right customer role                   |
| Integrations    | Pulling evidence in and pushing follow-up out                           |
| Automations     | Handling repeated updates, messages, and task creation                  |
| AI              | Summarizing, drafting, and maintaining context from real workspace data |

## Example

A trial-to-paid journey might use this structure:

* Workspace: `Acme product team`
* Journey: `Trial to paid`
* Stage: `Setup`
* Step: `Customer connects first integration`
* Item: `Insight about non-technical admins stalling at API credentials`

That item can then link to an opportunity, solution, metric, and delivery task without losing the customer moment that created the work.

## Next step

Read [Quickstart](/quickstart) if you are setting up the workspace now. Read [Items](/items) for the full item model.