Marketing automations

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 lead-time 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 the configuration early without the runner behind it lets us learn what the interface should look like from operators configuring alongside the /reminders dashboard and the manual campaign path. Second, capturing intent now means the runner can fire correctly from day one when it ships — every toggle that's on the moment the runner lands starts firing, and tenants who configured early don't need to re-do the setup. Operators who held off configuring because the runner wasn't live 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 is Test run supported on Birthday and Anniversary but not on Re-engagement, Repair Ready, or Post-purchase?

Birthday and Anniversary are date-column matches against a single customers-table column — the matcher logic is one query against customers.birthday or customers.anniversary. Cheap, fast, and the count is meaningful as a dry preview.

The other automation types require cross-table joins. Repair Ready needs to read workshop_jobs with status = ready, joined back to customers, with collection-overdue filtering. Re-engagement needs to read the customer's most-recent interaction across several tables (sales, repairs, communications) to compute the inactivity threshold accurately. Post-purchase needs to read sales rows joined to customers within a recency window. These matchers are non-trivial enough that we ship them alongside the runner — wiring them up just for Test run ahead of the runner would duplicate work and risk the dry-preview number diverging from what the runner eventually computes. Honest count or no count; not an approximation.

Why two automation surfaces — /marketing/automations and /customers/automation?

Two different lenses on the same underlying marketing_automations rows. /marketing/automations leads with the automation-type perspective — “here are the event-triggered automations Nexpura recognises, and here's the template each will dispatch when fired.” /customers/automation leads with the customer-segment perspective — “here are your segments (VIP, Inactive, Birthday, New) and here are the automations that target them.” Same toggles under both, same persistence; each surface is optimised for the operator question that brought them there.

A staff member thinking “how do I touch my VIPs more?” lands on /customers/automation naturally and sees the relevant toggles in the context of the segment. A staff member thinking “does our birthday template look right before I turn it on?” lands on /marketing/automations and sees the template selection clearly. Both surfaces are honest about the execution-layer gap; whichever you land on, the picture of what fires today and what doesn't is the same.

Why are appointment reminders separate 24h and 1h automations instead of one with a configurable lead time?

Two different mental models. The 24h reminder is the “don't forget tomorrow” nudge — gentle, informational, useful for the customer to plan their day. The 1h reminder is the “you're about to be late” nudge — immediate, sometimes urgent, often paired with a contact-us-if-you-can't-make-it line. The two have different message shapes and tones; the templates that drive them are different in practice.

Collapsing them into one toggle with a lead-time picker would force one template to cover both tones — either too soft for the 1h send or too alarming for the 24h send. Keeping them separate lets stores configure each independently, with the right template per nudge, and turn one or both on as their customer base prefers.

Will the automation respect customer consent when it fires?

Yes. The runner will apply the channel-specific consent gate at dispatch time, the same way campaign sends do today — a customer who has opted out of marketing on the configured channel is skipped, and the skip is recorded so the automation's send stats reflect the intended-but-skipped count. Capturing intent today doesn't bypass the consent gate when the runner lands; the gate is a separate layer that fires regardless of whether the message originated from a campaign, a 1:1, or an automation.

The customer add / edit page has the consent fields; the customer detail page surfaces them in the Overview / Marketing-preferences section. Capturing consent accurately at intake is what keeps the eventual automation sends honest.

Automation is toggled on but customers aren't receiving the automated messages

Symptom: the toggle is on, customers definitely match the trigger (e.g. it's their birthday, or they've been inactive for 6+ months), but no message went out. Cause: expected today, documented in the honest disclosure section above. The cron runner that reads the marketing_automations table and dispatches messages doesn't yet exist; toggle state captures intent but doesn't guarantee execution. Fix:use the manual workaround paths in the honest disclosure section above — the right one depends on which automation. Birthday and anniversary go through /reminders or a Birthday-this-month campaign; re-engagement goes through the Inactive 90+ segment + a campaign; appointment reminders go through the appointment detail page's manual reminder send.

Test run returns 0 matches but I know I have birthdays coming up this month

Symptom: the Test run affordance on the Birthday Wishes 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.” This same troubleshooting entry exists on the anniversary and reminders page with the same fix.

Test run returns “Test run is not yet available for this automation type”

Symptom: the Test run button on Repair Ready, Re-engagement, Post-purchase, Appointment, or a seasonal type returns the unsupported message. Cause: expected. The matcher logic for these types requires cross-table joins (workshop_jobs for repair-ready, sales / interactions for re-engagement, appointments table for the appointment reminders). Wiring up matchers ahead of the runner would risk the dry-preview count diverging from what the runner eventually computes. Fix: no fix today — the test-run affordance for these types populates when the runner ships. Until then, the cohort estimation has to come from the corresponding manual surfaces (filter the workshop list by ready + overdue, run an Inactive 90+ segment count, filter the appointments calendar by the relevant window).

Template picker on an automation shows no templates for that type

Symptom:the configure panel's template picker shows an empty dropdown for the chosen automation type. Cause: the picker filters templates by template_type; if the only system template with that type was deleted (rare — system templates are locked) or the tenant hasn't duplicated one yet, the dropdown is empty. Fix: open /marketing/templates, find the matching system template (e.g. Birthday Wishes for the birthday automation), click Duplicate, save. The duplicate now appears in the automation's template picker. The automation falls back to the system template if no binding is selected and a system template exists; the picker showing empty means even the system version isn't resolving — contact support if duplicate-then-select doesn't recover.

Toggling an automation on returns “Only owner or manager can ...”

Symptom: a toggle action returns the permission-denied message inline. Cause: automation toggles fire customer-facing messages on your tenant's behalf — they're gated to owner / manager. Salesperson, workshop, and accountant roles can read the configuration but not modify it. Fix: ask an owner or manager to flip the toggle, or to elevate your role if your responsibilities have changed. Roles are managed under settings.