Before you automate an hour, find out where it goes.

Watch the handoffs, not just the clicks

Choose one recurring task: an invoice arriving by email, a booking request or a lead entering the CRM. Record what arrives, who touches it, which systems change and what proves the task is finished. Include the time spent fixing yesterday’s mistakes.

A useful sample contains ordinary work and awkward cases: a duplicate PDF, an incomplete form, a cancelled appointment. Keep waiting time separate from working time. Removing a three-day queue can matter more than saving thirty seconds of typing.

Pick the first process by its failure cost

A sensible first automation is frequent enough to observe, stable enough to describe and small enough to stop. Start by writing down the trigger and the finished state. For an incoming invoice, the trigger might be an email attachment; completion might mean a validated record in the accounting system, with the source linked and a responsible person notified. “Process invoices with AI” does not tell the implementer which of those steps must happen.

Compare candidates using volume, active working time, error frequency and the consequences of a wrong action. Do not combine those into a magic score unless everyone understands the assumptions. A rare mistake that changes a customer’s payment details deserves different controls from a missing internal tag. The first pilot should expose a real operational problem while keeping the consequences manageable. Put a named process owner beside every candidate; otherwise each integration question will become a meeting.

Decide where rules end and AI begins

When the same input should always lead to the same action, explicit rules are often easier to inspect. A complete form can create a CRM record, route it by region and notify an account owner without a language model. An AI step becomes useful when the input varies: an unstructured email, a scanned document or a request whose wording differs from your internal category names. Even then, separate interpreting the input from approving the action.

Imagine a purchase order that mentions two delivery addresses. The model can propose structured fields and point to the relevant text. A validation layer then checks required values, allowed suppliers and whether the address change needs review. It should not quietly invent a missing identifier. Ask the supplier to show where uncertainty becomes visible and how a reviewer corrects the result. That boundary is more useful than a broad claim that the workflow is “intelligent”.

Build a sample that includes ordinary inconvenience

Collect a permitted sample of real working situations before asking for an estimate. Include readable documents, poor scans, duplicate submissions, missing references and a supplier changing its layout. Keep a separate list of cases you expect to reject. The point is to describe the work accurately, not to make the demonstration fail through impossible examples. Remove unnecessary personal information from material used for development, and agree which systems may receive it.

Record the expected outcome beside each example. One document may be accepted, another sent for clarification and another identified as a duplicate. If different people disagree about the outcome, the business rule is still unresolved. Settle that before treating a developer’s answer as a defect. Retain some examples for acceptance rather than using everything while tuning the workflow. A useful test pack explains both the input and the reason a result is correct.

Check the integration before committing to the interface

A connector logo on a proposal does not tell you what the integration permits. Confirm which account can read or write the required data, whether the relevant operation exists and what happens when access expires. Ask about usage limits, pagination and delayed updates. A workflow that successfully reads the first page of contacts may still miss most of the database. A successful test with an administrator account may conceal permissions ordinary staff will not have.

Agree which system owns each field. If the CRM and billing tool both contain an address, decide which one wins when they differ. Avoid changing both automatically without a conflict rule. Record the identifiers used to match records, including what happens when a person changes their email address. These decisions may take longer than drawing the visual workflow, but they prevent the quiet duplication and overwriting that make automation difficult to trust after launch.

Make repeated delivery safe

Connections time out. An upstream service may send an event again because it did not receive an acknowledgement. Treat repeated delivery as an ordinary condition. For a consequential action, retain a stable operation identifier and check whether the action already succeeded before trying it again. The reviewer should be able to distinguish “not started”, “completed” and “outcome not yet confirmed”. A generic red error badge is not enough to make that decision.

Test the awkward middle: the destination saved a record, but the source never received confirmation. Then retry the original request. You should still have one record, with a traceable history. Also test a failure before any record is written, because that needs a different recovery path. Agree which errors may retry automatically and which should stop for inspection. Repeating a request with invalid business data more quickly is not a recovery strategy; it merely fills the queue.

Give the exception queue an owner and a next action

An exception queue should let a colleague finish the task without reconstructing the entire workflow. Show the source, extracted values, validation failure, previous attempts and the action required. Provide a way to correct a field, reject the item or resume from an appropriate point. If every failure creates only a notification saying “something went wrong”, the apparently automated process still depends on someone finding the missing context in several applications.

Decide how quickly each type of exception needs attention and who covers absences. A same-day booking request and a monthly internal report do not need identical escalation rules. Count the actual review time in the pilot, including context switching and follow-up questions. Examine why exceptions occur: improving an intake form may remove more work than changing the model. A growing unresolved queue is a capacity problem even when the percentage of automatically completed items looks impressive.

Test permissions with the account that will operate the workflow

Create the permissions needed for the actual task and check them in the pilot. Reading a document is different from editing a customer record, deleting a file or issuing a refund. A prompt telling an agent to behave carefully does not replace an application-level permission check. Record which actions can run automatically and which require an explicit approval from an authorised person. Use that decision when designing the workflow, rather than adding it after the demo.

The handover should explain who can change credentials and how access is removed when a person leaves. Keep secrets out of workflow screenshots and ordinary error notifications. Review which data appears in execution logs and how long the business needs to retain it. These are operational design questions, not a reason to copy every source document into every tool. A maintainable setup gives the owner enough evidence to diagnose a failure without distributing unnecessary sensitive content.

Run a pilot with a visible stopping point

Choose a bounded workload and write down the period, participants and success criteria. You might process selected documents while a person checks the result before it reaches the working system. The exact arrangement depends on the consequences of error. Make sure the team knows which route is authoritative during the trial, so that staff do not unknowingly complete the same task manually and automatically. Count both routes when assessing how much work remains.

Agree what stops the pilot: an incorrect consequential action, an unmanageable exception queue or a failure to identify duplicates, for example. Keep a practical pause control and a way to return unfinished work to normal operations. During the review, compare equivalent workloads, not a quiet pilot afternoon with the busiest day of the previous month. Include errors corrected before delivery. Those corrections are useful evidence about reliability even when customers never saw the original mistake.

Separate implementation cost from the monthly operating model

Ask for the estimate in parts: process discovery, data preparation, integrations, workflow implementation, acceptance and handover. Then list recurring subscriptions, API or model usage, hosting, monitoring and support. A low build price can coexist with substantial operating effort. Conversely, a more careful first implementation may reduce repeated manual investigation. You need to see the assumptions to compare proposals, especially if one includes supervision and the other ends with a working demonstration.

Write down what changes the estimate. A new document type, another business entity, higher volume or an additional approval step may be outside the original scope. Ask how those changes are priced and who can make small rule updates. Keep the value of released staff capacity separate from expenses you can actually remove. If the team uses the time to answer customers sooner, measure that outcome directly; do not relabel every recovered hour as money already saved.

Accept the operation, not just the workflow file

At handover, ask a colleague who did not build the automation to handle a failed item using the documentation. Have them find the source, understand the error, correct the issue and verify the final record. Then ask them to pause processing and identify the route for urgent support. This exercise tests whether the organisation can operate what it has bought. A large collection of connected nodes is not an operational handover on its own.

Include account ownership, exportable configuration, a version history and the repeatable acceptance examples. Identify who watches failures, who approves rule changes and who pays for the external services. Schedule reviews around actual changes in inputs or business rules rather than assuming the workflow is finished forever. The useful deliverable is one dependable process with a visible owner and recovery path. Once that works under ordinary conditions, expanding it becomes a decision supported by evidence.

A small calculation with an honest denominator

Consider an illustrative month with 400 documents taking four minutes each: 26.7 hours of manual work. After automation, suppose 60 exceptions still require five minutes each, plus two hours for monitoring. That leaves seven hours of work and recovers about 19.7 hours.

Those are assumptions, not a forecast. Replace them with your own volumes and timings. Recovered capacity becomes cash savings only if spending actually changes. Otherwise its value lies in what the team can now finish, how quickly customers get an answer, or how many corrections disappear.

Ask what happens to the sixty exceptions

A workflow is incomplete if the demo ends when the easy document reaches the database. Who receives an unreadable attachment? What stops a retry creating a second invoice? Can the person reviewing a record see its source?

Include API access, model usage, subscriptions and maintenance in the running cost. Ask for a named owner, a failure notification and a way to pause the workflow. Sometimes a form validation rule solves the expensive part before any AI is needed.

Commission one complete loop

Start with a single input, a defined destination and a visible exception queue. Agree the acceptance test before implementation, then compare the same task over comparable periods. Expand when the completed loop works; a longer list of connected apps is not evidence of a better process.