> For the complete documentation index, see [llms.txt](https://docs.bloop.plus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloop.plus/getting-started/the-referral-journey.md).

# The Referral Journey

The path a referrer and their friend take from share to reward.

The referral journey is the path two people take through your program: an existing customer (the **referrer**) shares a personal link or code, and a friend (the **referee**) uses it to claim a discount, buys, and earns the referrer their reward. Understanding this journey from both sides helps you design an offer that people actually want to share — and helps you read your dashboard, because every metric you see maps to a step below.

This page describes the experience, not the configuration. It does not tell you which buttons to press; it shows what your customers see and feel at each stage, so the settings in the feature docs have a purpose behind them. For setup, see [Getting started with referrals](/quick-start/getting-started.md).

The whole thing in four beats — note that the friend is rewarded when they buy, while the referrer is rewarded afterwards, once the order is paid:

```mermaid
flowchart LR
    A["Your customer shares<br/>a link or a code"]
    B["Their friend buys<br/>with a discount"]
    C["The order is paid,<br/>and you approve"]
    D["Your customer<br/>gets their reward"]
    A --> B --> C --> D
    D -. "the friend can now share too" .-> A
```

The six steps below expand each beat.

### The two people in every referral

* The **referrer** is a customer who already bought from you. They have a unique 8-character share code and want a reward worth the small social risk of recommending you.
* The **referee** is the friend they invite — someone who trusts the referrer and is deciding whether to try you for the first time.

A successful journey leaves both better off: the referee gets a discount on something they were already curious about, and the referrer is thanked for the introduction. That mutual win is the whole point of a two-sided reward.

### Step 1 — The referrer discovers they can share

After a purchase (and depending on the [target audience](/referral-program/target-audience.md) you allow), the customer sees an invitation to refer friends — on a post-purchase screen, in their account, in an email, or through your storefront widget. The message is simple: *give your friends a discount, get a reward when they buy.* This is where a clear, generous offer earns its keep; a confusing one is scrolled past.

### Step 2 — The referrer shares a link or code

The referrer passes along their personal **referral link** or **referral code**. Where they share depends on how they talk about you — a link works for email, chat, and social posts; a short code works for word-of-mouth and offline conversations. Whichever method they choose, the share carries their unique code so Bloop can credit the right person later. See [Choose a referral sharing method](/referral-program/referral-methods.md) for what each method suits.

### Step 3 — The referee arrives and claims a discount

How the friend claims their discount depends on which method the referrer used. A **referral link** brings them to your store, where they enter their email address and the discount is sent to them — that extra step is also what captures an address you can follow up on. A **referral code** skips it entirely: they type the code at checkout. See [Choose a referral sharing method](/referral-program/referral-methods.md) for the trade-off between the two.

Either way, what they receive is the **referee reward** you defined as the friend's side of your [rewards setup](/referral-program/rewards.md) — typically a discount on a first order. It lowers the barrier to trying you: the friend arrives with both a trusted recommendation and a reason to act now.

### Step 4 — The referee makes a qualifying purchase

When the referee completes an order that meets your conditions, the referral becomes successful. This is the moment that matters: **nothing is rewarded for a share alone** — only a real, qualifying purchase counts. If you set minimum requirements (a minimum order value, a number of items, or a number of referees), the order has to clear them. The new order is recorded so you can see it in [referral orders](/referral-program/management/orders.md).

### Step 5 — The referrer earns their reward

Once the referee's purchase qualifies, the **referrer reward** is issued — a discount code, store credit, cash, a free product, or something custom you fulfil yourself. If you set a review period, there is a short delay before approval; orders flagged as suspicious are held for 14 days for a closer look. The referrer is notified by email, and the reward waits for them on their [referral hub](/referral-program/referral-hub.md) alongside everything else they've earned.

Every reward moves through the same states, and this is the map to reach for when a referrer asks where theirs is. Cash rewards carry on past **Reward sent** into a payout queue, which you settle in [referral orders](/referral-program/management/orders.md).

```mermaid
stateDiagram-v2
    state "Reward sent" as Sent
    state "Reward declined" as Declined
    [*] --> Pending: the referee's order is paid
    Pending --> Suspicious: a fraud check flags it
    Pending --> Sent: the review period ends
    Pending --> Declined: you reject it
    Suspicious --> Sent: you approve, or the 14-day hold lapses
    Suspicious --> Declined: you reject the case
    Sent --> Used: the referrer redeems it
    Sent --> Expired: the code reaches its expiry
    Sent --> Revoked: the order is cancelled or fully refunded
```

> **Best practice:** The faster and clearer the thank-you, the more likely a referrer shares again. A reward that arrives promptly with a friendly note turns a one-time advocate into a repeat one. Tune the timing in the reward review period and the message in your [referral emails](/referral-program/emails.md).

### Step 6 — The referee becomes a referrer

The journey is a loop, not a line. The referee who just bought is now an existing customer — and can be invited to refer their own friends, starting the cycle again. A program that makes step 1 feel natural for every new customer is what turns a single referral into compounding word-of-mouth growth.

### How the journey shows up in your dashboard

Each step leaves a trace you can monitor: shares and clicks, referee orders, issued rewards, and the revenue behind them. Reading these together tells you where the journey stalls — lots of shares but few purchases points to a weak referee offer; few shares points to a weak referrer reward or poor placement. Follow the numbers in [referral analytics](/referral-program/analytics.md) and the chronological record in the [activity log](/referral-program/analytics/activity.md).

### Where to go next

* Set the rewards behind steps 3 and 5 in [Set up referrer and referee rewards](/referral-program/rewards.md).
* Decide how sharing happens in step 2 with [Choose a referral sharing method](/referral-program/referral-methods.md).
* See the partner equivalent in [The affiliate journey](/getting-started/the-affiliate-journey.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.bloop.plus/getting-started/the-referral-journey.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.