A useful business process automation solution completes a defined handoff and makes unresolved work visible. Start with the work that repeatedly stalls, needs copying or requires chasing. Then compare configuration, integration, interface automation and custom development against that workflow. A tool's ability to run an action does not establish that it can run the right action, with the right authority, and recover when the result is uncertain.
This guide uses a fictional client-onboarding request that becomes a delivery task after approval. It is a planning example, not a customer success story or a claim about savings.
Choose a first workflow with an observable outcome
Look for a repeated activity whose start, finish and owner can be named. An approved onboarding request reaching the delivery queue is a useful boundary. “Automate operations” is too broad to evaluate. Observe some recent instances of the work, including an exception, before deciding which step needs changing.
Separate waiting from active work. A request waiting for a commercial decision has a different problem from an approved request that someone forgot to copy. Count manual touches, corrections and unresolved cases using existing records where possible. Mark estimates as estimates. If the process has no agreed approval rule or reliable customer identifier, resolving that gap may be the first useful work.
Choose a pilot where an operator can inspect the result and pause processing. Avoid combining a new customer-data model, a replacement CRM and several external integrations into the same initial decision. A smaller boundary still needs realistic failure cases.
Write down the handoff before choosing the tool
Describe six things together: the process owner, trigger, required input, action, review and exception route. For onboarding, the owner is the person responsible for getting approved work into delivery. The trigger is approval of a particular request revision. The input identifies the workspace, client, requested work and delivery owner. The action creates the delivery task; review confirms the correct task exists; exceptions reach someone who can investigate.
A form submission is not necessarily approval. Likewise, a notification that a job started is not evidence that delivery received the work. Give the important states names that staff can distinguish: awaiting approval, approved and pending handoff, handed off, or needing attention.
Keep the business outcome separate from its implementation. Our business and functional requirements guide explains how to turn an intended improvement into observable behavior. Here, that behavior becomes the basis for comparing solutions.
Compare four approaches against the same workflow
| Approach | Where to investigate fit | Evidence needed before committing |
|---|---|---|
| Configure an existing application | The records and work already live in one product, and its rules may support the approval and task creation. | Demonstrate the exact trigger, permitted roles, required fields, exception visibility and ownership after the original administrator leaves. |
| Integrate through APIs or connectors | Two useful systems need to exchange a bounded record without replacing their main interfaces. | Verify the required read and write operations, authentication scope, identifiers, limits, failure responses and duplicate handling. |
| Automate the user interface with RPA | A necessary application exposes the work through screens and no suitable supported integration meets the requirement. | Try representative screens and exception paths; establish the runtime account, session needs, change detection and who repairs broken selectors. |
| Build a custom workflow | Essential states, permissions or handoffs cannot be represented adequately by the available configuration and integrations. | Prove the uncertain rule or connection first, then include deployment, monitoring, recovery and maintenance in the scope. |
These are different ways to deliver the same outcome. Microsoft's connector documentation describes exposed triggers and actions, while its desktop-flow documentation describes interaction through UI elements and selectors. The presence of a product name in a connector catalogue does not establish support for your particular operation.
For interface automation, include representative layout changes and expired sessions in the assessment. For API integration, inspect the actual operation and account permissions. For custom work, compare the additional control with the responsibility to maintain it. The bespoke software decision guide develops that build-versus-configure choice.
A bounded pilot: approved onboarding to delivery
In our fictional pilot, a coordinator drafts an onboarding request in a workspace. An authorized approver in that same workspace reviews its client, scope and delivery owner. Drafting alone cannot start delivery. The pilot covers one approved request revision creating one corresponding delivery task; it excludes invoices, account provisioning and communication with real clients.
The request remains the authority for what was approved. The delivery system owns the resulting task and its later progress. Store a link between those records rather than treating their statuses as interchangeable. A task being created means the handoff happened, not that onboarding is complete.
Use synthetic requests covering a valid approval, missing information, the wrong role, a different workspace and a repeated handoff attempt. Propose a paused, inspectable trial before live processing. Decide how an approved request is corrected: a new revision should have an explicit review and relationship to earlier work, rather than silently changing a task that delivery has already started.
Acceptance requires evidence about those boundaries. An unauthorized attempt must leave the request and task unchanged. A valid approval must leave a traceable pending handoff or a confirmed task. Repeating the same handoff must not quietly create another task, and conflicting data must become visible for review.
Plan for an uncertain result, not just a failed action
Consider a receiver that creates the task but whose acknowledgment never reaches the sender. The sender cannot safely conclude that nothing happened. A retry needs a way to identify the same handoff and determine whether its content matches the existing task. A changed payload under the same identity needs a defined conflict response.
AWS's transactional outbox guidance addresses recording a business change together with pending notification work, and identifies duplicate messages as a concern for the receiver. The buyer's question is practical: can the operator distinguish pending work from completed work and recover without creating an unintended duplicate?
Our workflow automation example explores that boundary using local PHP and two SQLite databases, including a simulated lost acknowledgment and retry. Its synthetic identities and local receiver do not establish a real login flow, external-provider behavior, concurrent-worker safety or production delivery guarantees.
Observe whether the pilot improves the whole handoff
Agree the observation record before the trial. For each request, record when it became ready for approval, when approval happened, when the receiving task was confirmed and whether an operator intervened. Record correction and exception handling separately from the automated path. This allows the team to see whether work moved faster or simply moved into a less visible queue.
Compare like-for-like work and report how many cases were observed. A short pilot with straightforward synthetic requests cannot establish a general time-saving percentage. Once live observation is authorized, separate elapsed waiting time from staff effort and include time spent investigating failures. A reduction in manual effort may create capacity without reducing cash spending.
Ask the operators to explain a pending record and recover a prepared failure using the supplied instructions. Their ability to do that is part of acceptance. A successful demonstration by the person who built the automation is narrower evidence.
Assign the work that continues after launch
Name who owns the workflow rules and who operates the automation. Specify where failed or overdue handoffs appear, who reviews them, and when processing should pause. An alert needs a recipient and a response procedure. Agree support coverage and escalation according to the workflow's actual needs.
Keep application accounts, configuration and source access under the agreed organizational ownership. Document connection permissions, credential renewal, provider limits and dependencies. Handover should include the field mapping, approved revision, acceptance evidence, recovery steps and instructions for stopping new work without losing sight of already pending items.
Rehearse a manual fallback that includes checking for an existing delivery task before creating one. Reconcile outstanding handoffs when automation resumes. Changes to approval rules, fields or connected applications should trigger a review of the affected behavior and recovery instructions.
Use the evidence to choose the next step
At the review, decide whether to expand, revise or stop the pilot. Base that decision on observed handling of ordinary work and exceptions, operating effort and unresolved dependencies. Add another workflow only when its owner, data boundary and acceptance evidence are equally clear.
Use the editable business automation pilot brief to share the current process, proposed boundary and evidence needed. For implementation support, see our software development services, or CRM development services when customer records and sales-to-delivery handoffs are central.