Browse documentation
Support automations
Small, explicit support rules with durable runs and visible outcomes.
Three conversation triggers
Create up to ten rules per app for the first customer message, a check for no operator reply, or a resolved conversation. Each rule starts disabled and sends one clearly labelled support text reply when explicitly enabled. Delay, UTC quiet hours and once/daily frequency settings are bounded. Promotional cards, billing-triggered messages and AI sending are outside this rule engine.
Preview before enabling
Preview a rule against an authorized conversation before enabling it. The preview is read-only; it shows eligibility, a reason and planned time. Activity records scheduled, sent, skipped and failed work separately. A local PostgreSQL development profile retains its separate read-only template preview.
Rechecked at delivery
Canonical conversation events create versioned durable jobs. Before sending, a leased worker checks current rule version, permissions, customer block/deletion and opt-out state, conversation activity, timing and frequency. Notes do not count as human replies. Disabled, outdated or ineligible work is skipped with a reason. An automation reply preserves the conversation’s work state and cannot stand in for a human response.