1. Discover one workflow
Name the trigger, current steps, systems, owner, volume, handling time and known exceptions. Start with one bounded workflow rather than a broad goal such as automate sales.
Planning an implementation
A clear process from the first question to daily use
A useful automation needs a defined workflow, representative evidence, controlled access, explicit failure handling and an owner after launch. These are the steps we propose using to make those decisions visible.
Agree the scope before starting
Use this approach to prepare the project with us. Before starting, we agree which steps apply, who approves each decision, what evidence is needed and what support is included. The proposal records those commitments for your project.
Seven working stages
2. Confirm minimum data and permissions
Request only the sample records and system access needed to test the workflow. Use least-privilege accounts, identify sensitive fields, agree retention, and prefer a test environment where one exists.
3. Define limits before building
Write down what the system may do, what it must never do, which cases require a person, and what should stop the run. An automation without a boundary is not ready to test.
4. Build a representative test sample
Include ordinary cases, missing data, duplicates, invalid values, external-system failures and high-risk exceptions. Sample size should match workflow variability and risk, not a universal number.
5. Design errors and escalation
Classify recoverable and non-recoverable errors. Define retries, logs, alerts, a named human owner and the information that person needs to continue safely. Silent failure is an acceptance failure.
6. Accept against written criteria
Agree expected outputs and tolerances before evaluating the build. Record each test, observed result, evidence, decision and unresolved issue. Approval should identify who accepted which version and scope.
7. Assign maintenance
Name the owner for credentials, integrations, costs, monitoring and change requests. Set a review cadence based on business risk and change frequency, and keep a rollback or manual fallback available.
Minimum inputs before a pilot
- Workflow
- Trigger, end state, current owner and a simple step-by-step map.
- Evidence
- Representative input and output examples, including known bad cases.
- Access
- Named systems, least-privilege test access and an agreed credential owner.
- Boundaries
- Allowed actions, prohibited actions, stop conditions and human handoffs.
- Decision
- Success criteria, evidence required and the person authorised to accept.
Example test sample
This is a template, not a record of a completed client test. Replace the examples with the real workflow and record observed results during the pilot.
| Test | Input condition | Expected behaviour | Evidence to retain |
|---|---|---|---|
| EX-01 | Complete valid record | Complete the allowed action once and log the result | Input ID, timestamp, output ID and status |
| EX-02 | Required field missing | Do not perform the action; send the case to the named owner | Validation error and handoff record |
| EX-03 | Duplicate event | Detect the duplicate and avoid a second action | Idempotency key and duplicate status |
| EX-04 | External system unavailable | Retry only as agreed, then stop and alert a person | Attempts, final error and alert receipt |
| EX-05 | High-risk exception | Pause for human review before any irreversible action | Review decision, reviewer and timestamp |
A practical acceptance record
- Version and workflow scope under review
- Test cases executed and observed outputs
- Known failures, open limitations and accepted residual risk
- Rollback or manual fallback checked
- Monitoring, alert owner and credential owner assigned
- Named decision-maker and acceptance date recorded for the real project
Limits that should remain visible
- A passing sample does not prove every future input will behave the same way.
- Generative outputs can vary and need task-specific review thresholds.
- Third-party APIs, permissions, prices and behaviour can change after launch.
- Automation can move work rather than remove it, especially when review or exception volume is underestimated.
- Security, privacy, legal and sector requirements need qualified review where the project calls for it.
Maintenance is part of the system
A live workflow needs someone to watch failures, rotate credentials, review usage costs, approve changes and confirm that business rules still match reality. The appropriate cadence depends on volume, impact and change frequency. There is no universal retainer or review interval implied by this page.