Who maintains your business automations after launch?

Assign responsibility to a person or service

One person may hold several roles. A named role, access to investigate and an agreed response expectation matter more than the title. A monthly fee alone does not explain coverage.

What agents can observe and what they do not replace

Hunter monitors the connected advertising scope, including pacing, account changes and tracking breaks. Oscar helps review available website and channel evidence. Figaro and Cyrano contribute inquiry and conversation context in their enabled workflows. These are useful observations, not a general infrastructure watchdog.

Growth Control implementation and its technical maintainer must define workflow logs, alerts, access checks and recovery. Do not describe Hunter as monitoring every server, or promise that an agent can safely repair any failure without an accountable person.

See the boundaries of advertising monitoring.

See the available analytics and source coverage.

Create a runbook someone else can use

A runbook should explain the business consequence before it lists technical steps. An operator needs to know whether customers may have received a message, whether an invoice may already exist and whether the workflow is safe to pause. The technical maintainer needs enough references to investigate without relying on the original builder’s memory.

Keep this information accessible to the people who must respond, with appropriate access. A diagram that only the contractor can interpret is not a complete handover. Avoid putting credentials into the runbook; document account ownership and the approved access path instead.

Test hard failures and quiet wrong results

1. Stop a test connection and check who learns that the workflow failed.
2. Send a synthetic event twice and confirm that the implementation does not create two customer actions.
3. Interrupt a multi-step run after a record is saved but before delivery; define a safe recovery point.
4. Use incomplete or contradictory data and confirm that the workflow asks for review instead of inventing a fact.
5. Check a sample of completed records against source messages. Success logs can hide incorrect customer matches or old quote versions.

Worked example: an invoice request times out

Fictional Stretch Tent acceptance exercise; use synthetic records and do not issue real invoices.

The owner approves a deposit invoice proposal, but the application reports a timeout. The first question is whether the request failed before creation or whether the response was lost afterward. Those states require different actions. The operator pauses further attempts on that item and gives the maintainer the opportunity and request references.

The maintainer checks the destination provider through its approved interface. If the invoice exists, link the confirmed provider record and resolve the uncertain attempt rather than creating another invoice. If it does not exist, recovery must follow the implementation’s tested retry and approval rules. The record should explain which evidence supported the decision.

Pacioli’s billing connection is useful in this workflow, but it does not remove the need to define duplicate handling and partial-failure recovery. After the exercise, verify the amount, customer, provider reference and delivery state. “Invoice found” does not mean “paid,” and an approval for the original invoice does not automatically approve a changed amount.

Finish by recording the cause, affected test item, corrective action and evidence that the process is working. A maintainer saying “fixed” is weaker than an operator confirming the intended record and next action.

Review the billing role and approval rules.

Check business correctness as well as technical uptime

Some failures announce themselves: expired access, rejected requests or a stopped worker. Others produce plausible but wrong results. A recap may attach to the wrong event, a reminder may cite a replaced quote, or a report may quietly omit a channel. Design reviews that can detect both kinds.

• Completeness: compare eligible source events with the records that should have been created.
• Freshness: check when the source last updated, especially before acting on payment or campaign evidence.
• Correctness: review a sample against original messages and approved commercial facts.
• Responsibility: inspect unresolved exceptions and confirm someone owns the next step.

Hunter can flag issues in its advertising scope, and Oscar can help examine available source coverage. A technical maintainer must still own the broader monitoring and access checks. Schedule the operational review at a cadence appropriate to the business risk; a workflow touching customer commitments needs closer oversight than an internal draft report.

When a business rule changes, update its test examples and instructions as well as the automation. Preserve the last validated behavior so the operator can explain what a prior run was supposed to do.

Put the handover in writing

• List the owner of each account, access renewal and escalation contact.
• Document the intended inputs, outputs, exceptions and how to pause customer-facing activity.
• Specify what support includes, how changes are requested and who checks recovery.
• Keep sample synthetic tests and a readable record of the last validated configuration.

Use these requirements when choosing a partner.

Include support and recovery in the ownership-cost model.

Questions and answers