> 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/best-practices/designing-your-offer.md). # Designing Your Offer Once you have chosen a reward type, the offer is everything wrapped around it: whether you reward one side or both, what a referee has to do to qualify, and how long the reward stays valid. The short answer for most Shopify stores: run a **double-sided** offer, add a **minimum purchase requirement** only if you have a margin reason to, and give rewards a **gentle expiry** to create urgency without punishing genuine customers. This article explains those choices, then links the Bloop settings that apply them. The offer is where generosity meets guardrails. Too loose and you pay for low-value or abusive referrals; too strict and you suppress the shares you were trying to encourage. The goal is the lightest set of conditions that still protects your margin. ### Single-sided vs double-sided The first decision is who gets rewarded. | Offer shape | What it means | Best for | | ---------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------- | | Double-sided | Both the referrer and the referee get a reward | Almost every store — it gives the referrer something to talk about and the friend a reason to act | | Single-sided (referrer only) | Only the existing customer earns | Stores where the product sells itself and the friend needs no incentive | | Single-sided (referee only) | Only the new customer is discounted | Pure acquisition pushes where you are not trying to reward advocacy | Default to double-sided. A referrer-only offer asks customers to recommend you while their friend gets nothing, which makes the pitch awkward; a referee-only offer is really just a discount channel, not a referral program. The friend's reward matters more than it looks: it lets the referrer feel they are *giving* something their friend will appreciate rather than just cashing in — which is what makes people comfortable sharing. Frame it that way in your copy ("give your friend 20% off, get store credit when they buy"). In Bloop each side has its own **Reward status** toggle, so you can switch to single-sided by turning one off. ### Minimum requirements: only when margin demands it A minimum requirement decides what a referral must achieve before the referrer reward is issued. Bloop offers four options: none, minimum purchase amount, minimum quantity of items, and a minimum number of referees. * **None** is the right default. Every extra condition costs you some conversions, so add one only to solve a real problem. * **Minimum purchase amount** protects margin when a referee could otherwise claim a generous reward on a tiny order. Set it just above the point where the order becomes profitable. * **Minimum quantity of referees** rewards in cycles — at the 5th, 10th, 15th successful referee, for example — which suits programs aimed at a few high-output advocates rather than broad word of mouth. Between thresholds, a referrer on the minimum-referees option gets a "not enough referrals yet" notification instead of a reward, so be transparent about the rule in your messaging. ### Expiry: urgency without resentment Reward codes can be set to never expire or to lapse after a set number of days. A reward that never expires loses its nudge; one that expires too fast frustrates customers who were ready to buy. * For most stores, a valid period in the range of a few weeks creates useful urgency. * Bloop sends a reminder email before a code expires, so set the window long enough that the reminder has time to land and be acted on. * For high-ticket or considered purchases, lean toward a longer window — the decision itself takes time. ### Make it easy to say yes to Beyond the mechanics, an offer only works if a customer feels comfortable sharing it. A referral puts the referrer's reputation on the line, so the clearer the offer, the lower that social risk: state plainly what both sides get and what the friend has to do. Uncertainty — "what happens after I refer?" — is one of the biggest reasons customers who love you still don't share. Keep the conditions and the steps to a minimum too; every extra hoop or data field costs you shares. See [Referral methods](/referral-program/referral-methods.md) for how customers actually send the offer. ### Match the offer to who can refer Your offer and your audience rule work together. A wide-open audience paired with a rich, no-minimum reward is the combination most exposed to abuse; a tighter audience lets you be more generous safely. Decide the two together rather than in isolation — see [Set your referral target audience](/referral-program/target-audience.md) for the eligibility options. ### Set it up in Bloop * Apply the offer shape, minimums, and expiry in [Set up referrer and referee rewards](/referral-program/rewards.md). * Set who is allowed to refer in [Target audience](/referral-program/target-audience.md). * For ideas on structuring multi-step or milestone offers, see [multi-step referral rewards](https://bloop.plus/blog/multi-step-referral-rewards/). ### Related * [Best practices: choosing the right referral reward](/best-practices/choosing-rewards.md) * [Best practices: making your program visible](/best-practices/program-visibility.md) * [Refer-a-friend scheme ideas](https://bloop.plus/blog/refer-a-friend-scheme-ideas/) --- # 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/best-practices/designing-your-offer.md?ask=&goal= ``` `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.