Anniversary, birthday, and reminders

Why ship the configuration UI before the runner that actually fires the automations?

Two reasons that point the same direction. First, the configuration is the harder design problem. Deciding which automations exist, what their triggers should be, how the days-before settings work, which templates plug in, and how operators think about turning them on or off — that's a UX surface that needs real-store-owner feedback to get right. Shipping it early without the runner behind it lets us learn what the actual interface should look like from operators using it manually alongside the /reminders surface. Second, capturing intent now means the runner can fire correctly from day one when it ships — a tenant who's configured Birthday Greeting today and starts seeing messages go out the day after the runner lands doesn't need to revisit anything. Operators who'd held off configuring because they couldn't see the surface yet would be late to activate.

The cost is the gap documented above — the toggle being on today is a record of intent, not a guarantee of execution. That cost is real, and is why the honest disclosure leads with it.

Why does the dashboard surface dates from a 30-day lookahead instead of just “this month”?

The forget-and-rush failure mode is the worst case. A customer's anniversary on the 5th of next month, surfaced on a strict-calendar-month view, wouldn't appear until the 1st — five days of lead time that's rarely enough to think about the piece, place an order, or set up a workshop window. A 30-day rolling window keeps the lead time consistent regardless of where in the calendar you are — a birthday on the 28th is visible from the 28th of the prior month onward, which is enough time to actually do something.

The trade-off is that the dashboard can read busy at the start of a month when all of the current month's dates AND the early-next-month dates are visible together. That's the right direction of error — too much lead time beats not enough.

Why is dismiss per-user instead of per-tenant?

Reminders are about staff-to-customer relationship workflows. The same upcoming birthday might prompt three different staff members to act in three different ways: the original-sale associate has a relationship and would call; the workshop manager wants to flag a piece ready for that anniversary; the owner wants to check the marketing-campaign segment is built. One of them dismissing the reminder shouldn't hide it from the other two — they have different roles in the response.

The other model — tenant-wide dismiss — would make the dashboard a shared inbox where one person's cleanup is everyone's cleanup. That works for a different shape of workflow (a single-thread support queue) but not for relationship-driven outreach. The dismiss-per-user choice keeps each staff member's view tuned to their own context.

How do reminders interact with the marketing campaign segments?

/reminders is for 1:1 in-context outreach; segments + campaigns are for batch outreach to a cohort. They share data but have different goals.

Concretely: the “Birthdays this month” KPI on the customer hub at /customers counts the same customers the /reminders dashboard surfaces individually. The segments page surfaces the same cohort under a “Birthday this month” segment so a campaign can target them all at once. Three views, one data source: the reminders dashboard is the operator workflow, the KPI is the hub orientation, the segment is the campaign target.

What happens to a customer's past birthday after it passes — do the previous-year dates clutter the dashboard?

No. The dashboard reads MM-DD across all stored years and compares against today + 30 days. A customer born on March 28, 1970 surfaces every March from late February (when March 28 falls within the 30-day window) and drops off March 29. The stored year doesn't affect the upcoming-in-30-days check at all — it's strictly the month and day that matter.

This means a customer with a known birthday but unknown year (entered with a sentinel like 1900) works identically to one with a real birth year. The dashboard reads them the same. The hero-card detail-page rendering of the birthday does show the year — see the related troubleshooting entry if a sentinel year is showing on the customer page in a way that's misleading.

Birthday Greeting automation is on but the customer didn't get an email on their birthday

Symptom: the toggle at /marketing/automations is on, the customer has a birthday on file, the date passed — but no email went out. Cause: expected today, documented in the honest disclosure section above. The execution loop that actually dispatches automated messages isn't wired up yet; toggle state is a record of intent, not a guarantee of execution. Fix: until the runner ships, the manual path is to act on the reminder from /reminders — open the customer, click Send email on the hero card, send the birthday message. Or build a Birthday segment in the campaigns surface and send the cohort all at once. Both leave a record on the customer's Communications tab.

A customer doesn't show on the birthdays panel even though their birthday is in two weeks

Symptom:a customer with a known birthday isn't surfacing on the Birthdays this month panel. Cause:three candidates. (1) The birthday field is empty on the customer record (more common than expected — especially on records that came in via web enquiry or sync, where intake forms don't always capture the date). (2) The customer has been dismissed by you on this dashboard. (3) The customer is soft-deleted. Fix:open the customer's detail page. If the Overview tab shows “Birthday: —”, edit the record and add the date. If the customer is soft-deleted, the dashboard correctly skips them. If the customer card is just hidden by a dismiss action, the dismissal is per-user — log out and back in to check, or use the dashboard's reset affordance (when implemented; today this requires support to clear the dismissal row).

Snooze didn't hide the reminder

Symptom: you snoozed a reminder for “1 week” and the card is still visible after refresh. Cause:two candidates. (1) The snooze didn't persist — network blip during the action. (2) Browser cache showing the pre-snooze render. Snooze writes to reminder_dismissals with a futuresnoozed_until timestamp, and the dashboard filter at load time skips any reminder whose key is in that table with a future snoozed_until. Fix:hard- refresh the page (Cmd+Shift+R) to bypass any cached payload. If the reminder still surfaces, re-snooze it (the action is idempotent — it'll re-write the row). If the issue repeats across dashboard loads, contact support with the customer / reminder ID.

Test run on a birthday automation returns 0 matches when I know I have birthdays this month

Symptom: the Test run affordance on the Birthday Greeting automation returns “0 customers would match today” but the /reminders dashboard shows birthdays this month. Cause: the two surfaces use different windows. /reminders shows a 30-day forward window. The test-run match count uses the configured days_before offset from today specifically — defaults to 0, meaning “match customers whose birthday is exactly today.” On a Tuesday with no birthdays falling exactly on Tuesday, the count is correctly 0 even though there are upcoming birthdays this month. Fix: if you want the automation to fire the configured number of days before the birthday, set days_before in the automation settings to the lead time you want (e.g. 7 to fire one week before). The match count then reflects customers who match “today + 7 days.”

The /reminders dashboard takes a long time to load for a large tenant

Symptom: the page renders slowly — multi-second wait before cards appear. Cause: the dashboard issues parallel fetches across tasks, repairs, bespoke jobs, laybys, and the full customer set (for the date filter). On tenants with tens of thousands of customers the client-side date filtering on customer rows dominates the load time. Fix: there's a planned migration toward a materialised view of upcoming customer dates that short-circuits the full customer-table read. If you're hitting this regularly on a large tenant, let us know — the priority of the materialised view depends on real tenant pain.