Should you automate this recurring workflow?

1. Ask four questions first

• Is the task repeatable? Write its trigger, required information, rule, and expected result. Use recent examples, including awkward cases. If two people apply the rule differently, resolve that first.
• Is it worthwhile? Measure current hands-on time and rework. Compare them with setup, checking, exceptions, fees, and maintenance.
• Can mistakes be contained? Identify the worst plausible error, how you would notice it, and how to stop it spreading.
• Who owns it? Name the person who checks failures, approves changes, and keeps instructions current. Name a backup.

Choose “keep manual,” “simplify first,” or “test one step.” A template or clearer form may solve the problem with less upkeep.

2. Include the work that remains

Here is a fictional example, not a client result or savings promise. A team handles 180 internal requests each month. Copying and checking each takes six minutes: 18 hours monthly.

A proposed automation prepares draft tasks. The team's monthly estimates are:

• 150 ordinary reviews at one minute each: 2.5 hours.
• 30 exceptions at five minutes each: 2.5 hours, replacing ordinary review for those cases.
• Checking runs: 1.5 hours. Maintenance: 2 hours.

That totals 8.5 hours, leaving an estimated 9.5 hours of released time. At an invented planning value of $30 USD per hour, less $45 in monthly tool fees, modeled net value is $240 monthly. Forty setup hours at that rate represent $1,200: a simple five-month payback.

Add four unexpected maintenance hours monthly and modeled net value falls to $120; payback becomes ten months. Include all actual incremental costs. Released time is not automatically cash savings. Measure real review time, errors, fees, and upkeep before expanding.

3. Keep access and approval specific

Start with a narrow task, such as copying approved form fields into an internal draft. List which records it reads, where it writes, and who can see the result. Ask the system owner to approve only the access needed. This follows the least-privilege principle in AWS guidance.

Keep customer messages, spending, and deadline commitments outside the pilot unless explicitly included and approved. A human approval step should show the proposed action and supporting information. Record the decision against that version of the request. Important changes require fresh review; silence is not approval.

Use fictional or appropriately redacted test records. Keep passwords and access keys out of forms, instructions, and logs.

4. Plan for the same request arriving twice

A missing confirmation does not prove an action failed. It may have completed before the connection broke. Repeating it could create a second task. The Amazon Builders’ Library explains this retry problem.

Give each request a stable reference number and record the task created from it. Distinguish repeating the same action from submitting a changed or genuinely new request.

Ask whoever configures the workflow to demonstrate duplicate protection during overlapping runs and partial failures. A separate “check whether it exists” step alone does not establish that protection. If the outcome is uncertain, hold the request for someone to compare source and destination before repeating the action.

5. Make failures visible and easy to stop

A temporary connection issue may justify a limited retry after a delay. A missing field needs correction; denied access needs the authorized owner. Set a maximum number of attempts and a person to notify. Microsoft's retry guidance explains why the response should match the failure.

Keep a simple register: request number, time, last completed step, output link, status, and next owner. Check for requests that produced no output as well as reported errors. Avoid unnecessary personal details in logs.

Agree on stop conditions. For this draft-task pilot, any unexplained duplicate, wrong destination, or bypassed approval should trigger a pause. Then:

1. Pause new work and check queued or in-progress actions.
2. Compare source requests with confirmed outputs.
3. Correct affected work using the approved procedure.
4. Resume manually from the checked list.
5. Test the fix and obtain the owner's approval before restarting.

Restoring earlier settings does not undo actions already completed. Sent messages may need an authorized correction.

6. Test before using live records

Use an isolated test destination, with external sending disabled. Write the expected outcome before each test. Check:

• A complete request and a missing required field.
• The same request repeated and two overlapping runs.
• A changed request after approval.
• A connection failure after an action has partly completed.
• Expired access, an absent approver, and a missing run.
• Pausing, returning to manual work, and restarting.

Record the result and evidence. Every request should have an explainable status, with no unexplained duplicate or unapproved action. Fix and retest failures before live use. If no safe testing route exists, keep the exercise to a walkthrough and draft outputs.

7. Hand over a routine someone can maintain

Provide the owner with the purpose, exclusions, approved access, approval rules, test results, failure register, and pause/recovery instructions. Include the backup contact, expected costs, and review date. Have the owner demonstrate finding a held request and stopping processing.

After a representative operating period, compare actual time, errors, unresolved work, and costs with the baseline. Decide whether to expand, revise, or retire it. Recheck whenever forms, fields, access, tools, or business rules change.

Workflow automation support begins with a clearly defined process and agreed responsibilities. Discuss one recurring workflow using a description or redacted example. Scope, technical fit, access, maintenance, and fees need agreement before implementation; specialist engineering or security work may need a qualified provider.

Download the editable workflow readiness checklist to record the decision and open questions.