Offer timing and targeting rules
The previous article covered how to create automated and one-time offers. This article goes deeper on the mechanics — what the system is actually doing behind the scenes to decide when an offer appears, who sees it, and what happens at checkout when a patient has more than one active discount available.
Understanding these rules helps you time your offers deliberately, avoid gaps in coverage, and set patient expectations correctly.
How automated offer activation works
The 7-day pre-activation window
For calendar-based automated offers (Christmas, Black Friday, Mother's Day, and all other occasion-based triggers), the system checks daily whether an occasion is approaching. When the check runs and finds that an occasion is exactly 7 days away, it flips the offer to active in the patient app.
In practice: a patient who opens the Glovora app on 18 December will already see your Christmas offer in the Offers section, even though Christmas is still a week away. They do not need a push notification to discover it — the offer is simply there.
The 7-day lead is fixed and cannot be changed per offer. All calendar-based offers use the same 7-day activation window.
When the push notification fires
Activation and notification are two separate events.
| Event | When it happens |
|---|---|
| Offer appears in app | 7 days before the occasion |
| Push notification sent | On the day of the occasion itself |
A patient who has notifications enabled will receive the push on Christmas Day (25 December), not on 18 December when the offer appeared in the app. The push is the moment of "surprise" — the offer has been quietly available in the app for a week, but the notification creates the event-day experience.
When an offer deactivates
Each calendar-based automated offer has its own active duration, controlled by a durationDays value set per occasion. When the system's daily deactivation job runs, it calculates:
Expiration = occasion date + durationDays
When today reaches or passes that expiration date, the offer is switched off and removed from the patient app.
The full visibility window for a calendar-based automated offer is therefore:
| Phase | Timing |
|---|---|
| Offer appears in app | 7 days before the occasion |
| Push notification sent | On the day of the occasion |
| Offer deactivates | durationDays after the occasion |
Each occasion's duration is listed in the occasions table above. Here are two worked examples at opposite ends of the range:
Christmas (durationDays = 7)
- Appears in app: 18 December (7 days before)
- Push sent: 25 December
- Deactivates: 1 January (7 days after Christmas Day)
- Total visible: 15 days
Bonfire Night (durationDays = 1)
- Appears in app: 29 October (7 days before)
- Push sent: 5 November
- Deactivates: 6 November (1 day after)
- Total visible: 9 days
The year-boundary case is handled automatically — a Christmas offer that deactivates on 1 January is correctly processed even though the occasion (25 December) and expiration (1 January) fall in different calendar years.
If you want an offer to run longer than its standard window — for example, keeping a Boxing Day sale live through the new year — create a separate one-time offer with a manual From/Until date range. The automated offer system always uses the occasion's fixed durationDays and cannot be extended per-activation.
Birthday and anniversary triggers
Patient-based offers (Birthday Special and Client Anniversary) work differently from calendar offers. They fire individually for each patient based on their personal data:
Birthday Special
- The system checks every day whether any patient's date of birth matches today's date (day and month)
- If it matches, the offer activates for that patient and the push notification is sent to them directly
- If a patient has no date of birth on their profile, they are silently skipped — no offer, no notification
- The active window is 3 days (the day of the birthday and 2 days following)
Client Anniversary
- The system checks whether the anniversary of the patient's clinic join date falls on today (day and month)
- Every patient has a join date (set automatically when their profile is created), so no patients are skipped for missing data
- The active window is 3 days
Unlike calendar offers, birthday and anniversary notifications are personalised to the individual patient. The push notification title and body you configure (with {{patient_name}} and {{clinic_name}} placeholders) are resolved per patient before sending.
Birthday offers are silently skipped for any patient without a date of birth on their profile. They will not see the offer and will not receive a notification. Before enabling the Birthday Special automated offer, use the Missing DOB filter on the Client Profiles page to identify and follow up with any patients who have no date of birth recorded.
Who receives each type of offer
Calendar-based offers (broadcast)
When a calendar-based automated offer triggers its push notification, it is sent to all patients in your clinic who have the app installed and have permitted push notifications. Christmas, Black Friday, Mother's Day, and similar occasions are broadcast events — there is no filtering by patient segment, spend history, or membership status. Every patient in your database is a potential recipient.
The offer also becomes visible to any patient who opens the app during the active window, regardless of whether they received a push notification.
Patient-based offers (individual)
Birthday and anniversary offers are sent only to the specific patient whose occasion it is. On any given day, the system might send a birthday notification to three patients who share that birthday, or to none. Each patient receives their own personalised notification independently.
One-time offers (in-app or manual push)
One-time offers become visible to all patients in the app as soon as the offer is active (the Active toggle is on and the current date falls within the From/Until range). If you choose to send a push notification, it goes to all patients with the app installed and notifications permitted — the same broadcast behaviour as calendar-based offers.
There is currently no targeting by patient segment (for example, "only members" or "only patients who spent over £500 last year") for any offer type. All active offers are visible to all patients.
How Max Uses works for one-time offers
Per-patient enforcement
The Max Uses field on a one-time offer is intended to cap total redemptions. In the current implementation, the system enforces one redemption per patient per offer. Each time a patient redeems an offer, a record is stored against their account. If the same patient tries to redeem the same offer a second time, the system rejects it with an "already redeemed" error.
What happens when you set Max Uses
Setting Max Uses to a specific number (for example, 50) is a signal of intent: you want to limit how broadly the offer is used. The system does not currently hide the offer from all patients once a global redemption count is reached, but individual patients cannot redeem the same offer more than once.
For offers where the financial exposure matters — a generous fixed-amount discount or a free treatment — setting Max Uses provides a practical limit on how many individual patients can benefit from it.
When an offer is no longer redeemable
An offer stops being accessible to patients when any of the following occurs:
- The Until date has passed (one-time offers)
- The Active toggle is switched off manually
- The offer is unpublished
In all cases, the offer disappears from the patient app immediately. Any patient who had the offer card visible but had not yet tapped Redeem will find it gone on their next app open.
How the best discount wins at checkout
When a patient checks out with items in their cart, the system evaluates every discount source available to them and applies only the most beneficial one. Discounts do not stack.
The three discount sources
| Source | What qualifies |
|---|---|
| Active offer | An automated or one-time offer the patient has redeemed (tapped Redeem Offer in the app) |
| Loyalty reward | A loyalty reward the patient has redeemed (tapped Redeem in the Rewards section) |
| Membership discount | A percentage discount associated with the patient's active membership plan |
How the winner is determined
Each source is converted to an absolute pound value based on the current cart subtotal:
- Membership discount — the membership percentage is multiplied by the cart subtotal to get a pound saving (e.g. 10% membership on a £200 cart = £20 saving)
- Offer discount — if percentage-based, same calculation; if fixed amount, the fixed pound value is used directly
- Reward discount — same approach as offer: percentage converted to pounds, or fixed value taken directly
The system then picks the one that produces the largest absolute saving in pounds. This is a pure numerical comparison — there is no rule that membership always wins, or that offers always override membership.