# Business automation pilot brief

Choose one repeated workflow, agree its rules and observe the complete result before expanding. Replace bracketed fields. The onboarding example below is fictional; its business benefits are not measured customer results.

## 1. Define the work and its owner

Workflow: [a bounded activity, such as creating a delivery task after onboarding approval]

Business owner: [role responsible for the outcome]

Implementation and ongoing support owners: [roles]

Start and finish: [observable trigger] → [confirmed result in the authoritative system]

Users and affected systems: [people, applications and records]

Keep outside this pilot: [other workflows, replacement projects and optional features]

What is failing today: [observed delay, repeated entry, missing information or correction]

## 2. Record a baseline

Measure comparable work for a stated period. Count waiting and hands-on work separately. Keep exceptions in the sample rather than measuring only successful cases.

| Measure | Definition | Baseline observation | Pilot observation | Evidence |
| --- | --- | --- | --- | --- |
| Eligible cases | Which requests belong in this workflow? | [count / period] | [count / period] | [record set] |
| Hands-on time | Which tasks are timed, including checking and correcting? | [minutes / case and total] | [same basis] | [sample / timer record] |
| Elapsed time | Which start and finish timestamps are compared? | [distribution / period] | [same basis] | [timestamps] |
| Exception rate | Which cases needed human intervention? | [exceptions / eligible cases] | [same basis] | [reason codes] |
| Correct completion | What proves that the intended record exists and is usable? | [completed / eligible cases] | [same basis] | [reconciliation] |
| Duplicate or missing results | Which stable identity joins the source and destination? | [counts and reasons] | [same basis] | [matched records] |

Reduced hands-on time creates capacity only when it is usable elsewhere. It does not automatically reduce payroll or increase revenue. Include subscription charges, support, exception handling and changes to the connected systems when comparing options. Record monetary assumptions separately from observed minutes.

## 3. Compare the smallest suitable solution

| Option | What the pilot must demonstrate | Ongoing responsibility |
| --- | --- | --- |
| Configure an existing application | Its actual permissions, approvals and automation rules cover the required workflow | Rule changes, account access and product updates |
| Connect systems through supported APIs | Correct field mapping, stable identities, duplicate handling and recoverable failures | API changes, credentials, delivery monitoring and reconciliation |
| Use UI automation/RPA for a necessary gap | The specified screens and exception cases work under the permitted access model | Interface changes, session failures and manual recovery |
| Build a bounded workflow component | The unmet rule or control warrants the development and maintenance scope | Releases, data ownership, support and operating documentation |
| Keep or improve the manual step | Low volume or frequent judgment makes the smaller change sufficient | Clear instructions, visibility and accountable review |

Shortlisted option and reason: [evidence, unresolved questions and disqualifiers]

Avoid selecting a tool solely from its feature list. Request a demonstration of the exception that matters to this workflow.

## 4. Specify records, rules and handoffs

| Item | Decision |
| --- | --- |
| Trigger | [Which event starts work, and what proves it is authorized?] |
| Required inputs | [Fields, valid values and missing-data response] |
| Authoritative record | [System that owns the business state; allowed writers] |
| Human decision | [Who approves/rejects, and what must remain a person’s decision?] |
| Identity and scope | [Workspace/account/request/revision identifiers; permission boundary] |
| Intended output | [Record/action, destination and exact completion condition] |
| Repeated delivery | [Stable idempotency key, retention policy and changed-payload rule] |
| Uncertain outcome | [How to establish whether the destination already acted] |
| Exception owner | [Who reviews permanent rejection, missing data or repeated failure] |
| Evidence and retention | [Minimum useful log fields, access and agreed retention] |
| Stop and recovery | [How new work is paused; which pending cases need reconciliation] |

Changing a request after approval needs its own business rule. Do not simply assign a new key on every retry: that may turn a repeated delivery into a second business action. Conversely, a genuinely new approved action needs a distinct identity.

## 5. Filled fictional example

**Workflow:** after an authorized approver approves client-onboarding request 42 in workspace 7, create one delivery task for revision 1.

The source application owns approval. The destination owns its task. Approval and a durable pending handoff are saved in one source-database transaction. A separate worker delivers the handoff. The destination recognizes the stable action key `onboarding:7:42:1` and checks that a repeated key carries the same payload.

**Completion:** a destination task identifier is recorded against the source handoff. Sending a request is not enough to establish this result.

**Important failure:** the destination creates its task, but the sender does not receive confirmation. The sender must treat the outcome as uncertain. Retrying the same action identity allows the destination to return the original task rather than creating another. A request that reuses the key with a changed payload is a conflict for review.

This is a proposed business workflow. The separate [worked example](https://nomadicsoft.io/blog/workflow-automation-example) executes only its bounded approval and recovery logic using synthetic identities and two independent in-memory SQLite databases. Their state disappears when the process exits. It does not demonstrate persistent storage, restart recovery, a live CRM integration, a network, concurrent workers or a production authorization system.

## 6. Agree pilot acceptance and failure cases

| Scenario | Expected result | Evidence / owner / status |
| --- | --- | --- |
| Required input is missing | No invalid downstream action; useful correction path | [record] |
| User lacks approval authority | Denial and no approval or handoff change | [record] |
| Record belongs to another workspace | Denial; scope cannot be supplied to bypass access | [record] |
| Source transaction fails | Approval and its pending handoff both roll back | [record] |
| Normal approved handoff succeeds | Correct destination record and recorded confirmation | [record] |
| Destination commits but confirmation is lost | Retry uses the same action identity and reconciles the existing result | [record] |
| Same action is delivered again | No additional business effect under the agreed duplicate rule | [record] |
| Same key carries different content | Conflict is visible; the earlier record is not silently overwritten | [record] |
| Destination rejects the request permanently | No endless retry; assigned human review with source details | [record] |
| Credentials expire or rate limits apply | Bounded recovery behavior and visible unresolved work | [record] |
| Work is paused during a release | Pending work remains accountable; restart does not silently lose it | [record] |
| A later valid request arrives | Its distinct action is processed without being mistaken for a duplicate | [record] |

These are acceptance cases to agree and execute for the selected implementation. They are broader than the checks run by the downloadable local example. Add real-provider behavior, concurrent delivery, security, accessibility and deployment checks where the pilot requires them.

## 7. Define operating decisions

- Retry policy: [retryable outcomes, delay/backoff, attempt limit and escalation]
- Reconciliation: [how pending/uncertain actions are matched to destination records]
- Monitoring: [oldest pending age, rejected cases and who receives actionable notice]
- Credential owner: [access scope, rotation and expiry response; do not paste secrets]
- Change owner: [rule/schema/API changes, validation and deployment]
- Recovery procedure: [pause, inspect, correct and replay with the correct identity]
- Handover: [setup, dependencies, runbook and evidence of a successful recovery drill]

Choose alert thresholds from the workflow's actual deadline and staffing. A red counter without an available owner is not a recovery process.

## 8. Decide whether to expand

| Question | Recorded decision |
| --- | --- |
| Did the complete workflow work, including its required failures? | [evidence and gaps] |
| Did the baseline outcome improve on a comparable set of cases? | [measurement and uncertainty] |
| Was the saved effort offset by support or exception work? | [observed work and costs] |
| Can an assigned maintainer investigate and recover a failed case? | [demonstration] |
| Should the next step expand, revise or stop this pilot? | [owner, reason and date] |

Companion guide: https://nomadicsoft.io/blog/business-process-automation-solutions

Complete local example: https://nomadicsoft.io/downloads/workflow-automation-example.md