> ## Documentation Index
> Fetch the complete documentation index at: https://help.lobyco.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Create an offer
> Configure an offer step by step, from its basics through to how it looks in the app.
This walks through each section of the offer form, in the order you meet it.
Not every field below appears in every environment. Which offer types, checkout types and content fields you see depends on what is enabled for your setup.
## 1. Basics
**Name** identifies the offer in the Lobyco Portal. Unique names aren't required, but a naming convention makes offers far easier to find later — for example `2024_week_42_CocaCola_20off`.
**Type** decides how the coupon behaves: where it is shown, and how a customer comes to have it. Most settings are the same across all types — the real difference is **allocation**.
| Allocation | What it means |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Direct – offer** | Coupons are allocated when the offer is created. Coupon validity matches the offer dates. |
| **Direct – two steps** | Coupons are allocated in a second step, and can be valid for a shorter period than the offer. |
| **Reward** | Another product — a game, a challenge, or an orchestration flow — allocates coupons inside this offer. Coupons can be valid for a shorter period than the offer. |
You only see the offer types enabled in your system. Custom types can be added to support scenarios such as showing offers with a different design, so your environment may include types not listed here.
**Standard offer types**
| Offer type | Description | Allocation | Activation |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ---------------------------- |
| App Coupon | General offer available to all customers. | Direct – offer | *Pre-activated* flag applies |
| Challenge | Offer used as a reward for a challenge. | Reward | *Pre-activated* flag applies |
| Game | Offer used as a reward for a game. | Reward | Always pre-activated |
| Member Offer | Offer allocated to a list of customers, with its own design in the app. | Direct – offer | *Pre-activated* flag applies |
| Personal Offer | Offer allocated dynamically based on purchase history. The offer is created first, then coupons are allocated in a second step. | Direct – two steps | Needs activation |
| Segmented App Offer | Offer segmented to a specific list of customers. | Direct – offer | Needs activation |
**Custom offer types**
| Offer type | Description | Allocation | Activation |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | ---------------------------- |
| External | Redeemed on a partner's side rather than yours — for example a fuel discount earned after shopping in a store. May or may not be shown in the app, but the integration happens on the partner's POS. | Direct – offer | *Pre-activated* flag applies |
| External Segmented | A segmented version of External. | Reward | *Pre-activated* flag applies |
| Base Bonus | A base percentage bonus on top of every purchase. More configurable than the standard base earn bonus — you can include or exclude products and categories and set stacking rules. Should always be pre-activated, and we recommend not showing it in the app as an offer card. | Direct – offer | *Pre-activated* flag applies |
| Gift | The default choice for orchestration. Allocated through business logic on the orchestration canvas. | Reward | *Pre-activated* flag applies |
| Liquor | Shown like an App Coupon, with additional legal notice. | Direct – offer | *Pre-activated* flag applies |
| Preferred Store | Available to customers based on their preferred store selection. Specific to the store and its audience. | Direct – offer | *Pre-activated* flag applies |
| Stickers Offer | Reward for a sticker campaign — customers collect stickers to exchange for rewards. | Reward | Always pre-activated |
| Fuel – Standard | A fuel discount, available to all customers and ready to use. | Direct – offer | *Pre-activated* flag applies |
| Fuel – Triggered | A triggered fuel discount, used as a game or challenge reward or in a custom orchestration flow. | Reward | *Pre-activated* flag applies |
**Deprecated types**
| Offer type | Use instead |
| ------------------- | --------------------------------------- |
| Stamp Card | Challenge |
| Voucher – Standard | Another offer type with a Bonus benefit |
| Voucher – Triggered | Another offer type with a Bonus benefit |
**Start date** and **End date** control when the offer is visible in the app — or, for reward types, when coupons can be allocated inside it. They are pre-filled from the parent campaign and can be narrowed.
* Start at 00:01 and end at 23:59, to avoid ambiguity for customers and make planning easier.
* Avoid start times in the past, even though past end dates are accepted.
* Inside a campaign, the offer's dates must sit within the campaign's dates. The campaign's own dates are shown beneath the fields.
**Pre-activated** lets a customer use the offer without activating it in the app. The *Activate* button doesn't appear, and the offer is redeemable at the POS straight away.
The **Pre-activated** toggle is shown and can be switched for all types, but currently only takes effect for App Offer, Liquor and Preferred Store.
**Display priority** orders this offer against other offers of the same type in the app. Where your app shows several offer types in one section, the sorting order across types is agreed during implementation.
**Sponsor** records who funded the offer — a store, supplier, chain or group — so the source of sponsorship can be reported on.
**Visibility before offer start date** shows the offer in the app ahead of time. The customer sees it locked, with the date it becomes activatable. Leave it blank and the offer appears at campaign start. Only available for offers with segmentation capabilities.
**Validity period of voucher** sets the offer's validity period. Only available for offers with triggered capabilities.
## 2. Choose a discount type
The discount type decides what the offer actually does — reduce the price of a product, reduce a basket total, or scale the benefit with quantity or spend. It also changes which fields appear beneath it.
There are seven. See the [Discount types reference](/business-documentation/activities/offers/discount-types-reference) for each one, the discount values it supports, its limits, and a worked example.
**Offer type** cannot be changed once an offer is active, so it is worth settling the discount model before the offer goes live.
## 3. Where the offer applies
### Location
Choose whether the offer is valid in **chains** or in **stores** — the two cannot be combined. Selecting one or more chains disables the store selector, and the other way round.
* Use the **up arrow** on the store field to upload a store list: CSV, one store ID per line.
* Once stores are selected, use the **down arrow** to download the current selection as CSV.
### Checkout types
Restrict the offer to particular checkout channels: **POS**, **Self-checkout**, **Scan & Pay** and **E-commerce**.
If none are selected, the offer applies to **all** checkout types. This field only appears when checkout types are configured for your environment.
## 4. Stacking and limits
This is where you decide how the offer behaves alongside other Lobyco offers. Store discounts are normally treated as starting prices and are always stacked.
**Allow other offers on top**
* **True** — other Lobyco offers *can* be applied over this one.
* **False** — other Lobyco offers *cannot* be applied over this one.
This is enabled by default, on the assumption that a product isn't part of several offers at once and that offers should be cumulative — for example a 10% basket coupon that should apply across all products, discounted or not.
**Stacking priority** sets the order in which offers are applied. Values run from 1 to 10 and default to 5, so every offer starts at medium priority and you can create higher- or lower-priority offers around it. Where two discounts share a priority, the one that expires first is applied — oldest start date, earliest end date.
**Example — a "best price" offer.** To make 50% off a product the final price, with nothing applied afterwards, set **Allow other offers on top** to **False** and **Stacking priority** to **1**. The offer is then always applied first, and no other offer reduces the price further.
**Apply on items**
* **Apply on all items** — applies whether or not a discount is already applied.
* **Apply only on discounted items** — applies only to items that are already discounted.
* **Apply only on non-discounted items** — applies only to items that are not already discounted.
Most of the time these three can be left at their defaults, which simply means a regular offer that may stack with others in any way.
### Redemption limit
The total number of transactions the coupon can be used on.
Changing the redemption limit on an offer that is already active does **not** affect coupons that have already been activated or redeemed.
### Discount amount limit
The maximum amount given as a discount by one coupon per redemption. Use 0, or leave it empty, for unlimited.
For Product and Basket discounts with a percentage off, where the redemption limit is more than 1, you can set this limit either **per redemption** or **across all redemptions**:
* **Per redemption** cannot be exceeded within a single transaction.
* **Across all redemptions** is shared across every redemption — once reached, later redemptions grant no discount.
**Across all redemptions** applies per *coupon*, not per *offer*. If a customer receives several coupons from the same offer, the limit applies to each coupon separately.
## 5. Content and branding
This section controls how the offer looks in the app. Some fields may not appear, as this part of the form supports customization.
| Field | What it does |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Offer title** | The name of the offer as shown in the app. |
| **Description** | Details about the offer — product information, terms and conditions, anything else the customer should read. |
| **Product brand** | Optional. The app's offer design has to be set up to show it. |
| **Image** | The product image shown in the app. JPG or PNG. There is no size limit, but keep images under about 300 KB so they load quickly. |
| **Image URL** | An alternative to uploading: point at an image already hosted publicly where the app can reach it. |
| **Discount label** | Optional discount tag in the app. The app's offer design has to be set up to show it. |
| **Unit of measure** | Optional. The app's offer design has to be set up to show it. |
| **Receipt display text** | Optional. Sent to the POS to be printed as the discount label on the customer's receipt. The integration has to be set up to use this value. |
Additional metadata fields can be added to the content section to customize the look and feel further — during implementation, or later on request.
## 6. Reuse and edit later
### Save as template
An offer can be flagged as a template and used as the starting point for new offers. The flag has no effect on the offer itself, and can be switched on and off at any time — including after the offer has expired.
A template keeps all of the original offer's properties **except** its start and end dates.
### Edit an active offer
An active offer can still be edited, with limits:
* **Offer type** cannot be changed once the offer is active.
* **Redemption limit**, **Start date** and **End date** should not be changed — the change will not take effect on coupons that are already activated or redeemed.