The notification is part of the product. Design each message together with the page it opens and the feedback after the member acts. Reviewed 11 September 2026.
This reference combines current app message code, five inspected live Klaviyo flow definitions, their actual attached templates, and a no-send template render. It does not claim inbox rendering, carrier delivery, or every external retail notification was tested.
flowchart TD
A["Member saves people"] --> B["Calendar-saved SMS"]
B --> C["Birthday enters reminder window"]
C --> D{"Available reminder channels"}
D --> E["SMS when opted in"]
D --> F["Email when an address exists"]
E --> G["Relevant birthday / gift review"]
F --> G
G --> H["Gift paid"]
G --> I["Skip year"]
G --> J["Prepare and hand off personal message"]
H --> K["Confirmation email"]
H --> L["Eligible first gift: card-in-box email to sender"]
I --> M["Skip acknowledgement email"]
F --> N["24 hours after initial reminder"]
E --> N
N --> O{"Live checks: no confirmation or skip"}
O --> P["Email follow-up if an email exists"]
Timing: the intended initial reminder is five days before the birthday. The scheduler source also catches up within the one-to-five-days-before window. The initial Klaviyo SMS uses quiet hours, so event creation is not a promise of an exact receipt time. SMS and email are parallel channels when both are available. The later follow-up is email-only.
Decision needing attention: the inspected follow-up flow checks for gift confirmation or skip, but not the app’s separate Birthday Message Sent event. The design and CRM logic need to agree about whether and when a personal-message decision stops a gift nudge.
| Moment / recipient | Channel and trigger | Message’s job | Destination / completion |
|---|---|---|---|
| C01 Sign-in code | |||
| Visitor/member | App → SMS when a code is requested. | Identify Fig & Bloom, present the code, explain ten-minute expiry and how to recover. | Return to the code field on start/sign-in/attach. Successful verification is separate from reminder consent. |
| C02 Calendar saved | |||
| New member saving their initial list | App → SMS after verified initial save, when the member has people on their calendar. | Confirm saved work and the chosen reminder arrangement; reinforce member control. | Member lands in the calendar. Current SMS has no calendar link. |
| C03 Birthday reminder | |||
| Member | App schedule → Klaviyo event → SMS when opted in, plus email when present. | Name the person, state the remaining time/date, and make an action easy. | Main CTA opens that person’s current gift-review route. Email product tiles can preselect a design. |
| C04 Reminder follow-up | |||
| Member with email | One day after the initial reminder, conditional on the configured no-confirm/no-skip checks. | Offer another useful chance to act without contradicting a completed decision. | Same person’s gift-review path. Uses an absolute delivery-date label in body copy. |
| C05 Gift confirmation | |||
| Sender | Klaviyo email immediately on Send Confirmed. Production source emits this after paid-order settlement; demo behaviour differs. | Reassure the sender about the booked gift and next steps. | Calendar CTA; distinguish confirmed/scheduled from dispatched/delivered. |
| C06 Skip acknowledgement | |||
| Member | Klaviyo email on Send Skipped. | Normalise the choice; explain that the birthday remains for next year. | Calendar and opt-out controls. Skipping a gift is not deleting the person or changing all reminders. |
| C07 Welcome card accompanies gift | |||
| Sender | Klaviyo email on Gift Card Issued for the eligible first paid gift. | Explain the AUD 25 card travelling with the gift. | The physical card later serves the recipient. This email is addressed to the sender, not the recipient. |
| C08 Wish list started | |||
| Member who requested it | Klaviyo email on first sharing/saving a wish list into that member’s link. | Say the person has supplied preferences and make them easy to find. | Person profile, via profile_url. This is an update, not a purchase or a promise to buy. |
| C09 Birthday/address/wish-list request | |||
| Person the member knows | Member → their own sharing app, or copied link. | Explain the personal request and why it is easy to answer. | Purpose-specific guest form. Guest saves first; joining is optional afterwards. |
| C10 Personal birthday greeting | |||
| Person having the birthday | Member → chosen app/conversation, using an edited draft. | Help the member sound like themselves. | The member sends. Birthday Club has no delivery confirmation. |
| C11 Invitation | |||
| Friend of a member | Member → share/copy invite link. | Explain the AUD 20 first-gift offer and why they might join. | Invite welcome → start list → verification. The inviter’s cash-back condition remains distinct. |
| C12 Physical greeting / welcome card | |||
| Gift recipient | Handwritten premium card with gift; eligible AUD 25 welcome card includes QR. | Deliver the personal message, then make the onward invitation understandable. | QR → recipient welcome → account/list creation. Already-claimed states must be clear. |
| C13 Legacy access/security notice | |||
| Existing account holder | App → email for eligible older sign-in links and sign-in changes. | Support account continuity and explain a consequential account change. | Sign-in/attach path or support. Keep distinct from promotional preferences. |
C01, C02 and C13 are app-owned message content. C03–C08 are the inspected Klaviyo flows. C09–C11 are prepared by the app but sent by the member. C12 is a physical touchpoint.
The names below are fictional. A code placeholder is not a usable code. These examples describe the current content, not a proposed final rewrite.
Fig & Bloom: your Birthday Club code is [code]. It expires in 10 minutes. Never share this code.
The source adds a domain-bound autofill line. Retain functional code/expiry/autofill requirements when polishing the text. Provide resend and number-correction affordances in the matching screen.
The message opens with “your Birthday Club calendar is saved”, gives a count, explains text/email reminders five days before each birthday, and closes with “Nothing sends until you say go.”
Content issue to resolve: the current count uses all saved people, including people whose date is unknown. “Birthdays covered” can overstate reminder readiness. Distinguish saved people from dates ready for reminders.
Fig & Bloom: Alex’s birthday is 5 days away. Pick their flowers in one tap — nothing sends until you confirm: [person-specific link] Reply STOP to opt out.