Clienteling workflow

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

Two different lenses on the same underlying configuration. /customers/automation leads with the customer-segment perspective — “here are your segments (VIP, Inactive, Birthday, New) and here are the automations that target them.” /marketing/automations leads with the channel / template perspective — “here are the automations, and here's the template each one will dispatch when fired.” Same toggles under both, same persistence, but 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 the automation on?” lands on /marketing/automations and sees the template selection clearly. Both surfaces are honest about the execution gap; whichever surface you land on, you get the same picture of what fires today and what doesn't.

Why is VIP a free-form tag instead of a separate tier system (Gold / Platinum / Diamond clienteling)?

Resisting the urge to over-engineer the relationship taxonomy. Most stores end up with one meaningful tier — “the people we genuinely prioritise” — and a long tail of customers who don't need a finer distinction. A three-or-four-tier system invites every store to spend a week categorising their book and then never use the tiers again. One tier (VIP, present- or-absent) keeps the operational decision sharp: this customer gets the relationship effort, or they don't.

For stores that genuinely want finer-grained tiers, the tags array is unlimited — add “VVIP” or “Tier-1” or “Founders-Circle” as additional free- form tags, and they show up in the filter and segments surfaces. The system doesn't prevent the finer breakdown; it just doesn't default to one. Loyalty tiers (Bronze / Silver / Gold / Platinum) are a separate axis driven by points balance, not by relationship judgement — useful for entirely different reasons.

Why does the 1:1 email surface record to the customer's Communications tab when marketing campaigns also record there?

Touchpoint completeness. The point of the Communications tab is that any staff member opening a customer can see every outbound message they've received from your store, regardless of which surface dispatched it. A staff member preparing for a customer phone call wants to see “we sent her the new-arrivals campaign last Tuesday AND a follow-up 1:1 from Mark on Friday” — the two touchpoints together are the conversation context, not separately.

If 1:1 sends and campaigns recorded to different surfaces, the natural mistake is to send the same customer the same content twice — “I see no record of us emailing her about this, let me send it now” when actually the campaign covered it last week. One Communications tab, every outbound record, no missed history.

How do I find customers who've gone quiet today, instead of waiting for the re-engagement automation to ship?

The Inactive 90+ days segment on /marketing/segments is the manual equivalent. The cohort is dynamically calculated — customers without an update timestamp in the last 90 days — and renders with a count beside it. From the segment, you can run a one-time campaign at the cohort (the campaigns builder accepts a segment ID as a target), or open the segment's member list and touch customers individually.

The same shape of work the automation would do when it ships, run by hand. The campaign send records on each customer's Communications tab the same way the automated send eventually will, so when the runner lands you've already built the touchpoint history.

How do I know my staff aren't triple-touching a VIP across the campaigns and the 1:1 surface?

Open the customer's detail page and read the Communications tab. Every outbound message — campaign, 1:1, repair-ready notification, invoice receipt, etc. — surfaces chronologically with the type labelled clearly. If you see three sends to the same customer in the same week, that's either valid (three different contexts that happened to fall together) or a redundant touch your team should know about.

There's no automatic deduplication or cooldown today — the system trusts that staff are reading the Communications tab before composing a touch. An explicit cooldown / dedup affordance (e.g. “this customer has received 3 messages this week, are you sure you want to send a fourth?”) is on the backlog and would slot in alongside the automation execution loop work, since the same friction is more relevant the moment automation fires alongside manual touches.

VIP segment shows zero customers but my list is full of VIPs

Symptom:the segments page's VIP cohort reads 0, but the customer list shows multiple customers with the VIP badge. Cause: the segment filter reads the is_vip column, not the tags array. If customers were tagged via a CSV import or a direct DB write that set the tag but not the column, the badge renders (the detail page reads either source) but the column is false, so the segment misses them. Fix: re-save each customer through the edit form to sync the column — deselect the VIP chip, save, re-select, save. For many customers, ask support to run a one-line update that flips is_vip to true wherever the tags array contains VIP across the tenant.

Re-engagement automation is toggled on but no lapsed-customer emails are going out

Symptom: the Re-engagement (Lapsed) toggle is on, customers have definitely crossed the 90-day inactive threshold, but no automated email has gone out. Cause: expected today, documented in the honest disclosure section above. The cron runner that reads the automation toggles and dispatches messages isn't wired up yet; toggle state captures intent but doesn't guarantee execution. Fix:until the runner ships, build a campaign on /marketing/segments targeting the Inactive 90+ days cohort and send it manually. The campaign records to each customer's Communications tab the same way the eventual automated send will.

1:1 email send modal returns “Email provider returned an unexpected response”

Symptom: the send action returns the generic provider-error message rather than a confirmed send. Cause:the email-send code path is deliberately strict: it only displays “Sent” when the provider returns an unambiguous success. If the provider returns an ambiguous response, the modal shows the error rather than silently claiming success. Fix:retry the send (the action is safe to retry — duplicate sends are rare and not catastrophic). If the error repeats, check the customer's email for validity (some providers reject emails with recently-bounced flags); if all else fails, contact support with the customer ID and the approximate send time so we can audit the provider log.

Send email button is missing on a customer's hero card

Symptom: the customer has an email on file but the Send email button doesn't render beside it. Cause: three possibilities. (1) Your role lacks the edit_customer permission — the button is gated. (2) The page is in review / read-only mode. (3) The customer's email field is empty (no address to send to — button conditionally hides). Fix: for (1), ask owner / manager to grant the permission via the role matrix. For (2), open the page without the review token. For (3), add the email via the edit form.

Notes timeline shows a colleague's note I want to delete

Symptom: there's a note on a customer written by another staff member, and you don't see a delete affordance on it. Cause:the notes timeline gates edit and delete on author-or-admin. Staff members can edit / delete their own notes; owners and managers can edit / delete any note. If you're a non-admin staff member, you can only modify your own entries. Fix: ask the author to remove their own note, or ask an owner / manager to remove it on your behalf. If the note carries genuinely sensitive content that needs immediate removal (an accidental PII disclosure, a customer-confidential remark mis- recorded), contact support — we can soft-delete the note server-side and log the change in the audit trail.