Do not automate a broken process

01

Automation removes friction and visibility

A workflow can look efficient after automation because fewer people see it. That is helpful when the rule is sound and dangerous when staff were quietly correcting missing information, unusual cases or poor policy. The apparent manual inefficiency may have been the control keeping customers safe.

Before building, observe the process as it runs. Record where people pause, ask for context, change the route or ignore the documented step. Those moments reveal hidden decisions that a simple trigger-and-action diagram will miss.

02

Pass five tests before automating

The process should create a valuable outcome, have a clear start and finish, use dependable inputs, contain explainable rules and expose failures to an owner. If any test fails, improve that part before increasing the process speed.

Volume alone is not sufficient. A low-volume action with high consequence may deserve careful assistance and review, while a high-volume but unstable action may create more customer harm when scaled.

• Value: the step materially improves a customer or commercial outcome.
• Stability: most cases follow an understood path.
• Input quality: required data exists before the rule runs.
• Exception safety: uncertainty reaches the right person.
• Observability: completion and failure can be independently verified.

03

Automate coordination before judgement

Confirmations, assignments, reminders, status updates and evidence collection are often safer first candidates than qualification, complaints, discounts or advice. Coordination reduces waiting while leaving consequential decisions visible to people.

A good workflow knows when to stop. Define timeout, conflicting data, customer correction, repeated failure and sensitive-intent states. The hand-off should include the context already gathered so escalation does not force the customer to begin again.

04

Design for idempotency and reversal

Repeated events should not create repeated customers, invoices, tasks or messages. Give important actions a stable identity, check the current state before writing and record the result so retries are safe.

Ask how an operator can reverse or correct an outcome. If the only recovery is deleting data or asking a developer to repair production, the workflow is not operationally ready.

05

Measure the outcome, not executions

A thousand successful workflow runs prove only that the software executed. Measure whether the customer received the correct result, whether exceptions were escalated appropriately and whether teams spent less time on repeated coordination.

Review a sample of completed cases and every severe failure. As confidence grows, widen eligibility deliberately. Controlled expansion creates more learning than a broad launch followed by reactive exclusions.