Build An Automation

This tutorial outlines how to build an automation that supports operators without bypassing the source-of-truth surfaces in the console.

Example Goal

Create an automation that prepares a booking follow-up summary when a customer submits an intake form or completes a service booking.

The automation should help the team reply faster, not send an unsupervised message.

The useful output is a reviewable operator brief: what happened, what record it came from, what context matters, and what the operator should do next. If the automation cannot explain those pieces, keep it in draft.

Step 1: Define The Trigger

Choose a trigger that is specific and observable.

Examples:

• New form submission.
• Booking created.
• Booking cancelled.
• Payment failed.
• Ticket opened.
• Customer has not responded.

For this example, use “new booking or intake submission.”

Avoid triggers that describe a vague business feeling, such as “customer seems unhappy” or “lead is important.” The console should be able to point to a concrete source record and event time so operators can explain why the automation ran and decide whether the result is still relevant.

Step 2: Choose The Context

List the records the automation can read:

• Customer profile.
• Recent bookings.
• Recent orders.
• Intake form fields.
• Communication history.
• Service details.
• Payment state.
• Staff assignment.

Keep the context focused. More data is not automatically better.

Context should answer the operator’s immediate question and nothing else. Include the booking, order, form, customer, and policy records that change the recommended action; omit unrelated history that would make the output harder to audit or increase privacy risk without improving the decision.

Step 3: Define The Output

For a follow-up summary, the output should include:

• Customer name and contact path.
• Requested service or topic.
• Date and time.
• Payment or deposit status.
• Any form answers that need attention.
• Suggested operator next step.
• Missing information.

Step 4: Decide What It May Update

Start with read-only output. If the automation later updates records, define the exact write path.

Low-risk updates:

• Add an internal note.
• Draft a response.
• Add a tag.

Higher-risk updates:

• Change booking status.
• Send a customer notification.
• Create or void an invoice.
• Record a refund.
• Change availability.

Higher-risk updates should require explicit operator approval.

Step 5: Test With Scenarios

Test at least:

1. Complete booking with paid deposit.
2. Booking awaiting deposit.
3. Customer with previous bookings.
4. New customer with no history.
5. Missing phone or email.
6. Cancelled or rescheduled booking.
7. Form submission with incomplete fields.

For each scenario, compare the output with what an experienced operator would write manually. Mark the scenario as passing only when the automation cites the right source records, avoids unsupported claims, and defers when payment, consent, customer identity, or booking state is ambiguous.

Step 6: Add Operator Review

The operator should be able to answer:

• Why did this automation run?
• What customer or booking did it use?
• What did it recommend?
• What did it change?
• How do I undo or ignore the result?

Step 7: Launch Small

Start with one workspace, one workflow, and a narrow trigger. Watch Inbox, Customers, Scheduling, and internal notes for a few days before expanding scope.

During the first launch window, compare automation output against what an experienced operator would have done manually. Pause or revise the workflow if it creates duplicate work, hides urgency, recommends unsafe customer communication, or writes to a record the team did not expect it to touch.

Step 8: Define Pause And Rollback

Before launch, write the pause and rollback path.

Operators should know:

• Where to disable the automation.
• Which records it may have touched.
• Which customer-facing actions require manual follow-up.
• Which console action reverses the change.
• Who approves re-enabling the automation.

For the booking follow-up example, rollback usually means pausing the automation, reviewing customer timelines, removing or correcting internal notes, stopping any drafted message before send, and confirming no booking status or payment state changed unexpectedly.

Troubleshoot A Failed Run

Automation Checklist

Use this checklist as the approval gate before a playbook is activated. A playbook that cannot explain its trigger, inputs, output, and review path should remain in draft, even if the generated summary looks useful in a single test case.

• Trigger is explicit.
• Context is scoped.
• Output is useful without being noisy.
• Writes are limited.
• Risky actions require approval.
• Operator can trace every customer-impacting result.
• Pause, rollback, and re-enable steps are documented.