Automation recipes and operating guardrails

A recipe is a hypothesis

WRKZY provides outcome starters and recipes such as welcome messages, out-of-office responses, lead qualification, follow-up reminders, and simple email follow-up. Treat each as editable scaffolding. The recipe does not know your consent model, inbox ownership, business hours, data quality, or escalation policy.

Design from outcome to evidence

For every workflow, complete this sentence before building: “For eligible records, when event happens, create customer or business result, owned by person/team, proven by evidence, unless stop rule applies.”

Guardrails in the builder

• Quiet hours defer governed work outside the configured window and timezone.
• Frequency cap limits runs per record within a number of hours.
• Auto-pause on failures stops the workflow after the configured failures in a window.
• Suppression tag excludes records marked by team policy.
• Journey re-entry controls once, after exit, or every eligible event.
• Goal and exit events stop journeys that have already achieved the result.
• Human Handoff creates accountable work when automation should not decide.
• If this step fails gives consequential steps an explicit exception path.

Launch in stages

1. Build only the minimum path that produces one useful, measurable outcome.
2. Use a marked test record to exercise success, failure, suppression, and timeout.
3. Publish during staffed hours.
4. Begin with narrow scope and conservative frequency.
5. Review the first real runs and customer-visible effects.
6. Expand only after success, edit, failure, and handoff signals support it.

Operating review

Weekly, inspect live workflows with recent failures, unusually low volume, unusually high volume, long waits, and repeated manual correction. A zero-failure workflow can still be wrong if it is enrolling the wrong records. Sample successful runs as well.

For AI-assisted optimization findings, review the proposed change like any other product hypothesis. Reject a proposal that cannot cite evidence or explain expected impact. AI must not silently publish workflow changes.

Anti-patterns

• One workflow owns several unrelated business outcomes.
• A broad inbound trigger relies on many nested conditions.
• A wait has no timeout or owner.
• A send step has no consent or purpose boundary.
• A webhook receiver creates duplicate work when the same request arrives more than once.
• A workflow closes a conversation before customer outcome evidence exists.
• A team edits a live workflow but never retests the current draft.
• “No errors” is used as the success metric.

Recovery standard

Contain broad risk by pausing. Recover individual runs from receipts. Roll back configuration through Version history. Archive obsolete workflows rather than repurposing their identity and history.