Automations Overview

Automations are repeatable operator workflows. They help a workspace team perform consistent tasks without turning the console into a black box.

Use automations for procedures such as:

• Intake triage.
• Booking follow-up.
• Customer reactivation.
• Support handoff preparation.
• Drafting operator notes.
• Preparing product or service updates.
• Summarizing customer context.

What Automations Should Do

A good automation:

• Starts from a clear trigger or operator action.
• Names the records it will read or update.
• Explains what the operator should review.
• Leaves bookings, orders, payments, and customer records traceable.
• Produces a useful result even when some context is missing.

What Automations Should Not Do

Avoid automations that:

• Hide customer-impacting changes from the operator.
• Bypass payment, refund, booking, or notification rules.
• Duplicate a console feature that already has a dedicated action.
• Require the operator to know internal implementation details.

An automation should never become the only place a business rule exists. If the rule changes money, availability, customer status, notification timing, consent, or public content, the durable setting should live in the console surface that owns that workflow. Automations can prepare, draft, route, summarize, or request approval around that rule.

Console Relationship

Automations should support these surfaces:

Scheduling

Prepare follow-ups, summarize booking context, suggest next action

Customers

Gather relationship history before outreach

Inbox

Classify incoming work and route it

Products

Draft catalog updates, but let operators approve changes

Forms

Summarize submissions and identify missing fields

Email Notifications

Draft copy, but keep templates and variables explicit

Public Site Relationship

Automations may be triggered by customer activity on sites, but they should not surprise customers. If an automation sends messages, changes availability, creates invoices, or changes booking status, the operator should know where that behavior is configured and how to pause it.

Use public-site events as signals, not shortcuts around workflow ownership. A submitted form can trigger a triage draft, but the form definition still owns the fields. A booking event can trigger prep notes, but Scheduling still owns availability, payment timing, and lifecycle status.

Pause Or Roll Back An Automation

Use this path when an automation affects customers, creates noisy work, or appears to be using the wrong context.

1. Identify the automation name, trigger, workspace, and time window.
2. Pause or disable the automation before editing it.
3. Review the customer, booking, order, form, ticket, or notification records it touched.
4. Undo customer-impacting changes through the source-of-truth console surface.
5. Notify the operator owner when customers, payments, bookings, or email were affected.
6. Test the revised automation with a safe scenario before re-enabling it.

Do not patch the public site to hide an automation issue when a console automation owns the behavior.

Failure Visibility

Setup Principles

1. Start with one high-volume workflow.
2. Write the desired outcome in one sentence.
3. Define the records the automation can use.
4. Define the records it can update.
5. Add a manual review step for risky actions.
6. Test with real-but-safe scenarios before launch.

Choose the smallest workflow that saves repeated operator effort without increasing customer risk. A good first automation usually reads several records and produces one reviewable output. A risky first automation writes customer-visible state, sends messages automatically, or depends on ambiguous context.

Signs An Automation Is Ready

• The operator can explain when it runs.
• The output is easy to verify.
• Failures are visible in a console surface.
• Customer-facing changes have a human-approved path.
• The workflow improves speed without reducing accountability.