Automation Playbooks

Use these examples as starting points. Adapt them to the workspace’s actual services, products, policies, and team responsibilities.

Pick a playbook only after naming the operator decision it improves. The best playbooks make a repeated judgment easier to review; they do not replace the console surface that owns bookings, orders, payments, forms, notifications, or customer records.

Choose A Playbook

Before enabling a playbook, decide where the output appears, who reviews it, what it may update, and how to pause it.

Booking Follow-Up Prep

Trigger: booking created or intake submitted.

Reads:

• Booking details.
• Customer profile.
• Service configuration.
• Form answers.
• Payment state.

Output:

• Brief summary for the operator.
• Missing information.
• Suggested next action.

Good fit when the team handles high-touch services and wants consistent pre-appointment prep.

Deposit Reminder Draft

Trigger: booking remains awaiting deposit after a defined period.

Reads:

• Booking status.
• Deposit amount.
• Pay link state.
• Customer communication preferences.

Output:

• Draft reminder.
• Link to booking detail.
• Warning if the booking is no longer payable.

Do not send automatically unless the workspace has approved the notification timing and message.

Order Exception Triage

Trigger: order has payment, inventory, shipping, or fulfillment mismatch.

Reads:

• Order detail.
• Payment state.
• Inventory state.
• Shipping state.
• Customer record.

Output:

• Exception reason.
• Operator action list.
• Link to order detail and shipping queue.

Good fit for teams with product fulfillment volume.

Form Submission Router

Trigger: public form submitted.

Reads:

• Form definition.
• Submission fields.
• Customer identity if available.
• Workspace routing rules.

Output:

• Suggested category.
• Priority.
• Assigned team or owner.
• Draft customer reply.

Use for quote requests, contact forms, consent documents, and support intake.

Customer Recovery Prompt

Trigger: customer has stale booking, abandoned cart, unpaid invoice, or unresolved ticket.

Reads:

• Customer timeline.
• Last order or booking.
• Open invoices.
• Ticket status.
• Email preference.

Output:

• Recommended recovery path.
• Draft message.
• Risk notes.

Respect unsubscribe, consent, and communication settings.

Review Response Assistant

Trigger: new review synced from Google Business Profile or entered in the console.

Reads:

• Review rating and text.
• Customer record if matched.
• Prior support history.

Output:

• Draft public response.
• Internal context.
• Suggested follow-up if the review mentions unresolved work.

Human approval is strongly recommended before public review responses.

Playbook Quality Bar

Use the quality bar before adapting any example into a real workspace. The goal is not to automate everything; it is to make one repeatable operator decision easier to review, easier to assign, and safer to repeat.

Every playbook should identify:

• Trigger.
• Inputs.
• Output.
• Allowed writes.
• Operator review step.
• Stop condition.
• Where the result appears in console.

Add a stop condition for each playbook so the automation knows when to defer. Missing customer consent, ambiguous payment state, mismatched workspace identity, stale calendar data, or a policy conflict should move the result to operator review instead of producing a confident recommendation.

Risk Review

Consent

Is the customer allowed to receive the proposed message?

Payment state

Could the automation misread a paid, refunded, cancelled, or disputed record?

Booking state

Could the automation message a customer after a booking changed status?

Tenant scope

Is every input tied to the selected workspace?

Customer identity

Is the output about the right customer record?

Public impact

Could the automation change what customers see or receive without approval?

If any answer is uncertain, keep the automation in draft/review mode until the owner narrows the trigger or adds a stop condition.